Golang模块结构维护与演进策略

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 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。