不想让 CI 里的依赖整理命令直接改工作区，可以先用：
go mod tidy -diff
它会按当前源码和构建标签计算整理结果，并把和现有 go.mod、go.sum 的差异打印出来，而不是直接改文件。适合放在校验步骤里，发现有 diff 就回头检查提交里是否漏了依赖变更。
环境：Go 1.16+。如果项目依赖特定平台或 build tag，校验时要带上和实际构建一致的参数；另外它会分析测试依赖，别只按生产代码判断。
这个很适合做成 CI 的依赖漂移检查。再补一个容易踩的点：校验环境里的 Go 版本、GOFLAGS 和 build tags 最好跟正式构建固定一致，不然同一个提交在不同 runner 上可能得到不同 diff。若要把结果变成明确的失败条件，也可以把输出重定向到临时文件，再检查文件是否为空，日志会比直接刷终端更好看。
uitfLv1#1 这个很适合做成 CI 的依赖漂移检查。再补一个容易踩的点：校验环境里的 Go 版本、
GOFLAGS和 build tags 最好跟正式构建固定一致，不然同一个提交在不同 runner 上可能得到不同 diff。若要把结果变成明确的失败条件，也可以把输出重定向到临时文件，再检查文件是否为空，日志会比直接刷终端更好看。
如果 CI 有 GOOS/GOARCH 或 CGO_ENABLED 的矩阵，这几个也要显式固定，不能只固定 Go 版本和 build tags。条件导入在不同目标下可能让 tidy 结果不一样。把构建环境参数和正式构建共用一份配置，排查这种依赖漂移会省不少时间。
如果 CI 有多套 GOOS/GOARCH 矩阵，我更倾向只选一套约定好的环境跑 go mod tidy -diff，不要让每个 runner 都拿自己的结果当标准；其他矩阵只负责构建和测试。否则同一提交可能同时报出互相矛盾的依赖 diff。这个规范最好和仓库文档里的支持版本一起写清楚。
Ryan小满Lv1#4 如果 CI 有多套 GOOS/GOARCH 矩阵，我更倾向只选一套约定好的环境跑
go mod tidy -diff，不要让每个 runner 都拿自己的结果当标准；其他矩阵只负责构建和测试。否则同一提交可能同时报出互相矛盾的依赖 diff。这个规范最好和仓库文档里的支持版本一起写清楚。
这个约定挺稳。再补一个现在比较容易忽略的变量：Go 1.21+ 的自动 toolchain 切换。CI 最好明确 GOTOOLCHAIN（比如固定用 runner 上的版本），不然不同环境可能实际跑了不同的 tidy 版本。把 Go 版本、-compat 和这项一起写进 workflow，出现 diff 时定位会更直接。
雾很大Lv1#5 这个约定挺稳。再补一个现在比较容易忽略的变量：Go 1.21+ 的自动 toolchain 切换。CI 最好明确
GOTOOLCHAIN（比如固定用 runner 上的版本），不然不同环境可能实际跑了不同的 tidy 版本。把 Go 版本、-compat和这项一起写进 workflow，出现 diff 时定位会更直接。
GOTOOLCHAIN=local go mod tidy -diff 这个写法也挺适合 CI：先由 runner 明确安装目标 Go 版本，再禁止 tidy 临时下载或切换 toolchain。这样版本没配对时会直接失败，不会悄悄拿另一套工具链算出 diff。若仓库依赖 toolchain 指令要求更高版本，就别盲目用 local，把 workflow 里的版本和项目支持范围对齐更稳。
Zoe_JayLv1#6
GOTOOLCHAIN=local go mod tidy -diff这个写法也挺适合 CI：先由 runner 明确安装目标 Go 版本，再禁止 tidy 临时下载或切换 toolchain。这样版本没配对时会直接失败，不会悄悄拿另一套工具链算出 diff。若仓库依赖toolchain指令要求更高版本，就别盲目用local，把 workflow 里的版本和项目支持范围对齐更稳。
私有模块场景还要把 GOPRIVATE、GONOSUMDB 和 GOPROXY 这类环境也固定下来。否则同一个提交可能因为代理或校验配置不同，表现成下载失败，甚至让人误以为是 tidy diff。把这些变量和 workflow 里的 Go/toolchain 版本放在同一处维护，排查会更顺。