go模块路径发布后不可随意修改，必须通过语义化版本（如/v2）升级而非重命名；v2+需显式带后缀并置于独立子目录；接口兼容性比包结构更重要；go.work仅用于本地开发协同，不替代正式发布流程。
模块路径一旦发布就不能随意修改
Go 模块的 module 声明（如 module github.com/user/project）是其唯一标识，被所有依赖方硬编码引用。一旦推送到公开仓库并被他人 go get，就相当于 API 的一部分。强行改路径（比如从 github.com/user/proj 改成 github.com/user/project/v2）会导致下游 go.mod 中的 require 语句失效，go build 直接报错：require github.com/user/proj: version "v1.2.3" invalid: module contains a go.mod file, so major version must be compatible。
- 新功能迭代优先走语义化版本升级（
v1→v2），而非重命名模块路径 - 若真需路径变更（如组织迁移），必须同步发布重定向模块（
github.com/old/path中保留仅含replace的go.mod）并明确标注弃用 - 内部私有模块也建议按此约束，避免团队协作时因本地
replace漏配导致构建不一致
v2+ 版本必须用 /v2 后缀且独立目录
Go 要求 v2+ 模块路径显式包含 /v2（或 /v3 等），且对应代码必须放在 ./v2/ 子目录下——这不是约定，是 go mod 工具的强制解析规则。否则 go list -m all 会拒绝识别，go get github.com/user/project/v2 会提示 unknown revision v2.0.0。
- 正确结构：
project/ ├── go.mod # module github.com/user/project ├── main.go └── v2/ ├── go.mod # module github.com/user/project/v2 └── stuff.go -
v2/go.mod中的module行必须带/v2，不能省略或写成v2.0.0 - 不要试图用
replace在 v1 的go.mod里“模拟” v2，这会让依赖图混乱且无法被公共代理（如 proxy.golang.org）缓存
接口兼容性比目录结构更关键
很多团队花大量精力设计“整洁”的包层级（如 internal/、pkg/、domain/），却忽略真正影响长期稳定的，是导出标识符（exported identifiers）的签名变更。哪怕目录完全重排，只要 func DoThing(ctx context.Context, s string) error 的参数、返回值、行为没变，v1 用户就能无缝升级到 v1.9.0。
- 用
gopls或go vet -vettool=$(which staticcheck)检查导出函数/方法的签名漂移 - 对核心接口（如
type Store interface { Get(key string) ([]byte, error) }）做轻量契约测试，确保 v1.x 和 v2.x 实现能互换 - 避免在 v1 中为“未来扩展”预留未实现的接口方法，这会锁死后续版本的演进空间
go.work 适合多模块协同但不解决发布问题
当项目拆分成多个模块（如 github.com/user/core、github.com/user/cli、github.com/user/web），用 go.work 可以统一管理本地开发，绕过频繁 go mod edit -replace。但它只作用于本地 go build 和 go test，不影响 go publish 或他人拉取行为。
立即学习“go语言免费学习笔记（深入）”；
-
go work use ./core ./cli ./web后，所有子模块的修改实时可见，适合快速验证跨模块改动 - 发布前仍需确保每个子模块的
go.mod正确声明require关系，且版本号与实际 tag 匹配 - CI 流程中应禁用
go.work，用纯净环境执行go mod download && go build，防止本地替换掩盖依赖问题
模块路径和版本后缀是 Go 生态的刚性契约，不是风格偏好。真正难的不是怎么拆，而是每次 git tag 前，想清楚这个 commit 是否真的需要新版本号——多数时候，一个修复 bug 的提交，只需要 v1.8.1，而不是新建 v2。
