go modules 是强制依赖契约，不是可选替代；submodule 仅是 git 路径快照，不参与 go 构建系统，需 replace 显式接入且无法跨项目继承，缺乏版本语义与安全校验。
Go modules 是强制依赖契约，不是“可选替代”
Go 1.11 起，go mod 就不是功能开关，而是构建系统认定依赖的唯一入口。没有 go.mod，Go 工具链就无法确认 import "github.com/yourorg/proj/pkg" 指的是本地代码、缓存旧版本，还是压根不存在——它会直接报 no required module provides package。
Git Submodule 完全不在这个体系里：它只是 Git 的路径快照机制，go build 和 go mod tidy 对 .gitmodules 文件视而不见。你 git clone --recurse-submodules 下来，如果没手动 replace，Go 依然找不到包。
- Submodule 不提供版本语义，只存 commit hash；Modules 通过
go.sum锁定校验和，防篡改、防漂移 - CI 环境拉新仓库时，Submodule 需额外配置递归拉取，漏了就静默失败；Modules 只要
go mod download就能还原全部依赖树 - 团队中有人忘了
git submodule update，有人用了--force覆盖子模块，协作成本指数上升
replace 是 Submodule 唯一能“接入” Go 生态的补救方式
如果你非要用 Submodule（比如复用私有 C 库或共享 proto 定义），那必须在父项目的 go.mod 中显式 replace，否则 Go 不认它是个模块。
例如子模块放在 ./third_party/pdf，且它自己有 go.mod（module github.com/rsc/pdf），就得这样写：
立即学习“go语言免费学习笔记（深入）”；
replace github.com/rsc/pdf => ./third_party/pdf
否则 go mod tidy 会去 proxy 查 github.com/rsc/pdf，而不是读本地目录。
-
replace仅对当前模块生效，下游项目go get你的项目时不会继承该重定向 - 子模块目录名必须与
module声明完全一致，否则导入路径不匹配，编译失败 - CI 构建前必须确保子模块已检出（
git submodule sync && git submodule update --init），否则replace指向空目录，go build直接报错
Submodule 导致 import 路径与包名逻辑断裂
Go 的 import 路径 = 模块路径 + 目录相对路径，不是包名。Submodule 让这个映射关系变得脆弱且隐式。
比如你在主项目中 import "github.com/yourorg/proj/utils"，但实际代码藏在 Submodule 的 ./submodules/utils 里——除非你用 replace 把 github.com/yourorg/proj/utils 指向那个路径，否则 Go 根本不会去那里找。
- 开发者容易误以为 “只要目录存在就能 import”，结果本地能跑（因为 GOPATH 缓存或路径巧合），CI 失败
- 重构时移动 Submodule 目录，所有
replace行都要手动更新，极易遗漏 - 包名（
package utils）和导入路径末段（/utils）本应一致，但 Submodule 强行把物理路径和逻辑路径解耦，增加理解负担
Modules 天然支持私有仓库和统一校验，Submodule 需额外运维
私有 Git 仓库用 Modules 只需一行配置：go env -w GOPRIVATE=git.internal.company/*，之后 go get 和 go mod tidy 自动走直连，不碰 proxy。
Submodule 则要为每个私有子模块单独配 SSH key、处理 403、维护 .gitmodules URL 协议（ssh:// vs https://），CI 还得注入凭据才能 git submodule update。
-
go.sum是自动维护的，每次go mod tidy都刷新校验和；Submodule 没有等价机制，commit hash 易被绕过（如git submodule add -f） - 安全响应慢：CVE 修复需同步更新所有 Submodule 的 commit，并手动验证兼容性；Modules 只需
go get -u+go mod tidy，工具链自动处理依赖传递 - 想让别人
go get你的项目？Modules 要求go.mod中的module名与 GitHub 地址严格一致；Submodule 的路径根本不出现在任何 Go 元数据里，对外不可见、不可引用
真正难的从来不是“怎么让 Submodule 跑起来”，而是“怎么让所有人、所有环境、所有时间都以完全相同的方式跑起来”。Modules 把这个问题收进 go.mod 和 go.sum 两行文件里，Submodule 把它散落在 Git 配置、CI 脚本、开发者记忆和 README 的角落里。
