go.mod和go.sum必须一起提交，因go.sum是依赖内容的密码学指纹清单，缺失会导致ci拉取不一致模块而校验失败；仅提交go.mod等于将校验权交给不可控的本地缓存。
团队成员的 go.mod 和 go.sum 必须全部提交，且每次依赖变更后需同步运行 go mod tidy —— 这是唯一能防止“本地能跑、CI 报错”的底线操作。
为什么 go.mod 和 go.sum 必须一起提交
只提交 go.mod 而忽略 go.sum，等于把依赖校验权交给了每个人的本地缓存。CI 环境拉取代码后执行 go build 时，go 工具会尝试补全缺失的 go.sum 条目，但这时下载的模块内容可能与你本地不一致（比如中间代理缓存了旧版本、或私有仓库权限临时失效），导致 checksum mismatch 或构建失败。
-
go.sum不是“可选文件”，它是所有依赖模块内容的密码学指纹清单，缺失即不可信 - Git 分支合并冲突常发生在
go.sum，必须人工确认每行哈希是否对应预期模块版本，不能直接 accept theirs - 若某子模块更新了依赖但没更新自己的
go.sum，主模块运行go mod tidy会把它拉进来，但 CI 构建时可能因子模块未提交而报missing go.sum entry
多人同时改多个模块时，replace 怎么用才不翻车
replace 是开发阶段绕过远程拉取的临时方案，但它极易在发布流程中被遗忘，成为 CI 失败的头号诱因。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 路径必须相对于当前
go.mod所在目录，比如主模块go.mod在./app，要替换github.com/yourorg/lib，就得写replace github.com/yourorg/lib => ../lib，而不是./lib -
replace不穿透：如果lib自己又依赖github.com/yourorg/util，而你也正在改util，那必须在lib/go.mod里也加一条replace，否则主模块的replace对util无效 - CI 环境建议加
GOFLAGS="-mod=readonly"，它会让go命令拒绝任何修改go.mod的操作（包括自动补replace），提前暴露问题 - 上线前必须删掉所有
replace行，或用go mod edit -dropreplace=github.com/yourorg/lib清理，不能靠“应该没人提交”赌运气
私有模块和跨仓库依赖总连不上？检查 GOPRIVATE 和 GOPROXY
Go 默认把所有模块请求发给 GOPROXY，遇到匹配 GOPRIVATE 的域名才跳过代理直连 Git。配错顺序或范围，就会出现 module not found 或 unknown revision。
-
GOPRIVATE必须是域名前缀，不是完整 URL，例如git.company.com或git.company.com/myteam，不能写成https://git.company.com -
GOPROXY推荐设为https://proxy.golang.org,direct：公共模块走代理，私有模块 fallback 到 direct（即直连 Git） - 如果公司用了自建 Athens 代理，
GOPRIVATE仍需配置，否则 Athens 会拒绝代理私有模块请求 - 开发者本地环境、CI runner、Docker 构建镜像中的
GOPROXY/GOPRIVATE必须完全一致，建议统一写进项目根目录的.env或 CI 配置模板里
怎么发现团队里有人偷偷升级了依赖却没同步
靠人盯不如靠命令，定期用三行命令交叉验证：
-
go list -m all | grep -v 'indirect' | sort：列出所有直接依赖及其解析版本，对比各成员输出是否一致 -
go list -m -u all：查出哪些模块有可用更新，避免长期卡在旧版引入安全漏洞 -
govulncheck ./...：扫描已知 CVE，结果差异往往暴露了某人本地用了未提交的replace或未tidy的临时改动
真正麻烦的从来不是“怎么同步”，而是“谁改了却没推 go.sum”，或者“replace 写在开发分支但 merge 到 main 前忘了删”。这些点不靠流程卡住，光靠文档提醒基本没用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
