不推荐。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，这步会失败。
