go项目依赖版本锁定核心靠go.mod的require行，写死语义化或伪版本号即严格使用该版本；伪版本精准绑定commit与时间；手动改go.mod后须运行go mod tidy校验；升级应显式指定版本如go get @v1.8.6，禁用go get -u；replace和vendor为特殊场景补充手段；需确保go.mod/go.sum受控且构建环境禁用动态修改命令。
Go 项目中依赖包的版本锁定，核心靠 go.mod 文件里的 require 行，不是靠手动改 go.sum 或“锁文件”概念——写死版本号，Go 就会严格用那个版本。
go.mod 的 require 行才是真正的版本锁
Go 不靠锁文件选版本，而是直接解析 go.mod 中的 require 语句。只要它写着 github.com/sirupsen/logrus v1.9.3，go build 就一定拉这个版本（前提是本地缓存或 proxy 没被污染）。
-
require必须带明确语义化版本（如v1.2.3）或伪版本（如v0.0.0-20230101000000-3f5e24b6），空着、写latest或master都不合法，go mod tidy会报错 - 伪版本不是“临时方案”，而是 Go 对无 tag commit 的标准表达，它绑定具体 commit 和 author time，比 tag 更精确、更可重现
- 手动编辑
go.mod后，必须运行go mod tidy校验一致性；但tidy不会升级已锁定的版本，只补全或清理间接依赖 - 如果某个模块被多个间接依赖以不同版本引入（比如 A 要 v1.2.0，B 要 v1.5.0），Go 会保留两者，并在
go.sum中分别记录哈希——这是正常行为，不是错误
go get @version 是最安全的更新方式
想升级或降级一个包，别用 go get -u，它会连带升级所有可及依赖，极易破坏兼容性。应该显式指定版本，让 Go 工具链自动同步 go.mod 和 go.sum。
- 升级到特定版：
go get github.com/gorilla/mux@v1.8.6 - 切到某次 commit：
go get github.com/gorilla/mux@3f5e24b6（Go 自动转成伪版本并写入go.mod） - 避免只写
go mod edit -require=...：它只改go.mod，不下载代码，也不更新go.sum，下次go build可能拉错版本或报校验失败 - 执行后立刻检查
go.sum是否新增对应行；若没变，可能是 proxy 缓存或 GOPROXY 干扰，加-x参数看真实 fetch 行为
replace 和 vendor 是特殊场景下的加固手段
当需要绕过远程源、统一间接依赖版本，或追求完全离线构建时，replace 和 vendor 是补充手段，但它们不替代 go.mod 的基础锁定逻辑。
-
replace仅对当前模块生效，且右侧路径必须是有效 Git 仓库（含.git目录），否则go mod tidy会报no module found -
go mod vendor会把所有依赖复制进vendor/，之后用go build -mod=vendor构建，彻底脱离网络和 GOPROXY，适合 CI/CD 或 air-gapped 环境 -
replace不会自动触发下载，需确保目标存在；上线前务必删除开发用的replace，否则构建可能失败（比如指向本地./local-fork，CI 机器上根本不存在） - 私有模块（如公司内网 GitLab）必须配置
GOPRIVATE，否则 Go 默认走官方 proxy + checksum server，会导致校验失败或拉不到代码
真正容易被忽略的是：版本锁定的确定性，高度依赖 go.mod 内容稳定、go.sum 提交进版本控制、以及构建环境禁用任何可能修改依赖的命令（如 go get 或未加 -v 的 go mod tidy）。一旦这些环节松动，所谓“锁定”就只是纸面承诺。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
