微服务拆分不是按业务名词切，而是看通信边界和部署单元
单体 Go 服务一旦开始拆，最容易犯的错是照着“用户中心”“订单服务”这种名词直接建 repo、起新进程——结果接口耦合照旧，数据库还共用，只是多了一层 HTTP 调用。真正的拆分依据只有两个：谁必须和谁一起发布、谁的数据变更不能被别人直接读表。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先画出当前
main.go启动时初始化的所有模块依赖图，标出哪些初始化逻辑强依赖 DB 连接、Redis 客户端或第三方 SDK；这些模块如果共享同一份配置或连接池，就还不适合物理隔离 - 检查所有跨包调用：如果
user.Service直接调用了order.Repository，说明领域边界没划清，得先通过接口抽象（如order.OrderReader）解耦，再考虑是否拆进程 - 一个 Go module 不等于一个服务；可以先用多
main入口（cmd/userapi/main.go、cmd/usersvc/main.go）共用同一仓库，但二进制分离部署，这是最轻量的演进起点
Go 里 HTTP 服务拆分后，别在 handler 层硬编码其他服务地址
常见错误现象：http.HandleFunc("/pay", func(w http.ResponseWriter, r *http.Request) { resp, _ := http.Get("http://order-svc:8080/v1/order/123") }) —— 这种写法会让服务失去弹性，无法做重试、超时、熔断，且本地开发时根本没法联调。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有下游调用必须封装成 client 接口，例如
type OrderClient interface { GetOrder(ctx context.Context, id string) (*Order, error) }，实现里才用http.Client或 gRPC stub - client 初始化交给 DI 容器（如
dig或手写构造函数），不要在 handler 里 new；这样测试时可轻松注入 mock 实现 - 生产环境用服务发现（如 Consul +
go-micro/registry/consul）或 DNS SRV 记录，避免把order-svc:8080写死在代码或 config.json 里
gRPC 和 HTTP 共存时，别让 proto 文件变成新的单点故障
很多团队用 gRPC 拆服务后，把所有 .proto 放进一个 api/ 仓库，各服务都 go get 它——结果改一个字段，全链路得同步发版，反而比单体还脆弱。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个服务只定义自己暴露的 proto，比如
user.proto只描述用户查询接口，不包含订单字段；下游需要什么数据，由调用方自己 mapping，不复用对方的 message 定义 - 禁止在 proto 中使用
import引入其他服务的文件；如果真要复用结构（如通用分页），单独抽成common.proto，但版本号独立管理（v1/common.proto），且向下兼容策略写进 README - 生成 Go 代码时，用
--go-grpc_opt=paths=source_relative，确保生成路径和 proto 路径一致，避免 import 冲突
本地调试多服务时，env 配置和日志上下文最容易串掉
启动 5 个 Go 服务后，log 打印的 trace_id 对不上、env 从 dev 变成 test、甚至某个服务连错了本地 Redis 而不是自己的实例——这些问题往往不是代码 bug，而是启动时环境没隔离清楚。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个服务的
main.go开头强制校验关键 env 变量，例如if os.Getenv("ENV") == "" { log.Fatal("missing ENV") }，不依赖默认值 - 用
zap的With(zap.String("service", "user-api"))固定打点字段，别靠进程名或 PID 区分日志来源 - 本地用
docker-compose启动时，每个 service 的environment块显式声明ENV、LOG_LEVEL、REDIS_ADDR，不靠 .env 文件全局注入
真正难的不是写多少个 main.go，而是每次加一个新服务时，你有没有重新审视过它和上下游之间的错误传播方式、超时传递逻辑、以及失败后怎么通知调用方——这些细节不会出现在架构图里，但决定了系统到底算不算“分布式”。
