go 的 context.withtimeout 未生效主因是 context 未传递至阻塞操作处或被中间层丢弃；须显式传入 ctx 到 http/db/rpc 等 i/o 方法，避免依赖默认 client，防止 goroutine 泄漏与重试风暴，熔断应按服务维度配置并识别熔断错误。
Go 的 context.WithTimeout 为什么没生效？
根本原因往往是 context 没传到真正阻塞的地方，或者被中间层无意丢弃。比如 HTTP 客户端用了 http.DefaultClient，但没把带 timeout 的 context 传给 req.WithContext()；又或者数据库查询用了 db.Query() 而非 db.QueryContext()。
- 所有可能阻塞的 I/O 操作（HTTP 请求、DB 查询、RPC 调用、channel receive）必须显式接收并使用
ctx参数 - 不要依赖全局 client，默认 client 不感知 context；改用
&http.Client{Timeout: ...}只控制连接/读写总时长，不等价于 context timeout - 注意 goroutine 泄漏：启动 goroutine 时若没把
ctx传进去，超时后主流程退出，子 goroutine 还在跑
重试逻辑该放在客户端还是服务端？
微服务间调用，重试必须由调用方（客户端）控制，服务端不应自行重试——否则会放大雪崩风险，尤其当失败原因是下游过载时。
- 用
github.com/hashicorp/go-retryablehttp或golang.org/x/time/rate+ 自定义 backoff 更可控；标准库net/http不带重试 - 只对幂等操作（GET、PUT、DELETE）做重试；POST 默认非幂等，需服务端配合支持 idempotency key
- 避免“重试风暴”：指数退避 + jitter 是底线，别用固定间隔；最大重试次数建议 ≤ 3
熔断器怎么防止级联失败？
核心是隔离失败传播路径，而不是等错误堆满才动作。Go 生态里 sony/gobreaker 是最轻量可靠的选型，它基于滑动窗口统计失败率，不是简单计数。
- 不要给每个 RPC 方法配独立熔断器；按下游服务维度建实例，比如
userSvcBreaker、orderSvcBreaker - 状态切换有延迟：closed → open 需连续失败触发，open → half-open 需等待
sleepWindow，此时只放行少量请求试探 - 熔断后返回的 error 必须可识别（如检查是否为
gobreaker.ErrOpenState），避免上层误当业务错误处理
goroutine 泄漏比 panic 更难发现
超时和重试本身如果没配合 cancel，就是泄漏温床。一个典型场景：goroutine 启动后监听 channel，但 channel 永远不关闭，context 又没传进去。
立即学习“go语言免费学习笔记（深入）”；
- 所有
select必须含case 分支，且该分支要清理资源（关 channel、释放锁、cancel 子 ctx） - 用
pprof/goroutine快速定位：启动时加_ "net/http/pprof"，访问/debug/pprof/goroutine?debug=2看堆栈 - 测试阶段加
runtime.GC()+runtime.NumGoroutine()断言，验证并发调用后 goroutine 数回落
超时、重试、熔断三者必须组合使用才有意义，单独上任何一个都挡不住真实生产环境里的抖动和故障。最容易被忽略的是：cancel signal 是否真正穿透到了最底层 I/O 层，而不是只停在某一层封装里。
