go-zero适合需快速拉齐api、rpc、model的crud密集型团队，通过goctl一键生成代码并内置熔断限流能力，但http与rpc双体系易致架构撕裂。
别在“性能第一”或“上手最快”之间反复横跳了——框架选型不是比参数，而是看它能不能把你团队当前最疼的三个点一次性按住：接口定义混乱、服务上线后熔断失灵、新人三天还跑不通一个完整请求。
go-zero 适合什么人用？
适合需要 goctl 生成器把 api、rpc、model、cache 一键拉齐的团队。它不强制 Protobuf，API 可以写成 JSON 格式，goctl api -o=user.api 后直接 goctl api go -api=user.api -dir=. 就能跑起来。
常见错误现象：goctl 生成的代码编译失败，多数是 user.api 里用了未声明的类型（比如写了 int64 却没加 import "github.com/zeromicro/go-zero/core/stores/sqlx"）；或者 redis 配置路径写错，导致 cache.NewRedis panic。
使用场景：
- 电商后台、内容中台这类 CRUD 密集、需要快速出原型的业务
- 团队里有熟悉 Go 但没接触过 gRPC 或 Protobuf 的成员
- 运维环境已稳定使用 ETCD，不想额外引入 Consul 或 Nacos
注意：go-zero 的限流中间件默认走内存计数，跨实例不共享；要分布式限流得自己接 Redis 或升级到 go-zero v1.7+ 的 redislimiter 插件。
Kitex 性能强，但代价是什么？
Kitex 真正快的地方不在“写个 Hello World”，而在高并发 RPC 调用链路上：它的 Netpoll IO 多路复用 + Protobuf 零拷贝序列化，压测时 RPS 比 gRPC-Go 高 30% 不是玄学。
但代价很实在：
- 所有接口必须用
.proto定义，HTTP API 得靠kitex-http或自建网关转换，否则前端连/health都调不通 -
kitex tool生成的代码依赖kitex-gen包，升级 Kitex 版本时若不重生成，运行时报undefined: xxxServiceClient是常态 - 熔断策略默认只对 RPC 调用生效，HTTP 接口得手动 wrap 中间件，否则流量打爆下游服务时毫无感知
如果你的业务已经用 Protobuf 做通信规范，且核心链路每秒调用超 5 万次，Kitex 是目前 Go 生态里最稳的选择；否则，先用 Kratos 过渡更省心。
Kratos 为什么越来越多人选？
Kratos 的真实优势不是“B站出品”，而是它把 protobuf 当契约、把 transport 当插槽的设计——http.Server 和 grpc.Server 共用同一套 service 实现，改个配置就能双协议暴露。
容易踩的坑：
-
kratos.New初始化时漏传kratos.Server()，程序静默退出，日志里只有app stopped，根本不会报错 - 用
ent做 ORM 时，ent.Client必须通过di注入，硬 new 出来会导致事务失效、连接池泄漏 -
log.With()的字段名不能含空格或点号，否则 Jaeger 上链路日志丢失关键 tag
它适合中等规模团队：既不想被 go-zero 的约定绑架，又不愿像 gRPC-Go 那样从零搭治理层。只要接受“先写 proto，再写 service”，开发体验和长期可维护性就非常扎实。
别忽略 infra 层的真实成本
再好的框架，如果注册中心配成单点 etcd、配置中心没做灰度发布、链路追踪只埋了入口没串透 DB 调用，上线后照样查不出慢请求在哪卡住。
实操建议：
- 本地开发用
docker-compose起一套最小 infra：etcd + prometheus + jaeger + redis，所有框架 demo 都跑在这套环境上验证 - 拒绝“先写业务，infra 后补”——第一天就要让
curl http://localhost:9090/metrics返回真实数据，否则监控永远是摆设 - 每个服务的
main.go里必须显式声明app.WithTimeout(30 * time.Second)，避免 SIGTERM 后 goroutine 残留
框架只是骨架，真正决定系统韧性的，是你愿意为 infra 流程花多少时间写测试、压测、演练——而不是在选型文档里划重点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
