Go全量更新模块依赖时不同操作的结果差异与正确实现方式

go.mod的行数差异本质是两类独立操作的组合结果：

• 更新行为：将依赖版本升级到兼容的最新版本，过程中会新增新版本依赖引入的传递依赖
• 清理行为：扫描源码实际导入关系，移除未被使用的冗余依赖、历史遗留的无效条目

5种测试场景的差异对应如下：

• 仅执行go get -u（19行）：只做更新，完全不做清理。操作基于原仓库自带的go.mod运行，原有冗余require条目全部保留，升级依赖后新增的传递依赖也会直接写入go.mod，无任何删除操作，因此行数最多。
• 依次执行go get -u、go mod tidy（14行）：先完成全量依赖更新，再做清理。go mod tidy会扫描全量源码的实际导入关系，删掉原go.mod里留存的、当前代码已经不再使用的历史依赖，同时整理冗余的indirect标注，因此行数比仅执行go get -u少5行。
• 仅执行go mod tidy（13行）：只做清理，不做版本更新。使用的还是原仓库go.mod里已经锁定的依赖版本，不会升级到最新，因此不会引入新版本依赖带来的新增传递依赖，比上一种情况少1行。
• 手动清空require块后执行go mod tidy（12行）：直接从零开始扫描源码构建依赖图，完全不受原go.mod的历史条目影响，只会生成代码实际用到的最小依赖集，比基于原go.mod做清理的情况少了1条历史遗留的无效条目，行数进一步减少。
• 手动清空require块后执行go get -u（11行）：从零构建依赖图的同时，将所有依赖升级到最新兼容版本。新版本依赖往往会合并、移除旧版本的冗余传递依赖，整体依赖图更小，因此最终go.mod的行数最少。

如果已经确认当前模块可以兼容所有依赖的最新版本，按以下两步操作即可，无需手动修改go.mod内容：

1. 执行go get -u ./...：全量扫描当前模块下所有代码的依赖，将所有直接、间接依赖升级到语义化版本允许的最高minor、patch版本（不会自动跨大版本升级，避免引入破坏性变更）
2. 执行go mod tidy：清理所有源码未实际使用的冗余依赖，补全升级后新增的必要传递依赖，自动整理indirect依赖的标注，保证go.mod和实际代码的导入关系完全一致。

常见误区 #

• 仅执行go get -u不会清理冗余条目，最终生成的go.mod会保留大量历史遗留的无效内容，不是最优结果
• 仅执行go mod tidy不会升级依赖版本，只会同步现有依赖和代码的关系，不符合全量更新的需求
• 手动清空go.mod的require块属于非常规操作，会丢失原有依赖的历史约束（比如特意锁定的补丁版本、临时的replace规则上下文），不建议在常规更新流程中使用

内容的提问来源于stack exchange，提问作者Zombo