微服务拆分应基于DDD限界上下文而非技术模块，每个服务需独立部署与数据库；跨服务调用须用gRPC+Protobuf定义强类型接口，字段变更需向后兼容；本地开发需真实服务发现与健康检查。

微服务拆分不是代码切分，而是领域边界识别

Go 本身不提供“微服务拆分”能力，它只提供构建独立服务的工具链。真正决定是否该拆、怎么拆的，是业务语义和团队协作模式。常见错误是过早按技术模块（比如“user-service”“order-service”）硬切，结果导致跨服务频繁调用、事务断裂、最终一致性失控。

实操建议：

• 先画出 DDD 的限界上下文图，每个上下文对应一个服务——不是按表、不是按功能点，而是按“谁拥有数据主权、谁负责业务规则”来划
• 避免出现 user-service 同时被 order-service 和 notification-service 强依赖的扇出结构；若存在，说明 user 上下文职责过重或暴露了不该暴露的细节
• 拆分后，每个服务必须能独立部署、独立数据库（哪怕初期共用 PostgreSQL 实例，也必须用不同 schema 或 database）

Go 中定义服务接口：用 gRPC + Protocol Buffers 而非 REST+JSON

Go 生态中，gRPC 是事实标准，原因很实际：强类型契约、内置流控、天然支持多语言、序列化更紧凑。用 http.HandlerFunc 暴露 JSON 接口看似简单，但很快会陷入字段名不一致、版本混乱、无文档可查的问题。

实操建议：

• 所有跨服务调用必须通过 .proto 文件定义，禁止在服务内直接构造 HTTP 请求去调另一个服务的 /v1/user
• service 定义里不要暴露实现细节，例如避免 GetUserWithOrders 这种聚合查询——这是调用方组合逻辑，不是被调服务的职责
• 版本管理写进包名，比如 package userpbv2;，而非靠 URL 路径 /api/v2/user，后者对 gRPC 无效

service UserService {
  rpc GetUser(GetUserRequest) returns (GetUserResponse);
}
message GetUserRequest {
  string user_id = 1;
}
message GetUserResponse {
  User user = 1;
  // 不要加 repeated Order orders = 2;
}

接口变更必须向后兼容，否则就不是“服务”而是“紧耦合模块”

Go 编译期检查无法捕获 gRPC 接口不兼容问题。你改了 .proto 里的一个字段类型，旧客户端可能 panic 在 Unmarshal 阶段，而错误信息只是 "proto: cannot parse invalid wire-format data"，毫无提示。

实操建议：

• 字段删除前，先用 reserved 声明，并加注释说明废弃时间，例如：reserved 3; // deprecated since 2025-06, remove in v2.1
• 新增字段必须设默认值且为零值（int32 field = 4 [json_name = "field"]; ），不能依赖客户端传值
• 每次生成 Go 代码后，跑一次 protoc-gen-go 的 --go-grpc_opt=paths=source_relative，确保 import 路径不漂移

本地开发调试时，别让服务间调用变成“网络不可达”的黑洞

刚拆完两个服务，user-service 调 auth-service，本地一跑全报 connection refused。这不是代码问题，是环境没对齐。

实操建议：

• 所有服务启动时，读取环境变量 AUTH_SERVICE_ADDR（而非写死 "localhost:50051"），本地用 docker-compose 统一配 network，K8s 用 Service DNS 名
• 在 main.go 加一层健康检查路由（如 GET /healthz），返回当前服务依赖的下游地址和连接状态，不用翻日志就能确认连通性
• 用 grpcurl 替代 curl 测试接口：grpcurl -plaintext -d '{"user_id":"u1"}' localhost:50051 user.UserService/GetUser

最常被忽略的一点：服务发现不是“上线才配”，而是从第一个 go run main.go 就该走真实发现路径。本地开发用 consul agent -dev 或 etcd 单节点，比 mock 更接近生产行为。