应按未来服务边界而非当前单体形态选module path，如预拆用户服务则直接用github.com/company/user-service，避免后续import路径大规模重构。
go mod init 怎么选 module path？别用 github.com/xxx/monolith
模块路径不是随便起的，它直接影响后续拆分时的 import 路径迁移成本。如果一开始用 github.com/company/monolith，等拆出 user-service 时，所有内部引用还得手动改包名——比如 import "github.com/company/monolith/internal/user" 变成 import "github.com/company/user-service"，重构量大且易漏。
正确做法是：从第一天就按未来服务边界规划 module path。例如预判会拆出用户、订单两个服务，直接初始化为：
go mod init github.com/company/user-service
哪怕当前只是单体里的一个子目录，也先用最终服务名。其他模块同理：github.com/company/order-service。这样后续提取代码、剥离依赖时，go mod edit -replace 或迁移仓库后 import 路径基本不变。
- module path 应体现业务域，而非当前项目形态（单体/微服务）
- 避免使用
monolith、backend、main这类泛化词 - 如果暂不确定服务名，可用占位符如
github.com/company/boundedcontext-user，比硬编码更易后期替换
go.sum 文件在拆分过程中为什么必须保留？
拆分不是“复制粘贴代码”，而是逐步解耦。当你把用户逻辑从单体里抽出来独立成服务时，原单体的 go.sum 记录了所有依赖的精确哈希。如果新服务新建 go mod init 再 go get，很可能拉到不同 minor 版本的 gorm 或 ent，导致行为不一致——比如事务默认隔离级别变化、SQL 生成逻辑差异，引发数据不一致。
实操建议：
- 抽离代码时，直接拷贝原项目的
go.mod和go.sum到新服务根目录 - 用
go mod tidy清理未使用的依赖，但不删go.sum；它不是“锁文件”而是校验凭证 - 若需升级某依赖，务必在新服务中单独
go get并验证，而不是复用旧版本
如何用 replace 临时桥接单体与待拆服务？
拆分是渐进过程，不可能停机重写。常见场景：订单服务要调用用户服务的认证逻辑，但用户服务还没完全独立部署。这时不能硬编码 HTTP 地址或写一堆条件编译，而是用 Go Modules 的 replace 做本地桥接。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
假设你正在开发 order-service，它需要调用尚未拆出的用户逻辑，而该逻辑还在单体仓库的 internal/user 下：
go mod edit -replace github.com/company/user-service=../monolith/internal/user
这样 order-service 就能正常 import "github.com/company/user-service"，实际走的是本地路径。上线前再删掉这行 replace，切到真实的 gRPC 客户端实现。
-
replace是临时开发手段，不可提交到主分支的go.mod - 务必配合
// +build !prod或构建 tag 控制，避免误入生产镜像 - 如果 replace 目标含
internal，注意 Go 的 internal 规则仍生效——被 replace 的路径必须能被当前模块 import
为什么 go list -m all 比 go mod graph 更适合查拆分阻塞点？
go mod graph 显示的是依赖拓扑，但拆分卡点往往藏在隐式依赖里：比如订单模块看似只 import 用户模型，却因日志中间件间接依赖了用户服务的配置解析器。这时候 go list -m all 配合 grep 更直接：
go list -m all | grep user
它列出所有被间接拉入的模块，包括 transitive 依赖。再结合 go mod why 定位具体引用链：
go mod why github.com/company/user-service
常见阻塞点：
- 共享的
pkg/common里混着数据库连接池、全局 config、甚至业务实体——必须先拆出纯类型定义包 - HTTP handler 层直接调用另一个模块的 service 方法，形成强耦合，应改为 interface + wire 注入
- 测试文件里 import 了不该跨界的包，导致
go test ./...时意外拉入整套单体依赖
模块边界模糊时，go list 是比图形化工具更可靠的探针。真正难的不是命令怎么敲，而是识别哪些 replace 该留、哪些 go.sum 行该删、以及哪一行 import 其实早该被抽象成接口——这些决定都发生在编辑器里，不在终端里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
