v2+版本必须改导入路径，因为go不支持同一模块路径下多主版本共存；若不将module声明为github.com/user/lib/v2并同步更新所有import为/github.com/user/lib/v2，go仍视其为v1，导致go get失败、版本不可见或构建报错。
为什么 v2+ 版本必须改导入路径
Go 不支持同一模块路径下多个主版本共存。如果你发布 github.com/user/lib 的 v2.0.0，但没改模块路径，Go 工具链仍把它当 v1 处理——go get github.com/user/lib@v2.0.0 会报错或静默降级，因为模块路径没体现 major 变更。
真正起作用的是模块声明里的 module 行：
✅ 正确：在 v2/go.mod 中写 module github.com/user/lib/v2
❌ 错误：在 v2/go.mod 中仍写 module github.com/user/lib
- 所有 v2+ 的 import 语句必须带
/v2后缀，比如import "github.com/user/lib/v2" - 旧代码引用
github.com/user/lib不会自动升级到 v2，天然隔离 - v1 和 v2 在
go list -m all输出里是两个独立条目，互不干扰
如何验证主版本是否被 Go 正确识别
光改 go.mod 不够，得确认 Go 工具链真把它当新模块处理。常见误判是：本地能编译，CI 却失败，或 go mod graph 显示混乱。
- 运行
go list -m github.com/user/lib—— 应返回 v1.x.x；再跑go list -m github.com/user/lib/v2—— 应返回 v2.x.x，否则 v2 没被注册为独立模块 - 检查
go.mod文件是否在v2/子目录下，且该目录有完整模块文件（go.mod、go.sum），不是仅靠 tag - 用
go mod download github.com/user/lib/v2@v2.1.0测试能否拉取；若报invalid version，大概率是模块路径或 tag 格式不对（如打了v2.1.0tag，但go.mod里是module github.com/user/lib）
replace 能绕过主版本隔离吗
不能。你写 replace github.com/user/lib => github.com/user/lib/v2 是非法语法——replace 左侧必须是模块路径，而 github.com/user/lib 和 github.com/user/lib/v2 是两个不同路径，无法用 replace 关联。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 想让旧项目用 v2？必须改它的 import 语句，把
github.com/user/lib替成github.com/user/lib/v2，再更新go.mod的require - 临时调试可用
replace github.com/user/lib/v2 => ./v2，但这是对 v2 路径本身的替换，不影响 v1 - 别试图用
exclude github.com/user/lib来“屏蔽 v1”——这只会让依赖解析失败，不是隔离
最容易被忽略的发布细节
主版本隔离失效，往往卡在发布动作本身。tag 名、目录结构、go.mod 内容三者必须严格一致。
- tag 必须形如
v2.1.0（不是2.1.0或lib-v2.1.0），且打在v2/目录的 commit 上 - GitHub/GitLab 仓库根目录下不能有
v2/go.mod同时又存在根目录的go.mod—— 这会让 Go 认为整个仓库是一个模块，v2 只是子目录，而非独立模块 - 如果用 Go Workspaces（
go.work），确保 workspace 中包含的是v2/目录，而不是仓库根目录，否则go run ./...可能误加载根目录的 v1
主版本隔离不是配置开关，而是路径契约：路径变了，才是新模块。任何环节漏掉这个契约，隔离就断了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
