go mod 重构成败取决于模块边界与业务变化频率一致、接口契约稳定及 replace 是否被滥用；replace 可模拟模块拆分，但需指向真实路径并避免长期挂载，跨模块调用必须通过接口而非内部路径。
go mod 不是重命名文件夹的开关，也不是拆服务的倒计时。真正影响重构成败的，是模块边界是否与业务变化频率一致、接口契约是否稳定、以及 go.work 或 replace 是否被当成“临时补丁”长期挂着。
用 replace 模拟模块拆分，别急着发版
单体项目里想把 user 拆成独立模块？先别建新仓库、别打 tag。在根目录 go.mod 里加两行：
replace example.com/project/user => ./internal/domain/user replace example.com/project/order => ./internal/domain/order
这样其他包就能 import "example.com/project/user"，且 go test、go vet 全部走本地路径。关键点：
- 所有
replace必须指向真实存在的本地路径，否则 CI 会静默失败 -
go list -m all能验证是否生效：看到example.com/project/user v0.0.0-00010101000000-000000000000这类伪版本，说明成功 - 一旦某模块要交由其他团队维护，再把它移出、初始化独立
go.mod、打v1.0.0tag —— 此前所有改动都在主干，无分支同步成本
跨模块调用必须走接口，禁止直连 internal/xxx
常见错误：user/service.go 直接 import "example.com/project/internal/order/repo"。这等于把实现细节钉死，后续 order 换数据库或加缓存，user 就得跟着改。
正确做法：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在
user/interface.go定义它真正需要的能力，比如type OrderCreator interface { Create(ctx context.Context, req *OrderReq) error } - 让
order模块提供一个NewOrderCreator()工厂函数，返回满足该接口的实例 -
user只依赖user/interface.go，不 import 任何其他模块的内部路径 - 测试时直接传入 mock 实现，不用启动 DB 或 HTTP server
别让 go.work 成为隐式依赖的温床
多人协作时，有人本地加了 go.work 指向未提交的 lib 分支，CI 却跑在 clean 环境下 —— 这时 go build 会突然失败，报错找不到符号。
安全用法：
-
go.work只用于开发机本地联调，**绝不提交到主干分支**；CI 流水线始终以go.mod+replace为准 - 如果必须共享 workspace 配置（如 monorepo），把
go.work放进.gitignore，改用文档说明如何初始化：go work init ./service-a ./lib-b - IDE（如 Goland）能识别
go.work，但gopls有时会卡在旧缓存上 —— 遇到跳转失效，先go work use -r清理再重试
模块名不是路径别名，它代表契约稳定性
你给模块起名 example.com/project/user，就等于承诺：只要这个路径不变，它的公开 API（导出类型、函数签名、错误类型）变更必须遵守语义化版本规则。
所以：
- 别把快速迭代的实验性功能塞进已发布的模块路径下；新建
example.com/project/experimental/xxx更安全 - 如果
user模块的User结构体字段从Name string改成FullName string，这不是 bug 修复，是v2级别变更，必须升主版本 -
internal/pkg/log这类基础包，一旦被 3 个以上业务模块强依赖，就要警惕 —— 它正在变成“隐式核心”，此时应考虑拆成pkg/logger和pkg/zapadapter，明确谁负责抽象、谁负责实现
replace，或者某个 handler 里还藏着对 order/internal/repo.DB 的直接调用 —— 这些细节不清理，模块就只是目录名，不是边界。 
