真正拆分应基于限界上下文：明确数据主权与规则演化边界，如优惠券在发券、核销、风控中语义不同，须分属不同服务；患者档案与临床试验入组即使共用ID也应隔离。
按限界上下文拆，不是按“用户”“订单”命名就完事
很多团队一建服务就起名 user-service、order-service，结果跑半年发现：user-service 被 5 个服务调用，每个都查不同字段，接口越加越多，数据库 schema 被迫开放，最后变成“分布式单体”。这不是拆分，是贴标签。
真正该做的，是画出业务里的**限界上下文（Bounded Context）**——谁对数据有主权？谁负责规则演化？比如“优惠券”在发券策略、核销逻辑、风控拦截里语义完全不同，强行塞进一个服务，必然要妥协；而“患者档案”和“临床试验入组”在医疗系统里就是两个独立上下文，哪怕共用一个“患者ID”，也不该共享代码或数据库。
- 判断标准：
一个需求变更是否只改一个服务？如果改个登录流程要动 user、auth、notification 三个服务，说明边界错了 - 拒绝“表驱动拆分”：不要因为有
users表就建 user-service，要看它承载的是注册登录、还是会员等级、还是实名认证——这些可能分属不同上下文 - 初期可共用 PostgreSQL 实例，但必须用不同
schema或database，禁止跨 schema join，否则迟早被运维叫停
gRPC 接口定义不写清楚，上线后第一周就返工
用 protoc 生成代码很爽，但如果你的 .proto 文件里写着 rpc GetUserWithOrders(GetUserRequest) returns (GetUserResponse)，那等于把聚合逻辑强绑在服务契约上。下游一要加收货地址，你就得改 proto、发版、等所有客户端升级——这不是微服务，是 RPC 单体。
- 接口只暴露“本上下文能且只应提供的能力”：
GetUser返回User，别带repeated Order；订单归属由调用方自己查order-service - 字段增删必须向后兼容：
reserved 3;标记废弃字段，并在注释写明// deprecated since 2026-01, remove in v2.1 - 新增字段必须设默认零值：
int32 version = 4 [json_name = "version"];，不能依赖客户端传值，否则旧 client 一调就 panic 报"proto: cannot parse invalid wire-format data" - 版本写进包名，别用 URL 路径：
package userpbv2;，而不是靠/api/v2/user——gRPC 根本不认路径
HTTP/JSON 不是退而求其次，而是中小团队最可控的选择
别被“gRPC 性能高”带节奏。你真测过吗？在内网千兆网络下，gRPC 比 JSON 快不到 1ms，但调试成本翻倍：curl 不好使、浏览器打不开、前端联调要装插件、错误堆栈藏在二进制流里……很多团队卡在 context deadline exceeded 却查不出是哪层超时，最后全加 WithTimeout(30s) 了事。
- 内部服务间调用，用
net/http+chi完全够用；关键点是统一加context.WithTimeout和透传trace_id - 对外 API 一律走 HTTP/JSON，用
oapi-codegen从 OpenAPI 3.0 自动生成 server stub 和 client SDK，契约即文档 - 真要用 gRPC，
.proto必须放独立 git 仓库，所有服务go.mod replace同一 commit，别让 A 服务用 v1.2、B 服务用 v1.3 - 禁止在 proto 里定义
map或深度嵌套结构——生成的 Go 代码会难 debug，且跨语言解析易出错
服务自治不是口号，得靠目录结构和 CI/CD 卡死
所谓“独立部署”，不是你能 go run main.go 就算数。如果 order-service 的 internal/repository 包被 payment-service 直接 import，或者两个服务共用一个 go.mod，那再漂亮的 DDD 图也是纸老虎。
- 每个服务一个独立 repo 或至少一个独立 module：
/services/order下有自己go.mod，禁止跨目录import其他服务的internal -
/internal存私有逻辑，/pkg放可复用组件（如通用 error 包），但/pkg不能反向依赖/internal - CI 流水线必须校验：
go list -f '{{.Deps}}' ./... | grep 'other-service/internal'—— 有输出就失败 - 健康检查接口
/health必须检查自身 DB 连通性 + 关键下游连通性（如 order-service 检查 payment-service 是否可连），不能只 return 200
拆分最难的不是技术，是让团队习惯“这个逻辑不该我改”。一旦有人开始写 import "github.com/ourorg/payment-service/internal/service"，就得立刻拦住——这比任何性能问题都危险。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
