真正卡住微服务落地的是初始化依赖、跨包调用和proto定义三处；需通过go list分析依赖图，确保模块具备独立生命周期、连接池与配置，用接口隔离领域边界，client封装下游调用并集成服务发现，proto按服务粒度拆分且严格版本兼容。
拆分服务不是起新 repo 或改 import 路径就能解决的事——真正卡住落地的，是初始化依赖、跨包调用和 proto 契约这三处。你跑通 go run cmd/userapi/main.go 不代表它已经是服务，得先验证它能不能独立启停、独立配 DB、不碰其他服务的 internal。
怎么判断一个 Go 模块该不该拆成独立服务
别看它叫 user 就急着建 user-service。先执行：go list -f '{{.Deps}}' ./cmd/main，画出依赖图：
- 如果
user初始化强依赖order.Repository或共享同一个*sql.DB实例，那它现在只是模块，不是服务 - 能拆的前提：有自己完整的生命周期（启动/关闭 DB/Redis/第三方 SDK）、不共用连接池、配置项可独立覆盖
- 常见错误：在
user.Service里直接调order.GetByID()—— 这说明领域边界没划清，得先抽象出order.OrderReader接口
proto 文件怎么写才不会变成新的单点故障
很多团队把所有 .proto 塞进一个 api 仓库，结果改个字段全链路得同步发版。这不是微服务，是 proto 单体：
-
.proto必须由服务提供方定义，放在统一目录如api/user/v1/user.proto，禁止散落在各服务internal/下 - 禁止定义聚合接口，比如
rpc GetUserWithOrders(...)—— 这等于把组合逻辑强绑在契约上，下游一加字段你就得改 proto、发版、等客户端升级 - 版本管理写进包名，如
package userpbv2;，而不是靠 URL 路径/api/v2/user（gRPC 不认这个） - 字段变更必须向后兼容；否则旧客户端可能 panic 在
Unmarshal阶段，错误信息只是"proto: cannot parse invalid wire-format data"
HTTP 调用下游服务时为什么不能硬编码地址
http.Get("http://order-svc:8080/v1/order/123") 这种写法本地跑不通，上线扛不住节点故障，更没法做超时、重试、熔断：
立即学习“go语言免费学习笔记（深入）”；
- 所有下游调用必须封装成 client 接口，例如：
type OrderClient interface { GetOrder(ctx context.Context, id string) (*Order, error) } - client 实现里才用
http.Client或 gRPC stub；初始化交给 DI 容器（如dig）或构造函数链，绝不在 handler 里new - 生产环境必须走服务发现：Consul +
go-micro/registry/consul，或 DNS SRV 记录；开发环境用 localhost + 端口映射，别写死 host - 硬编码地址会导致链路追踪 tag 串不起来，超时控制失效，重试策略无法注入
真正难的不是写代码，是让每个服务在编译期就“不认识”其他服务的实现细节——interface 抽象、client 封装、proto 契约先行，这三件事漏掉任何一环，拆出来的就是分布式单体。
