require声明项目真实依赖版本，影响依赖解析；replace仅构建时重写路径，用于本地调试等，不改变require语义，且不适用于标准库或伪版本。
go.mod 文件里 require 和 replace 的实际作用差异
require 声明的是项目真正依赖的模块版本，go build 和 go test 都会据此解析依赖图；而 replace 是构建时的“路径重写”，只影响当前模块的依赖解析，不改变 require 的语义。它常用于本地调试、未发布分支验证或绕过不可达仓库。
容易踩的坑：
-
replace不会自动同步到其他协作者环境，CI 构建失败很常见——必须确保 CI 使用的 GOPROXY 或网络能访问原始模块，或显式把replace提交进go.mod并在 README 里说明 - 如果用
replace指向本地路径（如replace github.com/foo/bar => ./bar），该路径必须存在且含合法go.mod，否则go list -m all会报错no matching versions -
replace不能用于标准库或伪版本（如v0.0.0-20230101000000-abcdef123456）的重定向
为什么 go mod tidy 有时会升级不该升的依赖
根本原因是 Go 模块的最小版本选择（MVS）机制：只要某个间接依赖被更高版本的模块“传递引用”，且满足语义化版本约束，go mod tidy 就会把它提升为直接依赖并锁定最新兼容版。
典型场景包括：
立即学习“go语言免费学习笔记（深入）”；
- 你依赖 A v1.2.0，A 依赖 B v1.1.0；但另一个依赖 C v2.0.0 也依赖 B v1.3.0 —— 此时
go mod tidy会把 B 升到 v1.3.0，并写入require块 - 执行
go get github.com/some/pkg@latest后未加-d，Go 会尝试构建，触发对所有 transitive 依赖的版本推导 -
go.sum中校验和不匹配时，Go 可能回退到更老版本再重试，导致意外降级
控制方法：用 go mod graph | grep 查依赖来源，用 go list -m all | grep pkgname 看当前解析版本，必要时手动 go get pkg@v1.2.0 锁定。
私有模块拉取失败：GOPRIVATE 和 GOPROXY 怎么配才不冲突
GOPRIVATE 是开关，告诉 Go “这些域名下的模块跳过代理和校验”；GOPROXY 是源列表，按顺序查找模块。两者必须配合使用，否则私有模块要么 403，要么被公共代理缓存污染。
推荐配置（shell 中）：
export GOPRIVATE="git.example.com,github.company.com" export GOPROXY="https://proxy.golang.org,direct"
关键点：
-
GOPRIVATE必须是域名前缀匹配（支持通配符*，但不推荐），不能带协议或路径 -
direct在GOPROXY列表末尾表示“如果前面都失败，就直连源站”，但前提是该模块已列入GOPRIVATE，否则仍会走代理并失败 - 若用自建 proxy（如 Athens），需确保其支持私有仓库认证，且
GOPROXY指向它，同时GOPRIVATE仍要设置——否则 proxy 会拒绝转发
go.sum 文件膨胀、校验失败或频繁变动怎么办
go.sum 记录每个模块版本的加密哈希，不是可选文件。膨胀通常是因为大量间接依赖被引入；校验失败多因模块被篡改或镜像不同步；频繁变动往往源于多人未统一 go version 或 GOPROXY 设置。
实操建议：
- 定期运行
go mod verify，失败时用go clean -modcache清空本地缓存再go mod download - 避免手动编辑
go.sum；如需清理无用条目，先go mod graph确认哪些模块真被引用，再go mod tidy -v观察输出中的 “removing” 行 - 团队内统一 GOPROXY（比如都用
https://goproxy.cn），能大幅减少因镜像差异导致的go.sum冲突 - CI 中建议加检查：
git status --porcelain go.sum | grep -q '^??' && echo "go.sum changed" && exit 1，防止漏提交
最常被忽略的是：go.sum 的哈希值与 Go 版本强相关——Go 1.18 和 Go 1.21 对同一模块生成的哈希可能不同，升级 Go 后 go.sum 必然重写，这点必须同步告知所有开发者。
