What does go mod tidy do beyond adding dependencies?

WHAT THIS TESTS: Whether you understand go mod tidy as a correctness and security tool rather than mere housekeeping. It probes your grasp of how Go enforces a minimal, reproducible module graph through the tight interaction of go.mod, go.sum, the module cache, and Minimal Version Selection. Interviewers want to see that you recognize tidy as the command that bridges declared intent in go.mod with the ground truth of your source code and the actual resolved dependency graph.

A GOOD ANSWER COVERS: First, tidy scans every package in the main module to resolve all import paths to specific module paths and versions, including test dependencies. Second, it mutates go.mod to add missing requirements and prune requirements on modules that no longer provide any imported packages, yielding a minimal dependency set that exactly matches what the code needs. Third, it downloads the go.mod files required to compute the full build list using Minimal Version Selection, which determines the precise versions of direct and indirect dependencies. Fourth, and most important for verifiable builds, it ensures go.sum contains cryptographic checksums for every module in that resolved build list, including indirect dependencies, so future builds can authenticate the exact code being compiled and detect tampering in the module cache or proxy.

COMMON WRONG ANSWERS: Claiming tidy only edits go.mod without updating go.sum or that it is safe to hand-edit go.mod and skip tidy. Saying it upgrades dependencies to their latest versions rather than resolving the minimal version needed. Asserting that it modifies vendor directories directly or that it is equivalent to go mod vendor. Confusing it with go mod download, which merely fetches source code without pruning requirements, adding missing requirements, or reconciling go.sum against the build list.

LIKELY FOLLOW-UPS: How does tidy handle local replace and exclude directives when computing the build list? Why might go.sum have missing entries after a hand-edited go.mod, and what security risk does that create? What is the exact difference between the requirement list stored in go.mod and the actual build list computed by Minimal Version Selection? How does setting GONOSUMDB or GOSUMDB off change the behavior of tidy, and why is that dangerous for verifiable builds?

ONE CONCRETE EXAMPLE: Suppose you manually add a require directive for github.com/pkg/errors v0.9.1 to go.mod because a new source file imports it, but you skip running tidy. Your local build succeeds because the module already sits in your local cache, but go.sum lacks its checksum. A teammate running go build with GOSUMDB enabled and a fresh module cache will see a security error because the build system cannot verify the module contents against a known checksum. Running go mod tidy fetches the missing checksum, adds it to go.sum, prunes any old requirements that are no longer imported, and guarantees the module graph is minimal, consistent, and verifiable in every environment.