go-zero是多数团队的实际起点，因其将服务发现、熔断降级、限流、链路追踪等微服务高频痛点封装为声明式配置模块，通过yaml定义并自动生成http/grpc全栈代码，避免手动拼装导致的上下文错乱、注册发现失效及边界设计难题。
别从零写——现有成熟框架（如 go-zero、kratos、gin + etcd + grpc-go 组合）已覆盖 95% 的微服务需求，自己造轮子大概率陷入配置爆炸、上下文传递断裂、中间件调试地狱。
为什么 go-zero 是多数团队的实际起点
它不是“又一个 Web 框架”，而是把微服务高频痛点打包成可声明式配置的模块：服务发现、熔断降级、限流、链路追踪、JWT 验证、CRUD 自动生成——全在 api 和 rpc 两层 yaml 里定义。
- 你改一个
user.api文件，goctl api go就生成完整 HTTP handler + service + model + types - 限流规则直接写进
etc/user-api.yaml：Limit: 1000+Window: 60，不用手写 token bucket 逻辑 - gRPC 服务用
goctl rpc proto从user.proto生成 server/client/registry 代码，连 etcd 注册逻辑都内置了 - 错误是
code: 400还是code: 503？由errx.NewCodeError()统一控制，不会漏传 status code
gin + grpc-go 手动拼装时最容易崩的三个点
不是语法不会，是跨协议上下文和生命周期没对齐导致请求卡死、panic 或超时错乱。
-
gin.Context不能直接传给 gRPC handler——它没有context.Context的 deadline 和 cancel 机制，必须用gin.Context.Request.Context()提取原生 context - gRPC server 启动后监听
:9000，但 gin 路由里调用 client 时没设WithBlock()，会导致首次请求 hang 住（DNS 解析未完成就发包） - HTTP 中间件里 recover() 捕获 panic 后，如果没手动写
c.Status(500)，gin 默认返回 200 + 空 body，前端以为成功
服务注册与发现不配 etcd 就等于没微服务
用 localhost:8080 硬编码调用其他服务，上线就炸。真正要跑通的是“服务名 → 实例列表 → 健康实例 → 负载均衡”这一整条链。
-
go-zero默认用etcd，启动时自动注册，key 是/services/user-rpc/10.0.1.5:9000，ttl 30s，心跳续期 - 自己集成
etcd时，千万别用clientv3.New()不带context.WithTimeout()——初始化失败会卡死整个服务启动 - DNS SRV（如
_rpc._tcp.user.service.consul）看着优雅，但 Go 的net.Resolver默认不支持 TTL 缓存，频繁查 DNS 会拖慢首请求
真正的难点不在代码行数，而在服务间边界怎么划：一个 RPC 接口该返回 User 还是 UserBrief？字段空值要不要透出？错误码该用业务码（1001 用户不存在）还是 HTTP 状态码映射？这些决策比选框架影响更大。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
