Go 1.27 go.mod 重复 require 怎么收口：direct 与 indirect 分组的可验证结果

升级到 Go 1.27 后，团队最先看到的往往不是编译错误，而是 go.mod 的几个 require 块被重新排了版。这个变化很容易被误判成“依赖被删了”。先留住升级前的 diff，再看模块集合和版本，通常会发现真正变化只是 Go 1.27 的模块整理规则开始生效。

升级后先确认影响面：依赖没有丢，只是布局改变

一次版本升级中，go.mod 从四个 require 块变成两个，旁边的注释位置也动了。这里别急着手工恢复旧布局，先把升级前后的文件保存下来，重点检查三件事：module 路径是否变化、每个模块的版本是否变化、go.sum 是否出现无法解释的新校验项。

如果差异只集中在分组、空行和依赖注释附近，而模块路径与版本集合保持一致，它更像格式规范化。反过来，某个模块版本真的升降、路径消失，才需要继续追查 indirect 关系或上游版本选择。

从 go.mod 变化倒推触发条件：Go 1.27 的 tidy 规则

Go 1.27 的发布说明明确提到：当模块的 go 指令为 1.27 或更高版本时，go mod tidy 会自动合并重复的 require 块，形成 direct 和 indirect 两个标准分组。依赖上的注释也会跟随关联指令保留；混合标记的注释会归到新的 direct 分组。

module example.com/order

go 1.27

require (
    example.com/api v1.4.0
)

require (
    example.com/log v0.9.2 // indirect
)

这里的关键不是块的数量，而是依赖归属。go.mod 是模块文件边界，go 1.27 是整理规则的开关，go mod tidy 负责把 require direct 与 require indirect 收敛成稳定布局。若一个注释同时说明两种依赖，别只按它原来的行号判断归属。可以把这组关系看成“模块文件边界”与“依赖分组边界”：前者约束文件和版本，后者解释 direct、indirect 以及依赖注释。

用 go list 和差异检查排除真实依赖问题

确认规则后再做一次语义检查。go list -m all 给出当前模块图，适合观察模块是否意外增删；git diff -- go.mod go.sum 则负责把版本变化、校验变化和格式变化分开。两者都没有异常时，才可以把这次调整归类为模块文件整理。

go list -m all
git diff -- go.mod go.sum
go mod tidy
git diff --check

不要只看 tidy 之后的文件。先看 tidy 前的模块列表，再看 tidy 后是否仍能对应；如果出现版本漂移，先确认工具链、代理和工作区是否一致，而不是把所有差异都归咎于 require 合并。

把修复动作放在模块边界：规范化 require 块

修复动作可以很小：保留业务依赖的注释，允许 go mod tidy 生成最终分组，然后在提交中只审查模块文件相关差异。手工把 indirect 依赖删掉，可能只是把它从显式记录变成下一次 tidy 又会出现的间接依赖，反而增加噪声。

在依赖升级 PR 中，我更建议把 go mod tidy、go list -m all 和 git diff 放在同一组检查里。direct 依赖、indirect 依赖 是整理后的静态边界，go list -m all 是模块集合信号，git diff 是提交审查信号，三者不要互相替代。这里有三个判断组：整理动作、验证信号、工具链边界；它们分别回答“怎么收口”“有没有改语义”“谁在决定结果”。

在 CI 中防止旧工具链把格式改回去

最后处理最常见的复发原因：开发机已经是 Go 1.27，CI 镜像却还在使用旧工具链。这样同一份模块文件可能在本地被收口，到了 CI 又产生另一套差异。把 Go 版本写进构建镜像或工作流配置，并在依赖变更任务中固定执行 tidy 和差异检查，结果会稳定很多。

旧工具链可以作为兼容性对照，但不要让它决定新模块的最终格式。升级 PR 里单独展示 go.mod 与 go.sum 的 diff，审查者就能快速确认这是布局调整还是依赖语义变化。

相关问题

Go 1.27 会删除 go.mod 里的 indirect 依赖吗？

不会因为“合并 require 块”就自动删除有效依赖。它会整理分组；是否保留某项仍取决于模块图和源码引用。

只运行 go mod tidy，不运行 go list -m all 可以吗？

可以完成整理，但不利于解释差异。依赖升级 PR 最好补一次模块列表检查，确认没有把格式变化误当成版本变化。

项目还没升级到 Go 1.27，需要手动合并 require 块吗？

不建议为了追求新布局手工改。先按项目当前工具链保持可复现，升级工具链时再让对应版本的 tidy 统一整理。

这次排查的落点很明确：先确认模块集合，再接受 Go 1.27 的分组规范，最后用统一 CI 工具链固定结果。这样既保留依赖注释，也能让每次模块文件变化都说得清楚。