直接显式指定模块路径：go mod init github.com/your-org/your-project，确保module名合法、全小写、无空格，并与import路径一致，避免依赖自动推导。
go mod init 报 “cannot determine module path” 怎么办
根本原因是 Go 不知道该给你的项目起什么名字，它不会猜，也不该猜。老项目往往没配 Git、路径不规范，或者 go.mod 为空，go mod init 就卡住。
直接显式指定路径，别绕弯：
-
go mod init github.com/your-org/your-project—— 域名格式必须合法，哪怕只是占位，后续再开源也来得及 - 别用
./myproj或/home/user/myproj，Go 模块路径不是文件系统路径 - 执行完立刻检查
go.mod第一行：module github.com/your-org/your-project，确保和代码里所有import的前缀完全一致 - 如果项目已推 GitHub，先确认
git remote get-url origin返回正确地址，再跑go mod init，但别依赖这个自动行为
vendor 目录残留导致 go build 还走旧依赖
这是迁移后最隐蔽的失效点：你改了 go.mod 里的版本，go build 却没生效，十有八九是 vendor 在“偷偷干活”。
旧项目习惯 go vendor，升级 Modules 后若不清掉，Go 默认仍优先读 vendor/，等于白迁。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 第一步：删干净
rm -rf vendor - 第二步：临时验证是否真走 Modules：
go build -mod=readonly，如果报缺 module，说明终于查go.mod了 - 第三步：想彻底弃用 vendor？别加
// +build !vendor，那没用；真正有效的是——不再运行go mod vendor，也不提交vendor/到 Git - CI 环境若必须离线构建，才考虑
go mod vendor，且需配套配置私有GOPROXY和校验机制
replace 本地调试时路径不生效
开发中常要临时替换某个依赖为本地修改版，replace 是标准做法，但写错就白忙活。
常见错误：用相对路径、漏版本号、路径拼错、没同步 go mod tidy。
-
replace github.com/old/lib => ./local-fix❌ 错 ——./local-fix是相对路径，Go 不认 -
replace github.com/old/lib => ../local-fix❌ 错 —— 同样是相对路径，且上级目录可能不存在 -
replace github.com/old/lib => /abs/path/to/local-fix✅ 可行，但跨机器不可移植 -
replace github.com/old/lib => ./local-fix v1.2.3✅ 推荐 —— 必须带版本号，且./local-fix是相对于当前go.mod的合法子目录 - 写完
replace后，一定要go mod tidy，否则不会生效
migrate down 失败后 schema_migrations 表状态卡住
migrate down 不是“撤销上一条 SQL”，而是按序号倒着执行 .down.sql。一旦某条失败（比如删表时外键未清理），工具会停住，但已成功执行的 down 步骤仍写入 schema_migrations 表 —— 导致后续 up 认为“这部分已应用”，跳过关键修复。
- 开发环境可手动清空
schema_migrations表重试，但生产环境绝不能这么干 - 真正安全的做法：每个
.down.sql必须可逆，避免DROP COLUMN、TRUNCATE等不可逆操作 - 字段重命名、类型变更等复杂操作，应拆成两步：先加新字段 + 迁移数据，再删旧字段 —— 这样 up/down 都可控
- 执行前必先
migrate -path ./migrations -database "$DB_URL" version确认当前版本，防止误操作
go build 实际走哪条路径 —— 它既不看 go.mod 是否存在，也不管你有没有删 vendor，只认当前是否存在 vendor/ 目录和 -mod 参数。 
