Go中实现舱壁模式必须用semaphore硬限流，而非context.WithTimeout；需为每个依赖服务单独配置semaphore实例，确保资源隔离，并配合熔断器使用。
Go 里用 semaphore 做并发数硬限流，不是靠 context.WithTimeout
舱壁模式本质是资源隔离，不是超时控制。很多人误以为用 context.WithTimeout 包一层就实现了隔离，其实它只管“等多久”，不管“能同时跑几个”。真隔离得靠信号量（或带缓冲 channel）来硬控并发数。
推荐用 golang.org/x/sync/semaphore，轻量、无锁、语义明确：
sem := semaphore.NewWeighted(3) // 最多 3 个 goroutine 并发执行
err := sem.Acquire(ctx, 1)
if err != nil {
return err
}
defer sem.Release(1)
-
Acquire阻塞直到拿到配额，ctx可中断等待，但不释放已占资源 - 别用
make(chan struct{}, N)模拟：它无法区分“排队中”和“运行中”，也难做动态调整 - 权重支持非整数资源消耗（比如大任务占 2 份，小任务占 1 份），但多数场景设为 1 即可
每个依赖服务必须配独立 semaphore 实例，不能共用一个
共用同一个 semaphore 就等于把所有下游绑在一条绳上——A 服务慢拖垮 B 服务的请求，舱壁就破了。
典型错误写法：var globalSem *semaphore.Weighted 全局复用；正确做法是按依赖维度拆分：
立即学习“go语言免费学习笔记（深入）”；
type ServiceClient struct {
dbSem *semaphore.Weighted // 仅用于数据库调用
cacheSem *semaphore.Weighted // 仅用于 Redis 调用
httpSem *semaphore.Weighted // 仅用于第三方 HTTP 请求
}
- 每个
semaphore的容量要根据对应依赖的 SLO 和容量预估设置，不是拍脑袋定 5 或 10 - 如果某依赖有多个 endpoint（如 /user 和 /order），且稳定性差异大，建议再细分
- 别试图用 map[string]*semaphore.Weighted 动态管理——运行时新增依赖会绕过监控和容量评估
panic 或 defer 未执行时，sem.Release 丢失导致舱壁泄漏
这是最隐蔽的坑：goroutine panic、提前 return、或者 defer 被包裹在 if 分支里没触发，Release 就不会执行，配额永远卡住，后续请求全被阻塞。
- 必须确保
Release在任何路径下都执行，推荐用匿名函数封装： -
func acquireRelease(sem *semaphore.Weighted, ctx context.Context) func() { ... }返回一个 cleanup 函数，比裸写 defer 更可控 - 测试时故意让某个分支 panic，验证是否仍有 goroutine 卡在
Acquire - 上线后加指标监控：
sem.CurrentCount()（需自己包装或打 patch），看是否长期接近上限
不要把舱壁当熔断器用，semaphore 不感知下游健康状态
semaphore 只管“能不能进”，不管“进去后会不会失败”。如果下游持续 500 或超时，舱壁里积压的请求只会越堆越多，最后耗尽内存或触发 OOM。
- 舱壁 + 熔断（如
sony/gobreaker）是互补关系：舱壁保本地资源，熔断防雪崩传播 - 熔断打开时，应直接拒绝请求，而不是让它排队等
semaphore—— 否则熔断失效 - 注意
semaphore的等待队列无超时机制，必须配合ctx传入带 deadline 的 context，否则可能无限挂起
真正难的是容量设定和联动观测：同一服务里，dbSem、cacheSem、httpSem 的数值怎么配才不互相挤占？这得靠真实流量+错误率+延迟分布反复调，不是文档能写清楚的。
