联合编译依赖版本由go的最小版本选择（mvs）算法统一决策，非手动修改所致；必须在workspace根目录执行go mod tidy并用go list -m all生成deps.lock锁定实际依赖树。
联合编译时依赖版本被悄悄替换，不是你改的，是 Go 自己选的
Go 的模块依赖解析不按“谁先写谁生效”，而是走最小版本选择（MVS）算法。当你把多个模块（比如主项目 + 插件库 + CLI 工具）一起编译（例如用 go build ./... 或多模块 workspace），go list -m all 会重新聚合所有 require 声明，然后挑一个满足全部约束的最低兼容版本——这个版本很可能和你单独构建某个子模块时看到的不一样。
为什么 go mod tidy 在联合编译前失效
单独对每个模块执行 go mod tidy 只能保证该模块自身的 go.mod 闭合，但无法约束跨模块的版本协商结果。尤其当不同模块 require 同一依赖的不同 minor 版本（如 v1.8.2 和 v1.9.0），MVS 会升到 v1.9.0；如果某个模块还 exclude 了 v1.9.0，而另一个模块又强依赖它，构建就会失败。
- 现象：本地单模块 build 成功，联合编译时报
version "v1.9.0" does not match loaded version "v1.8.2" - 本质：不是缓存或
go.sum错误，是 MVS 在 workspace 级别重新计算出的版本冲突 - 关键动作：必须在 workspace 根目录下统一运行
go mod tidy，而不是进子目录各自 tidy - 注意：
go mod vendor不解决这个问题——vendor 只固化当前模块视角下的依赖，不干预 MVS 决策
replace 在 workspace 中的行为很危险
在 workspace 下，replace 指令只对声明它的那个 go.mod 生效。如果你在插件模块里写了 replace github.com/some/lib => ./fork，主模块仍可能拉取远端原始版本，导致类型不匹配或方法缺失。
- 正确做法：所有
replace必须写在 workspace 根目录的go.work文件里，格式为：replace github.com/some/lib => ./local-fix
- 错误做法：分散写在各子模块
go.mod中，MVS 会忽略它们或产生不可预测覆盖 - 副作用：
go.work中的replace会影响所有子模块，包括测试依赖，务必验证go list -m all | grep some/lib输出是否符合预期
如何锁定联合编译的实际依赖树
靠 go.sum 不够，它只记录校验和；靠 go.mod 也不够，它只声明意图。真正起作用的是 go list -m all 输出的实时解析结果。
- 每次 CI 构建前，强制执行：
go mod tidy && go list -m all > deps.lock
- 把
deps.lock提交进仓库，作为联合编译的“事实快照” - CI 脚本中加入校验：
go list -m all | diff - deps.lock
，不一致就 fail - 避免使用
go get -u：它会无视deps.lock，直接升级，破坏可重现性
联合编译的依赖漂移，根源不在工具链不稳，而在开发者默认把多个模块当“独立单元”处理。一旦进入 workspace 模式，就得按“单一体系”管理依赖——go.work 是入口，go list -m all 是真相，deps.lock 是契约。漏掉任何一环，CI 就可能凌晨三点给你发告警。
