Для чего нужны файлы go.mod и go.sum

Что проверяют

Понимаете ли вы, как Go выбирает версии зависимостей и чем контрольные суммы отличаются от лок-файла. Следом обычно спрашивают, нужно ли коммитить go.sum и что делать с приватными модулями.

Как отвечать

• go.mod: описание модуля. module задаёт путь импорта, go минимальную версию языка (с Go 1.21 это жёсткое требование, а toolchain указывает, какой тулчейн использовать), require зависимости с версиями, replace подмену на форк или локальный каталог, exclude и retract для плохих версий. С Go 1.17 там перечислены и косвенные зависимости с пометкой // indirect;
• go.sum: криптографические хэши. Для каждой версии хранится хэш содержимого модуля и отдельно хэш его go.mod. При загрузке скачанное сверяется с go.sum, а новые записи с публичной базой sum.golang.org. Если автор перезалил тег или прокси подсунул другой код, сборка упадёт.

Ключевая мысль: версии определяет go.mod через Minimal Version Selection. Из всех требований к модулю берётся наибольшая из минимальных версий, а не самая свежая в реестре. Поэтому сборка воспроизводима без лок-файла, а go.sum отвечает не за выбор версии, а за то, что под версией лежит тот же код.

Команды, которые стоит назвать: go mod tidy добавляет недостающее и убирает лишнее, go get example.com/lib@v1.4.0 меняет версию, go mod verify проверяет кеш модулей, go mod why объясняет, откуда взялась зависимость. Для приватных репозиториев задают GOPRIVATE, чтобы запросы не шли в публичный прокси и базу сумм.

Где спотыкаются

Называют go.sum аналогом package-lock.json. Версии там не фиксируются, файл может содержать строки для нескольких версий одного модуля, и это нормально.

Не коммитят go.sum или удаляют его при конфликте слияния. Правильно разрешить конфликт в go.mod и выполнить go mod tidy, суммы восстановятся.

Думают, что Go сам обновит зависимость до последней версии. Без явного go get -u берётся минимальная подходящая, и за обновлениями безопасности нужно следить самим, например через govulncheck.