直接修改go.mod中require版本号不生效，必须运行go mod download或go mod tidy触发重新解析与校验，否则go.sum和本地缓存仍指向旧版本，且可能被覆盖或报错。
go.mod 中直接修改 require 行版本号是否生效？
直接改 go.mod 里的 require github.com/some/pkg v1.2.3 行，不一定生效——Go 不会自动校验或拉取该版本，甚至可能在下次 go build 或 go mod tidy 时被回退或覆盖。
真正起作用的是 Go 的模块解析机制：它以 go.mod 为声明，但最终依赖版本由 go.sum 和模块图共同锁定。手动改完必须触发一次「重新解析+校验」流程。
- 改完
require行后，必须运行go mod download或go mod tidy，否则本地缓存和go.sum仍指向旧版本 - 如果目标版本不存在（如 tag 未发布、私有仓库不可达），
go mod tidy会报错：require github.com/some/pkg: version "v1.2.3" invalid: unknown revision v1.2.3 - 若该包被其他依赖间接引入更高版本，
go mod graph可查冲突来源，此时仅改require行可能被 override
用 go get 覆盖指定包版本的正确姿势
go get 是最可靠的手动覆盖方式，它会更新 go.mod、下载模块、更新 go.sum，并处理版本兼容性检查。
- 升级到特定 tag：
go get github.com/some/pkg@v1.2.3 - 回退到旧 commit：
go get github.com/some/pkg@8a1f2c5（需确保该 commit 在模块根目录下有go.mod） - 指向分支（不推荐用于生产）：
go get github.com/some/pkg@main—— 注意这会写入伪版本（如v0.0.0-20230101000000-8a1f2c5），且每次go mod tidy可能刷新 - 执行后务必检查
go.mod是否已更新require行，以及go.sum是否新增对应校验和
私有模块或 fork 后替换依赖怎么写？
当你要用自己 fork 的仓库替代原包，或使用公司内网私有模块时，不能只靠 go get，必须显式 replace。
立即学习“go语言免费学习笔记（深入）”；
- 在
go.mod文件末尾添加：replace github.com/orig/pkg => github.com/yourname/pkg v1.2.3
- 如果 fork 未打 tag，可用 commit：
replace github.com/orig/pkg => github.com/yourname/pkg v0.0.0-20230101000000-8a1f2c5
-
replace仅在当前模块生效，不会影响下游依赖；若下游也需同样替换，得各自配置 - 执行
go mod tidy后，go.sum会记录替换后的模块校验和，而非原始模块的 - 注意：CI 环境若无权限访问私有地址，会卡在
go mod download阶段，需提前配好git凭据或GO_PRIVATE
为什么 go mod edit 不推荐直接改版本？
go mod edit -replace 或 -require 能直接编辑 go.mod，但它是「纯文本操作」，不校验、不下载、不更新 go.sum，容易留下不一致状态。
- 例如：
go mod edit -require=github.com/some/pkg@v1.2.3只改了go.mod，但go.sum还是旧的，后续go build可能失败 - 它适合脚本化批量修改，但人工干预时风险高；真要这么做，后面必须跟
go mod download+go mod tidy - 更隐蔽的问题：某些版本在 go proxy 上不可见（如刚 push 的 tag 尚未同步），
go mod edit不会报错，但后续命令会失败
真正需要手动干预版本时，优先走 go get 或 replace，而不是绕过 Go 的模块生命周期直接硬改文件。最容易被忽略的是 go.sum 的同步——没它，你的版本修改在 CI 或新机器上根本跑不起来。
