Модули и тулчейн: MVS, go.sum, воркспейсы и инструменты CI

MVS: минимальный выбор версий, а не солвер

Почему Go-сборка воспроизводится байт-в-байт на машине коллеги через шесть месяцев, тогда как аналогичный npm-проект требует lock-файла и всё равно порой отличается? Ответ — один алгоритм, умещающийся на салфетке.

Строка require в go.mod — это минимум, а не диапазон. Чтобы собрать итоговый список версий, Go обходит граф модулей, собирает требуемый минимум каждого модуля для каждой зависимости и берёт максимум из минимумов — наименьшую версию, устраивающую всех. Это весь алгоритм:

// ваш модуль требует:  A v1.2.0,  B v1.1.0
// A требует:           C v1.3.0
// B требует:           C v1.5.0
//
// MVS выбирает C v1.5.0 — максимум из требуемых минимумов.
// НЕ последний релиз C v1.9.2: MVS никогда не прыгает дальше
// того, что кто-то в графе явно попросил.
//
// Апгрейды всегда явные:
//   go get C@v1.6.0    // поднять собственный минимум
//   go get -u ./...    // поднять всё (осознанно)
//   go mod tidy        // синхронизировать go.mod с импортами

Сравните с моделью npm: semver-диапазоны (^1.3.0), разрешаемые в момент установки, означают, что один и тот же package.json в разные дни даёт разные деревья, — и для восстановления детерминизма приходится прикручивать lock-файл. MVS для выбора версий lock-файл не нужен: список сборки — чистая функция от go.mod-файлов графа, вычислимая вручную, одинаковая на каждой машине, всегда. Размен честный: автоматического подхвата багфиксов нет; security-патч в C v1.5.1 доедет до вас, только когда вы или зависимость его попросите — отсюда govulncheck и регулярные PR с go get -u как противовес. go.sum добавляет не пиннинг версий, а верификацию содержимого: журнал криптографических хешей каждой когда-либо использованной версии модуля, сверяемый с transparency-логом (публичным append-only реестром хешей модулей) sum.golang.org при первом скачивании. Версии берутся из go.mod; go.sum гарантирует, что названная версия байт-в-байт совпадает с тем, что получил остальной мир, — именно это и сработало в Hook.

replace и go.work: локальная обвязка, которая не должна утекать

Два инструмента перенаправляют, откуда берётся исходник модуля, — с очень разным радиусом поражения. Директива replace в go.mod (replace github.com/acme/lib => ../lib) действует, только когда этот модуль — главный: replace в go.mod ваших зависимостей игнорируются целиком. Это делает replace безопасным для форков и аварийных пинов, но и классической миной: закоммиченный => ../lib собирается на вашем ноутбуке и умирает в Docker и у каждого потребителя, потому что относительный путь существует только на вашем диске. С Go 1.18 правильный инструмент мультимодульной разработки — воркспейс: файл go.work со строками use ./app и use ./lib заставляет тулчейн разрешать lib из локальных исходников для всех перечисленных модулей — без правок go.mod, и go.work по конвенции не коммитится (локальная обвязка разработчика, как конфиг IDE), так что в опубликованный модуль ничего не утекает. CI, собирающий без воркспейса, видит ровно то, что увидят потребители; GOFLAGS=-mod=readonly (поведение по умолчанию с 1.16) плюс отсутствие go.work в CI — честная конфигурация.

Тулчейн в CI: vet, staticcheck, -race, generate

Компилятор принимает массу неправильных программ; тулчейн сужает зазор слоями. go vet гоняет анализаторы багов, которые система типов не видит, — несовпадения аргументов printf, скопированные мьютексы (copylocks), недостижимый код; подмножество vet уже выполняется автоматически при go test, но CI должен гонять полный go vet ./.... staticcheck идёт на порядок дальше своими SA-проверками (запись в nil-map, неверный time.Format, отложенный Close на nil-теле ответа) и де-факто является вторым линтером серьёзных Go-команд. Детектор гонок — динамическая инструментация: go test -race ловит только гонки, которые тесты реально исполнили, по реальной цене — примерно 5–10× CPU и 5–10× памяти; поэтому его место — на CI-прогоне тестов (всегда) и, возможно, на канареечной реплике, но не на каждом продакшен-поде. go generate — это контракт с людьми, а не со сборкой: он никогда не запускается автоматически, поэтому сгенерированный код (моки, protobuf, stringer) коммитится, а CI стережёт дрейф, перегенерируя и падая на непустом git diff — тот же трюк, что и go mod tidy -diff. Для воспроизводимых релизных бинарей: запиненная директива toolchain go1.24.x в go.mod, -trimpath, чтобы пути сборщика не вшивались в бинарь, и module proxy плюс go.sum довершают дело — одинаковые входы, одинаковые байты.