应显式指定合法模块路径，如 go mod init github.com/yourorg/yourproject；清理 vendor 目录并验证 GO111MODULE=on；replace 须用绝对路径且本地有匹配 go.mod；依赖混乱时优先用 go mod graph 和 go list -m all 分析。
go mod init 报 “cannot determine module path” 怎么办
直接原因是 Go 不知道该给模块起什么名字，它会尝试从当前路径、go.work、环境变量甚至 Git remote 推断，但老旧项目往往没配 Git 或路径不规范，导致失败。
最稳的解法是显式指定合法模块路径：
- 运行
go mod init github.com/yourorg/yourproject（哪怕只是内部项目，也必须用域名格式） - 别用
./myproj或/home/user/myproj这类路径——Go 模块路径不是文件系统路径 - 执行后立刻检查
go.mod第一行：module github.com/yourorg/yourproject，确保它和未来所有import语句的前缀完全一致
vendor 目录还在，Modules 就没真启用
旧项目习惯用 go vendor，如果迁移时不清理，go build 默认仍优先读 vendor/，等于 Modules 形同虚设——你改了 go.mod 里的版本，实际跑的还是旧包。
验证是否真走 Modules：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先删掉原有
vendor/：rm -rf vendor - 临时禁用 vendor 测试：
go build -mod=readonly，如果报缺 module 错误，说明它终于在查go.mod了 - 确认
GO111MODULE=on（Go 1.16+ 默认开启，但旧 shell 可能残留off或auto）
replace 路径写错，本地调试根本没生效
开发中常想用 replace 把某个依赖指向本地修改版，但新手容易漏掉版本号或写相对路径，结果 go build 还是拉远端包。
正确写法必须满足三点：
-
replace左侧是原始模块路径 + 版本号，例如：github.com/some/lib v1.2.3 - 右侧是绝对路径（不能以
./开头），例如：=> /home/user/myfork/lib - 被替换的本地目录下必须有合法的
go.mod文件，且module声明要和左侧路径兼容
依赖图混乱时，go mod graph 比 go mod tidy 更有用
go mod tidy 只管补全缺失依赖，但老旧项目常存在隐式循环引用、多版本共存、间接依赖冲突等问题，光 tidy 不解决问题。
先看真实依赖结构：
- 运行
go mod graph | grep 'problematic-package'快速定位谁在拉哪个版本 - 结合
go list -m all | grep 'old-version'找出未升级的遗留依赖 - 注意
go.sum里同一模块多个哈希值，意味着不同子模块用了不同版本——这是 runtime panic 的高发源头
真正难处理的不是命令怎么敲，而是旧项目里那些没写进 import 却通过 _ 导入触发的隐式依赖，它们不会出现在 go mod graph 里，得靠 go build -x 看实际加载了哪些 .a 文件。
