Go 1.27 go mod tidy 多 require 块怎么整理：直接依赖与间接依赖边界

升级 Go 1.27 后，项目的 go.mod 可能出现一个容易被误解的变化：原来分散的多个 require 块被 go mod tidy 整理成直接依赖和间接依赖两组。这不是依赖版本被随意替换，而是文件结构与依赖角色更清晰了。

多个 require 块为什么会变成两组

go.mod 的 require 声明既可以写成单行，也可以写成块。项目经过手工合并、工具升级或多人协作后，常见情况是文件里出现多个块，直接依赖和传递依赖混在一起。Go 1.27 发布说明明确记录了 go mod tidy 会把多个块整理成标准的 direct 与 indirect 两块。

direct 和 indirect 看的是使用关系

直接依赖通常是当前模块源码明确导入的模块；间接依赖则是由其他模块带入、但仍需要写入模块图以保持版本选择一致的依赖。判断依据来自模块图和源码，不是开发者对“我有没有手动调用过”的主观印象。

module example.com/orders

go 1.27

require (
    example.com/router v1.4.0
    example.com/metrics v0.8.0
)

require (
    example.com/codec v1.2.1 // indirect
)

示例中的 router 和 metrics 是应用代码直接使用的入口，codec 可能由它们继续引入。真实项目的分组以 go mod tidy 根据当前源码、测试文件、构建标签和模块图计算的结果为准。

升级前先固定 go.mod 的可比较状态

不要直接在工作区里运行整理命令后凭肉眼判断。先保存当前分支的变更状态，确认 go.mod 和 go.sum 没有无关修改，再切换 Go 1.27 对同一份源码做整理。这样出现差异时，能区分版本工具带来的格式变化和项目本身的依赖变化。

• 记录当前 Go 版本与模块路径。
• 确认测试文件和构建标签没有被临时移出扫描范围。
• 只把本轮整理产生的 go.mod、go.sum 差异纳入审查。

go mod tidy 整理后应该检查哪些差异

第一眼看 require 块是否被归并，第二眼看依赖角色是否符合源码。若一个应用包已经直接导入某模块，却被整理为 indirect，应先检查导入是否只存在于带构建标签的文件、测试文件或生成代码中；不要为了让文件“看起来整齐”手动删掉注释。

为什么不能手工把 indirect 全删掉

间接依赖仍可能参与最小版本选择、测试构建或代码生成。删除后再运行整理工具，文件可能重新出现；更糟的是，错误的版本选择可能只在特定平台或构建标签下暴露。正确动作是追查是谁引入它、当前模块图是否仍需要它。

把整理差异纳入升级提交

确认差异来源后，再把整理后的两个文件提交到升级分支。代码审查中应说明哪些变化只是 require 块归并，哪些变化涉及版本选择或新增校验和；如果应用依赖生成代码，还要把生成步骤纳入同一份回归记录。

一个实用的验收标准是：依赖块结构符合 Go 1.27 的规范，源码与测试能完成构建，关键测试通过，且差异中的每个模块都能回溯到源码导入或依赖图。达不到这个标准时，先回退整理结果并定位依赖来源。

常见问题

Go 1.27 会自动升级所有依赖吗？

不会。go mod tidy 的主要职责是按当前模块内容整理依赖声明和校验和；版本变化仍应结合模块图与命令输出单独审查。

多个 require 块本身是错误吗？

不一定是错误，但它会让依赖角色和审查差异变得不直观。Go 1.27 的整理行为会把它们归并成更标准的分组。

indirect 依赖能不能从 go.mod 删除？

不能只凭标记删除。先确认模块图、测试、构建标签和生成流程都不再需要它，否则下一次整理可能把它加回来或导致构建失败。

用模块图解释变化，再接受文件整理

Go 1.27 对多个 require 块的整理，解决的是依赖文件长期演化后的可读性问题。升级时把格式归并、依赖角色、校验和以及构建结果放在同一条证据链里检查，才能知道变化是正常维护，还是隐藏了真正的模块版本问题。