Go项目依赖不会自动升级，所谓“自动”实为执行go get或go mod tidy等显式命令时，因版本约束不足而被动选择更高兼容版本所致。

Go 项目依赖不会“自动升级”，这是常见误解。Go Module 本身没有后台定时检查、自动拉取新版本或静默更新依赖的行为。所谓“自动升级”，其实是开发者在执行某些 显式命令（如 go get、go mod tidy）时，因未指定精确版本或约束不足，导致 Go 工具链按语义化版本规则“被动选择更高版本”所致。

go get 默认行为：升级到最新兼容版本

当你运行 go get example.com/pkg（不带版本后缀），Go 会：

• 查找该模块在 go.sum 中已记录的最高兼容版本（满足当前 go.mod 中 require 的版本范围）
• 若远程有更新的 次要版本（如 v1.2.x → v1.3.0）或补丁版本（v1.2.0 → v1.2.1），且符合语义化版本兼容性（主版本号相同），则默认升级到最新可用版本
• 同时更新 go.mod 中的 require 行和 go.sum

⚠️ 注意：这不是“自动”，而是你主动执行了 go get，工具按规则做了版本解析。

go mod tidy 的“隐式升级”场景

go mod tidy 本意是同步依赖树，但它可能“看似自动升级”，原因包括：

• 代码中新增 import 了一个尚未声明的模块（如 import "golang.org/x/sync/errgroup"），而该模块在 go.mod 中无 require 条目
• Go 会自动添加该模块的 最新发布版本（通常是 latest tagged release，非 master 分支）
• 如果已有旧版本 require，但本地缓存缺失或 go.sum 不匹配，tidy 可能回退到更高兼容版本来满足构建

本质仍是“按需解析”，不是后台升级。

为什么感觉像“自动”？常见诱因

以下操作容易让人误以为依赖被自动升级：

• CI/CD 流水线每次 clean 构建 + go mod tidy：若依赖模块发布了新 patch 版本，流水线就会拉取并固化，导致不同时间构建结果不一致
• 本地未锁定 minor 版本：例如 require github.com/gin-gonic/gin v1.9.0，后续 v1.10.0 发布后，go get -u 就会升到 v1.10.0
• 使用 go get -u 或 -u=patch：这些标志明确指示“升级”，不是默认行为

如何避免意外升级？实用建议

控制依赖版本的核心在于“显式声明 + 严格约束”：

• 用 go get example.com/pkg@v1.2.3 精确指定版本，而非省略 @vX.Y.Z
• 在 go.mod 中固定 minor 版本（如 v1.2.3），避免只写 v1 或留空
• 禁用自动升级：CI 中改用 go mod download + go build，跳过 tidy 和 get
• 定期人工审查：go list -u -m all 查看可升级项，go list -u -m github.com/xxx/yyy 检查单个模块

基本上就这些。Go Module 的设计哲学是“确定性优先”，所有版本变更都源于你的命令或代码变更，没有隐藏的自动升级服务。关键在理解每个命令的语义，而不是防“自动”。