go mod init 只创建 go.mod 文件，不生成 vendor 目录；需显式执行 go mod vendor 才能生成并更新 vendor/ 中的依赖。
go mod init 之后为什么 vendor 目录没生成
执行 go mod init 只会创建 go.mod 文件，不会自动生成 vendor 目录——这是常见误解。vendor 是可选机制，需显式触发。
- 要生成 vendor 目录，必须运行
go mod vendor -
go mod vendor会把当前模块依赖的所有包（含 transitive 依赖）拷贝到项目根目录下的vendor/子目录 - 如果项目里已有
vendor/但内容不全，go mod vendor会覆盖更新，而非增量补充 - 注意：启用 vendor 后，Go 工具链默认优先使用
vendor/中的代码（除非用-mod=readonly或-mod=mod覆盖）
go.mod 中 replace 语句怎么写才生效
replace 用于临时替换依赖路径或版本，但它的作用范围和加载顺序容易出错。
- 必须写在
go.mod文件末尾，在require块之后，否则会被忽略 - 格式为：
replace old/path => new/path v1.2.3或replace old/path => ./local/dir - 本地路径替换（
./xxx）必须是相对路径，且目标目录下要有合法的go.mod（或能被 Go 自动识别为模块） - 如果被 replace 的包本身又被其他依赖间接引入，而那些依赖指定了不同版本，Go 会按“主模块优先”规则统一使用 replace 后的版本——这可能导致兼容性问题
如何避免 go.sum 被意外提交导致 CI 失败
go.sum 记录了每个依赖模块的校验和，它不是“锁文件”，但对构建可重现性至关重要。误操作常引发校验失败。
- 不要手动编辑
go.sum；它应由go命令自动维护 - 运行
go build、go test、go get等命令时，Go 会按需更新go.sum；若发现不一致，会报错如checksum mismatch - CI 中建议加一步
go mod verify，确保本地go.sum与远程模块一致 - 如果团队多人协作，遇到
go.sum冲突，不要直接删掉重生成；应先go mod tidy，再提交变更后的go.sum
多模块项目中如何让子目录也参与依赖解析
当项目包含多个可独立构建的子模块（如 cmd/app1、internal/pkg），默认只有根目录的 go.mod 起作用。
立即学习“go语言免费学习笔记（深入）”；
- 子目录不需要自己的
go.mod，除非它要作为独立发布模块（例如别人go get github.com/you/repo/submod） - 若子目录确实需要独立模块行为，可在其中运行
go mod init github.com/you/repo/submod，但要注意：父模块无法再直接 import 这个子模块，除非用完整路径 - 更常见做法是保持单模块结构，在根
go.mod中通过require显式声明所有用到的外部依赖，并用go mod tidy清理未使用的项 - 子命令入口（如
cmd/xxx/main.go）只需保证 import 路径正确，Go 会自动从根模块解析整个依赖图
go mod init github.com/yourname/project go mod tidy go mod vendor # 如需 vendor 支持
依赖管理真正的复杂点不在初始化命令本身，而在模块路径语义、replace 的隐式传播、以及 go.sum 校验失败时如何定位具体是哪个间接依赖出了问题。
