不推荐。Git子模块与Go模块系统语义冲突：子模块锁定特定提交，而go.mod要求语义化版本管理；go get不识别子模块内包，因Go仅从go.mod声明路径拉取；子模块需无go.mod、不可直接import、CI须显式初始化，且go mod vendor不包含其内容。
Git子模块在Go项目中是否推荐使用
不推荐。Go的模块系统（go mod）与Git子模块在语义、生命周期和依赖管理逻辑上根本冲突——子模块强制绑定特定提交，而go.mod依赖解析要求可复现、可升级、可校验的语义化版本。强行混用会导致go build失败、go list -m all显示异常、CI中go mod download跳过子模块路径等问题。
为什么go get无法识别子模块里的包
因为Go工具链默认只从GOPATH或go.mod声明的module path（如github.com/user/repo）拉取代码，不会递归扫描工作目录下的.gitmodules或子目录中的go.mod。即使子模块已检出，只要没被主模块显式require，import "xxx"就会报no required module provides package。
- 子模块路径若未出现在主项目的
go.mod的require块中，Go完全无视它 - 子模块自身有
go.mod时，必须用其定义的module path导入，不能用相对路径或本地文件路径 -
replace指令可临时指向子模块本地路径，但仅限开发调试，不可提交到main分支
替代方案：用replace + go mod edit做本地开发
当需要频繁修改依赖库（比如正在开发的SDK），又不想发版再go get，可用replace将远程module映射到本地子目录（非Git子模块）：
go mod edit -replace github.com/owner/lib=../lib
注意：../lib必须是完整module（含go.mod），且其module声明要与replace左边一致；Git子模块目录若未初始化为独立module，这步会失败。
立即学习“go语言免费学习笔记（深入）”；
- 执行后
go.mod新增replace github.com/owner/lib => ../lib - CI构建前必须删掉
replace行，否则构建环境找不到../lib - 子模块若已存在，先
git submodule deinit -f .再手动复制代码进本地目录更可控
真要用子模块？必须满足三个硬条件
极少数场景（如嵌入固件工具链、生成器模板仓库）需保留子模块，此时必须确保：
- 子模块目录**没有自己的
go.mod**（否则Go会尝试加载它，却因路径不匹配失败） - 主模块的
import路径**不指向子模块内部**，而是通过封装层（如internal/gen）桥接 - CI脚本显式执行
git submodule update --init --recursive，且Go命令运行前确认子模块已就位
即便如此，go mod vendor也不会包含子模块内容，vendor一致性无法保障——这点常被忽略。
