Saga是Go微服务中唯一可落地的跨服务事务方案，因2PC、XA、TCC缺乏生产级实现或侵入性强；database/sql事务无法跨服务，DTM需手动实现幂等Compensate、持久化状态及重试容错。
goroutine 和 channel 不是银弹，而是演进起点
早期微服务常把 goroutine 当作“多线程替代品”滥用：一个请求起几十个 goroutine 去串行调用下游，没加超时、没设缓冲、没做 cancel 传播。结果是连接耗尽、内存泄漏、故障扩散。
真正演进发生在意识到：goroutine 是调度单元，channel 是协作契约。它倒逼你设计显式上下文传递、定义清晰的错误边界、拆分可取消的子任务。
- 必须用
context.WithTimeout或context.WithCancel包裹所有阻塞操作（HTTP 调用、DB 查询、gRPC 请求） -
select+channel是唯一合理的并发控制方式，不用time.Sleep轮询或全局锁 - 避免无缓冲
channel在高并发场景下造成 goroutine 泄漏；优先用带容量的chan T或sync.Pool管理对象
gRPC 不是 REST 的替代，而是契约驱动的必然选择
当服务数量超过 10 个、跨语言调用频繁、接口变更频繁时，REST 的松耦合就变成失控的耦合：字段含义靠文档、版本靠 URL 路径、错误码靠约定。而 gRPC 强制你写 .proto 文件，这本身就是一次领域建模——接口即契约，变更即破坏性升级。
但直接上 gRPC 也容易踩坑：
立即学习“go语言免费学习笔记（深入）”；
- 别把
gRPC当成 HTTP 替代品：不暴露GET /health这类简单探针，K8s liveness probe 会失败；得额外暴露 HTTP 端点或用 gRPC Health Checking 协议 -
proto中的enum和oneof必须预留扩展位，否则 v2 接口无法兼容 v1 客户端 - 流式接口（
stream）不能简单套用短连接思维：客户端断连后，服务端要主动 close stream 并清理资源，否则 goroutine 持续挂起
etcd/Consul 注册发现只是第一步，服务治理才是难点
注册成功 ≠ 服务可用。etcd 存了地址，但没告诉你这个实例 CPU 是否打满、延迟是否飙升、健康检查是否刚失败三次。真正的演进是从“能连上”走向“该不该连”。
关键动作不在注册侧，而在消费侧：
- 客户端必须实现本地缓存 + 定期刷新（如每 5 秒拉一次
/v3/kv/range?prefix=/services/），不能每次请求都查 etcd - 负载均衡不能只轮询：要结合实例的
latency、error_rate、qps动态加权，这些指标需由服务自身上报（比如通过 Prometheusmetricsendpoint） - 熔断器（如
hystrix-go或自研）必须基于滑动窗口统计失败率，且熔断后要自动半开探测，而不是固定时间后恢复
GORM 在分布式事务里只能管好自己那一亩三分地
很多人以为用 GORM 的 Begin/Commit 就能搞定跨服务事务。错。它只保证单库 ACID，对跨服务数据一致性毫无帮助。
真实演进路径是分层处理：
- 同服务内多表操作 → 用
GORM事务，没问题 - 跨服务最终一致性 → 放弃强一致，改用
Saga模式：订单服务落库后发Kafka消息，库存服务监听并扣减，失败则发补偿消息 - 极少数需要强一致的场景（如支付）→ 引入
Seata或Distributed Transaction Coordinator，但 Go 生态支持弱，通常绕开或用 TCC 手写
最容易被忽略的是：GORM 的 Preload 在微服务里几乎不可用——它会触发 N+1 查询，且无法跨服务预加载关联数据。正确做法是让调用方分别查用户服务和订单服务，再在网关层聚合。
