Git子模块在Go中仅用于源码快照管理，不参与Go模块依赖解析；正确复用方式是将子模块发布为独立Go模块并用go get引入。
Go 本身不支持 Git 子模块作为构建依赖——go build 和 go mod 完全忽略 .gitmodules 和子模块检出状态。你不能靠 git submodule update --init 让 go run 自动识别子模块里的包。
Git 子模块在 Go 项目中实际起什么作用？
它只负责「源码快照管理」，即把另一仓库的某次提交固定到主仓库的某个路径下，方便人工查看、调试或离线开发。Go 的模块系统（go.mod）对此无感知，也不会从子模块路径里解析 import 路径。
- 子模块内容不会被
go list ./...扫描到 -
import "github.com/your/repo/submodule"这种写法会失败，除非该路径已发布为独立 Go 模块并被go.mod显式 require - 如果子模块本身有
go.mod，它只是个普通 Go 模块，和主项目无关；要复用，得走标准依赖声明流程
想复用子模块代码？正确做法是发布为独立模块
别把子模块当“本地依赖”用。如果你控制子模块代码，应将其作为独立 Go 模块维护：
- 确保子模块根目录有
go.mod，模块路径如github.com/you/utils - 主项目运行
go get github.com/you/utils@main（或指定 tag/commit） - 导入时写
import "github.com/you/utils"，而非相对路径或子模块本地路径 - 子模块更新后，主项目需显式
go get -u github.com/you/utils并提交新的go.sum
这样既能版本锁定，又兼容 go build、CI 缓存、代理（如 GOPROXY）等所有 Go 生态机制。
立即学习“go语言免费学习笔记（深入）”；
什么时候才真需要 git submodule？
仅限以下场景，且必须接受「Go 工具链完全不配合」的事实：
- 嵌入第三方 C 库源码（如 SQLite、OpenSSL），需与 Go 代码共存于同一 repo，用于 CGO 构建
- 归档历史快照（例如把某个已停更的老 SDK 固定在项目里，不打算 import 或编译它）
- 跨语言协作：前端工程 + Go 后端共用一份 proto 定义，子模块存放
.proto文件供双方生成代码
此时务必注意：git clone --recurse-submodules 是必需的，否则子模块目录为空；CI 脚本里漏掉 git submodule update --init 会导致构建失败或静默错误。
常见陷阱与绕过方式
最典型错误是：把子模块放在 ./internal/lib 下，然后在代码里写 import "./internal/lib" —— 这语法非法，Go 不允许相对路径 import。
- 错误提示通常是：
import "./internal/lib": cannot import absolute path或no required module provides package - 试图用
replace指向子模块本地路径？可以，但仅限开发阶段：replace github.com/you/lib => ./internal/lib，且./internal/lib必须有合法go.mod - 上线前必须删掉
replace，改用真实模块路径，否则其他协作者或 CI 无法构建 - 子模块未初始化时，
go mod tidy可能意外成功（因没扫描到该路径），但运行时 panic：找不到包
子模块不是 Go 的依赖管理方案。它的存在，意味着你要多维护一层 Git 状态，而 Go 工具链对此视而不见——这点最容易被忽略，也最难调试。
