Go Sum
Fast recall
Quick revision
Core answer
Whether you understand Go Sum beyond memorized syntax.
Giving a definition without explaining a practical trade-off.
Connect the concept to a small production example and state its complexity or failure mode.
Interview-ready guide
Interview answer
The file, verified after our tidy:
github.com/google/uuid v1.6.0 h1:NIvJDL...Each line: module, version, and three hash fields (the module directory content, the .mod file, and the go.mod file). After download, the hashes are verified — a corrupted or tampered dependency fails the build.
What go.sum IS: an integrity verification list — 'these are the exact bytes we downloaded.' NOT a lock file: it doesn't select versions (go.mod's requires do that). Both exist to make builds reproducible.
Why both files: go.mod selects the version; go.sum verifies the content. A lock file conflates both; Go separates selection from verification — and the same version can appear in different builds' go.sums with the same hashes (verification) while go.mod's selection is per-module.
The supply-chain story: a compromised proxy or a deleted-and-republished tag would serve different bytes for the same version — go.sum catches the difference. Without it, 'v1.6.0' could be anything.
The discipline: commit both go.mod and go.sum. If go.sum is missing/empty (fresh clone), go mod download or go mod tidy recreates it — and CI verifies.
Go Sum
Direct Answer
Cryptographic hashes of every dependency's content. go test/build verifies downloaded modules against go.sum before use — supply-chain integrity. Commit it alongside go.mod.
Deep Dive & Architecture
The hash types: go.sum records hashes for the module's source directory (the extracted zip), the .mod file, and the go.mod file — each is verified against the downloaded artifact. The algorithm is SHA-256, and the format is the same as go.sum's snapshot format.
The verification flow: on import, the module proxy/cache is consulted → the version is downloaded → its content is hashed → compared to go.sum → mismatch aborts with a security error. Clean, deterministic, and the failure names the exact module/version that changed.
The -mod=mod vs -mod=readonly flag story: -mod=readonly (the default for builds) refuses to update go.mod/go.sum (fails if they'd change — the reproducibility guarantee); -mod=mod (go get/tidy) updates them. This is why go build errors when go.sum is missing — it won't silently add the verification entries.
Common Mistakes & Pitfalls
Giving a definition without explaining a practical trade-off.
Check your understanding
Answer these without looking back at the article.
- When would you use Go Sum in a real project?
- How would you compare Go Sum with an alternative?
- What is a common mistake when using Go Sum?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.