服务雪崩在Go微服务中最常见的触发点是goroutine泛滥、HTTP客户端无超时、下游依赖未熔断三者叠加；需用context.WithTimeout统一控制调用生命周期，强制熔断器嵌入每个outbound client，实施分级资源隔离与流量区分。
服务雪崩在 Go 微服务中最常见的触发点
Go 本身并发模型轻量，但不等于天然抗雪崩。真实线上环境里，goroutine 泛滥、HTTP 客户端无超时、下游依赖未熔断，三者叠加就足以让一个 http.Server 在数秒内耗尽内存或文件描述符。典型现象是：CPU 不高，但 net/http.server.WriteTimeout 大量超时，runtime.NumGoroutine() 持续攀升到 10k+，lsof -p PID | wc -l 显示连接数卡在 65535 上限。
用 context.WithTimeout 控制所有下游调用生命周期
Go 的 context 是唯一能统一中断 HTTP、gRPC、DB 查询、缓存访问的机制。漏掉任意一处，就等于留了个雪崩入口。
- HTTP 客户端必须设
http.Client.Timeout，且每个请求额外用context.WithTimeout(ctx, 800*time.Millisecond)包裹——前者防连接卡死，后者防业务逻辑阻塞 - gRPC 调用必须传入带 deadline 的
ctx，不要依赖WithTimeout后再手动 cancel；ctx.Done()触发时，grpc-go会主动发 RST_STREAM - SQL 查询不能只靠
db.QueryContext()，还要检查驱动是否真正响应 cancel（如pgx/v5支持，database/sql+lib/pq在某些版本中存在 cancel 延迟）
熔断器不是可选插件，而是必须嵌入每个 outbound client
Go 生态没有像 Hystrix 那样开箱即用的熔断器，但 sony/gobreaker 或 afex/hystrix-go 必须作为基础组件初始化进每个远程 client 封装层，而不是在 handler 里临时加。
- 熔断状态要基于失败率 + 连续错误数判断，不能只看超时——超时可能只是网络抖动，而连续 5 次
503 Service Unavailable才该熔断 - 熔断后 fallback 必须是同步、无副作用的逻辑（例如返回缓存旧值或默认值），禁止在 fallback 里再发起一次下游调用
- 半开状态探测请求要限制为 1 个，且需设置独立短超时（比如 200ms），避免试探请求本身又拖垮下游
资源隔离不能只靠 goroutine 数量限制
用 semaphore.Weighted 或 errgroup.Group 控制并发数只是第一步。更关键的是区分「可丢弃」和「不可丢弃」流量。
立即学习“go语言免费学习笔记（深入）”；
- 对非核心路径（如日志上报、异步埋点），使用带 buffer 的 channel + select default 分支直接丢弃，不阻塞主流程
- 对核心读请求（如订单查询），用
golang.org/x/sync/semaphore限制最大并发，但信号量数量必须小于系统能稳定承载的连接数（例如 MySQL max_connections=200，那本服务分配给 DB 的 semaphore 最多设 150） - 禁止在 HTTP handler 中启动无缓冲 channel 的 goroutine —— 一旦下游慢，这些 goroutine 就永久 hang 在 send 上，
runtime.GC清不掉它们
context 传进去了，却没检查函数内部是否真正响应 cancel；或者熔断器配了，但 fallback 逻辑悄悄引入了新依赖。 
