不能靠go mod init加go mod tidy就完事，核心在于旧项目中未打tag的依赖、硬编码本地路径的replace及被忽略的间接依赖；必须先统一import路径、显式指定commit、清理非法replace，并验证go.sum一致性。
不能靠go mod init加go mod tidy就完事，版本错乱几乎必然发生——核心在于旧项目里那些没打 tag 的依赖、硬编码的本地路径 replace、以及被忽略的间接依赖。
go.mod 初始化时模块名填错，所有 import 都会失效
旧项目放在$GOPATH/src/github.com/user/repo下，不代表模块名就能写github.com/user/repo。如果代码里实际写的是import "myapp/utils"，那go mod init必须用myapp，否则所有导入路径都解析失败。
- 先运行
grep -r 'import "' . --include="*.go"，确认所有非标准库 import 前缀 - 若发现混用（比如部分文件用
github.com/user/repo/utils，部分用utils），必须统一重写为合法路径再初始化 -
go mod init不接受./或空字符串，也不能用file://或本地绝对路径
go mod tidy 拉到的版本和原来 vendor 不一致
go mod tidy默认走最小版本选择（MVS），而旧vendor/可能是某次dep ensure锁死的特定 commit。常见现象是：编译通过但运行时报undefined: xxx，因为函数签名变了。
- 检查旧
Gopkg.lock或vendor/里关键包的 commit hash，用go get github.com/org/pkg@abcd123显式指定 - 若依赖未打 tag，
go mod tidy会生成v0.0.0-伪版本，此时必须手动在go.mod中补require行并加// indirect注释 - 执行
go list -m all | grep pkgname确认当前解析出的实际版本，别只看go.mod里写的
replace 指向旧机绝对路径，新环境直接 build 失败
迁移后在新电脑上跑go build报cannot find module providing package，八成是go.mod里还留着类似replace example.com/lib => /home/olduser/lib这种路径。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 立刻运行
go mod edit -dropreplace=example.com/lib删掉它，或改用相对路径：go mod edit -replace=example.com/lib=../lib - replace 仅限调试，上线前必须移除；它会让
go.sum失效，且影响整个模块树的依赖解析 - 如果真要保留 fork 修改，正确做法是：先推送到你自己的 GitHub 仓库，打 tag，再用
require example.com/lib v1.2.3+replace临时覆盖，最后go mod tidy
CI 构建失败，其实是 GOPATH 残留命令还在起作用
CI 脚本里还有go get golang.org/x/lint/golint这类命令，Go 1.17+ 已废弃——它会把二进制装进$GOPATH/bin，但 Modules 模式下go install才写入$GOBIN，路径错位导致找不到命令。
- 把所有
go get xxx替换成go install xxx@latest（注意末尾@latest不能省） - 构建命令必须加
-mod=readonly，否则go build可能偷偷改go.mod，CI 里一旦出错很难回溯 - 删除
export GOPATH相关行，Modules 下它已无意义；go env GOPATH输出什么，对构建结果零影响
最常被跳过的一步是：迁移后没验证go.sum是否真实反映依赖哈希。如果用了非官方代理源（比如私有 Nexus），又没配GOSUMDB=off，go build会静默失败——它不会报错，而是跳过校验，后续运行时才暴露问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
