go中无原生装饰器，需用高阶函数+闭包实现熔断降级；须正确控制执行流、按接口粒度隔离熔断器、在http响应前检查状态、避免goroutine泄漏，并明确失败判定边界。
Go 里没有原生装饰器，得用函数式包装替代
Go 语言本身不支持 Python 那种 @decorator 语法，所谓“装饰器”实际是通过高阶函数 + 闭包实现的请求拦截逻辑。核心思路是：把 http.HandlerFunc 或业务处理函数作为参数传入一个包装函数，返回新的处理函数，在其中插入熔断、降级等横切逻辑。
常见错误是直接在包装函数里调用原始 handler 并忽略返回值或错误，导致熔断状态没更新、降级响应没生效。必须确保包装后的函数能控制执行流——该跳过就跳过，该 fallback 就 fallback，该抛错就抛错。
- 包装函数签名通常为
func(http.HandlerFunc) http.HandlerFunc或func(func() error) func() error，取决于你封装的是 HTTP 层还是业务方法层 - 不要在闭包外提前计算熔断器实例（比如用全局变量），否则多个路由共享同一熔断状态，互相干扰
- HTTP 场景下，务必在
w.WriteHeader()和w.Write()前检查熔断状态，否则可能已写部分响应头再中断，客户端收不到完整 fallback 内容
用 github.com/sony/gobreaker 实现熔断器初始化与集成
gobreaker 是 Go 社区最常用的熔断库，配置简单但默认行为容易误用。它基于失败率+时间窗口判断状态，不是简单计数器。
典型陷阱是把 cb.Execute() 直接套在 http.ServeHTTP 上——这会把整个 HTTP 处理过程当做一个“命令”，而 HTTP handler 可能因超时、客户端断连等非业务错误失败，导致熔断器误判。
立即学习“go语言免费学习笔记（深入）”；
- 只对真正代表业务失败的操作调用
cb.Execute()，比如调用下游 API 的client.Do()、数据库查询db.QueryRow() -
gobreaker.Settings中Timeout指熔断开启后持续时间，不是单次调用超时；单次超时应由context.WithTimeout()控制 - 如果下游服务有多个 endpoint，建议按接口粒度创建独立
gobreaker.CircuitBreaker实例，避免 A 接口故障拖垮 B 接口
HTTP handler 中嵌入降级逻辑的三种可行位置
降级不是“出错了才执行”，而是要和熔断状态、上下文、请求参数联动。关键在于选对插入点，否则 fallback 可能被绕过或重复执行。
常见错误是把降级逻辑写在 defer 里——defer 在函数 return 后才执行，此时 HTTP 响应可能已写出，无法再改状态码或 body。
- 入口处检查：
if cb.State() == gobreaker.StateOpen { handleFallback(w, r); return }—— 最快拦截，适合强依赖型服务 - 调用下游前检查：
if cb.Ready() { ... } else { handleFallback(w, r) }—— 利用Ready()判断是否允许尝试，比查 State 更稳妥 - 捕获执行异常后降级：
if err != nil { if errors.Is(err, context.DeadlineExceeded) { handleFallback(w, r) } }—— 仅对特定错误类型 fallback，避免掩盖真实 panic
goroutine 泄漏与 context 传递被忽略的后果
装饰器里启动 goroutine 却不接收 context.Context，或者把外部 ctx 忘记传进下游调用，是线上服务内存缓慢增长的常见原因。
比如在包装函数里写 go doSomething()，但 doSomething 里没做 cancel 检查，一旦请求提前结束，goroutine 会一直跑完甚至卡死。
- 所有异步操作必须接收
ctx参数，并在 select 中监听ctx.Done() - HTTP handler 包装器中，从
r.Context()拿到的 ctx 要显式传给熔断器执行函数（cb.Execute不接受 ctx，需自行包装） - 别用
time.After()做超时控制，改用context.WithTimeout()，否则 timer 不会随请求取消而释放
熔断和降级真正难的不是代码怎么写，而是状态边界是否清晰——比如熔断器该不该感知 401/403 这类客户端错误？下游返回空数据算不算失败？这些判断点一旦模糊，整套机制就会在灰度期表现正常，上线后突然大面积 fallback。
