灰度测试无需修改主版本号，可通过replace本地路径或伪版本锁定分支实现依赖隔离；需避免replace与伪版本混用，CI中禁用replace，并配合代码层分流与监控。
灰度测试不需要动主版本号，Go 模块本身不提供“灰度发布”能力，但你可以用模块依赖的隔离机制，让新逻辑只被部分调用方加载——关键不是升级 go.mod 里的主模块版本，而是控制谁依赖它、怎么依赖它。
用 replace + 本地路径做灰度依赖注入
想让某个服务（比如 order-service）临时用上新功能，又不想把它整个升级到 v2，最直接的方式是用 replace 把它的依赖指向你本地正在开发的模块分支或目录。
- 在
order-service/go.mod里加一行：replace github.com/yourorg/payment => ./local/payment-v2 -
./local/payment-v2是你本地 checkout 出来的、带灰度逻辑的 payment 模块副本，go mod tidy后会自动拉入 - 这个替换只对当前模块生效，不影响其他服务，也不需要发布新 tag 或改主版本号
- 上线前删掉
replace行，再go mod tidy恢复为正式版本即可
用伪版本（pseudo-version）锁定灰度分支
如果灰度逻辑已 push 到远端分支（比如 feat/gray-payment），可以用伪版本让依赖精确指向那个 commit，而不是等它打 tag。
- 执行：
go get github.com/yourorg/payment@9a2b3c4d（commit hash） -
go mod tidy会自动生成类似v0.0.0-20260725143210-9a2b3c4d5e6f的伪版本，并写入go.mod - 这个伪版本只表示「某次提交」，不触发主版本号变更，也不会被
go get -u自动升级 - 注意：别用
go get github.com/yourorg/payment@feat/gray-payment—— 分支名不稳定，CI 构建时可能因分支删除或 force push 失败
避免 replace 和伪版本混用导致依赖不一致
同一模块在多个地方被不同方式引入，容易让 go list -m all 显示冲突，甚至编译失败。
- 检查是否在父模块和子模块中都写了
replace—— 只保留最上层的，子模块里删掉 - 别在一个项目里同时用
replace指向本地路径，又用伪版本指向远端 commit，go 会优先取replace，但行为不可预期 -
go mod graph | grep payment可快速查出payment被哪些模块以什么版本引入，确认是否唯一 - CI 环境里禁用
replace（通过GOFLAGS=-mod=readonly），否则本地调试用的路径替换会污染构建结果
真正难的是灰度逻辑本身的边界控制：模块能替，但函数调用路径、context 透传、错误处理这些，还是得靠代码里显式判断。依赖层面的“灰度”，只是把新代码塞进去的第一步，后面分流、降级、监控一个都不能少。
