Go-zero默认启用限流与熔断，因API层已预置middleware链；限流基于令牌桶、熔断按失败率>50%触发，均通过etc/*.yaml中enabled: true控制，无需手动注册。
Go-zero 不是“用来实现高性能”的工具，而是你放弃手动拼凑限流、熔断、gRPC 封装、配置热更新之后，自然获得高性能的框架。它不靠黑魔法，靠的是把生产级治理能力直接 baked in 到骨架里——你写业务逻辑时，goctl 生成的代码已经自带超时控制、token 限流、etcd 注册、prometheus 指标暴露。想绕开这些？反而更费劲。
goctl svc 生成的代码会被替换吗？
不会自动覆盖，但有明确触发条件：goctl svc -dir ./rpc -proto user.proto 执行时，如果目标目录下已存在 user 相关文件（如 user.go、user_zrpc.go），goctl 默认会跳过已存在文件，只生成缺失部分。但如果你加了 -force 参数，它就会无差别覆盖——包括你手写的业务逻辑层（比如 userlogic 文件）。
- ⚠️ 最容易踩的坑：在已有服务上反复执行
goctl svc -force，结果把刚加的数据库查询逻辑冲掉了 - ✅ 正确做法：只对
proto文件变更后执行goctl，且默认不加-force；手写业务逻辑一律放在*logic.go文件里（该文件goctl默认不生成也不覆盖） - ? 补救方式：用 Git 跟踪
*logic.go，每次goctl后检查 diff，确认没动到业务层
为什么 go-zero 的 HTTP 服务默认就带熔断和限流？
因为它的 api 层不是裸跑 net/http，而是封装了一整套 middleware 链：请求进来先过 RateLimit（基于令牌桶）、再进 CircuitBreaker（失败率 > 50% 自动熔断）、最后才到你的 handler。这些中间件在 goctl api 生成的 handler 中已预置，不需要你 import 或注册。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 参数控制点在
etc/user-api.yaml里：RateLimit: enabled: true和CircuitBreaker: enabled: true - 限流阈值单位是“每秒请求数”，默认值为
1000，别直接上线——建议先设成10，压测后再调 - 熔断窗口期默认
60s，半开状态持续10s，这两个值在高并发场景下容易误判，需结合实际错误率调整
RPC 服务间调用怎么避免雪崩？
关键不在 client 端，而在 server 端的 Timeout 和 MaxConnection 配置。go-zero 的 zrpc 客户端默认启用重试（最多 3 次），但如果被调用方响应慢或卡死，重试只会放大压力。
- 必须在
etc/user-rpc.yaml中显式设Timeout: 1s（不能依赖全局默认值） - 服务端
rpc的ListenOn要绑定具体 IP+端口，别用0.0.0.0—— K8s Service 域名解析可能失效 - client 端调用时，务必用
ctx, cancel := context.WithTimeout(ctx, time.Second*2)包一层，否则超时控制完全失效
真正难的不是配置开关，而是理解哪些治理能力是“默认生效但可关闭”，哪些是“必须显式声明才起作用”。比如链路追踪要配 Jaeger 地址才上报，而限流熔断只要 yaml 里 enabled: true 就立刻生效——这种不对称性，才是日常调试最耗时间的地方。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
