go mod init 失败主因是依赖路径、vendor 状态和内网域名解析冲突；需设 goproxy=direct 或用 replace 映射本地路径，删 vendor 后 tidy，配置 goprivate 并规范 git url 与 tag。
旧仓库直接 go mod init 很可能失败——不是 Go 版本问题，而是依赖路径、vendor 状态和内部域名解析共同导致的模块路径冲突。
为什么 go mod init 会报 no modules found 或 invalid module path
旧仓库通常没有 go.mod，且代码里大量使用类似 import "company.com/internal/utils" 这种非标准路径。Go 1.13+ 默认启用 GOPROXY，但公司内网没配私有 proxy 时，go mod init 会尝试向公网解析 company.com，结果超时或 404。
- 先确认是否在 GOPROXY 范围外：运行
go env GOPROXY，若返回https://proxy.golang.org,direct，说明内网域名走direct，但 DNS 不可达 - 临时绕过：执行
go env -w GOPROXY="direct"（仅限迁移期） - 更稳妥做法：在
go.mod初始化前，用go mod edit -replace=company.com/internal/utils=../internal/utils手动映射本地路径（适用于无版本管理的内部包）
go mod tidy 卡在 verifying ...: checksum mismatch
这是 vendor 目录残留 + 模块校验双重作用的结果。旧项目若有 vendor/，go mod tidy 仍会读取它，但校验时又去拉远程 tag，而内部 Git 仓库 tag 名称不规范（比如带 v 前缀但 Go 要求 v1.2.3 格式），就会校验失败。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 删掉
vendor/再跑go mod tidy（迁移阶段必须这么做） - 检查所有内部依赖的 Git remote URL：必须是完整 HTTPS 地址，不能是
git@或相对路径；例如https://git.company.com/go/libs/log，而非git@git.company.com:go/libs/log.git - 如果内部库没打符合语义化版本的 tag，就用 commit hash 替代：在
go.mod中写成replace company.com/libs/log => https://git.company.com/go/libs/log v0.0.0-20230512142233-a1b2c3d4e5f6
CI 流水线里 go build 失败，提示 cannot find module providing package
根本原因是 CI 环境没配置 GOPRIVATE，导致 Go 尝试从公网代理拉取内部路径模块，但这些路径不在 GOPROXY 白名单里。
- 在 CI 的构建脚本开头加：
go env -w GOPRIVATE="company.com/*,inner.corp/*" - 确保所有内部模块路径都覆盖进 GOPRIVATE（支持通配符，但不支持嵌套通配，
company.com/**无效） - 如果用 GitHub Actions，记得把
go env设置放在run步骤里，而不是只设在 job env 中——后者不被go命令识别
最麻烦的不是命令怎么敲，而是得逐个确认每个 import 路径背后的真实 Git 位置、tag 规范性、以及 DNS 是否能从构建机解析到——漏掉一个，go mod 就卡在那行 import 上不动。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
