单元测试依赖易被忽略版本锁定，因go test不触发go.mod更新，需显式用go get -t或手动添加require并运行go mod tidy；其校验和计入go.sum，必须提交以确保ci一致性。
单元测试依赖为什么容易被忽略版本锁定
因为 go test 默认不触发 go.mod 更新，即使你 import 了 github.com/stretchr/testify/assert 这类测试专用包，只要没在主代码里用，go build 就不会把它写进 go.mod。结果就是：本地跑得通，CI 上拉到不同版本直接 panic —— 尤其是 testify 这类常发 breaking change 的库。
如何让测试依赖也进 go.mod 并锁定版本
必须显式声明，不能靠“import 了就自动记录”。Go 不区分生产/测试依赖，只看是否被构建图实际引用。但测试代码（*_test.go）默认不参与主模块构建，所以得手动拉进来：
- 运行
go get -t github.com/stretchr/testify@v1.8.4（-t表示包含测试依赖） - 或直接编辑
go.mod，加一行：require github.com/stretchr/testify v1.8.4 // indirect，再执行go mod tidy - 验证是否生效：
go list -m -f '{{.Version}}' github.com/stretchr/testify应输出v1.8.4，不是伪版本或latest
注意：indirect 标记表示它没被主代码 import，但已被 go mod tidy 认定为必要依赖 —— 这个标记不影响锁定效果，只反映引用路径。
replace 对测试依赖无效？其实是优先级问题
replace 在 go.mod 中对所有依赖生效，包括测试依赖，但容易踩坑：
- 如果你在
go.mod里写了replace github.com/stretchr/testify => ./local-testify，但本地目录没go.mod文件，Go 会报错invalid module: no go.mod file -
replace优先级高于require，但仅对当前模块图生效；如果某个间接依赖（比如你用的某个 mock 工具）内部 hardcode 了testify v1.7.0，而你replace了 v1.8.4，Go 仍可能因版本冲突拒绝构建 - 真正可靠的方案是：先用
go mod graph | grep testify查清谁在拉哪个版本，再决定是replace还是升级那个间接依赖本身
go.sum 里测试依赖的校验和必须提交
go.sum 不区分主/测试依赖，所有出现在 go list -m all 输出里的模块，其哈希都会被记录。但很多人删掉测试依赖后忘了 go mod tidy，导致 go.sum 里残留旧校验和 —— CI 上一跑 go test 就报 checksum mismatch。
关键动作只有两个：
- 每次增删测试依赖后，必须运行
go mod tidy（它会同步清理go.sum中冗余条目） -
go.sum文件必须提交到 Git —— 它不是缓存，是完整性强制检查依据；漏提会导致不同机器构建出不同二进制
最隐蔽的问题是：某些私有测试工具链依赖未配置 GOPRIVATE，Go 会走公共 proxy 下载，但 proxy 返回的包哈希可能和公司内网仓库不一致 —— 这时候 go.sum 校验必然失败，且错误信息里不会明说原因。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
