go 中用 semaphore.weighted 实现舱壁模式最直接可靠，它通过 acquire/release 控制资源配额，支持权重、超时与上下文感知，避免 channel/mutex 手动实现的泄漏与死锁风险。
Go 里用 semaphore.Weighted 实现舱壁最直接
Go 标准库没有叫 “Bulkhead” 的包，但 golang.org/x/sync/semaphore 的 semaphore.Weighted 就是舱壁模式的底层支撑——它限制并发数，把资源（比如 HTTP 连接、DB 查询）锁在固定配额内，避免一个慢接口拖垮整个服务。
别自己手写带计数器的 channel 或 mutex 控制，容易漏释放、死锁或不支持超时。用 semaphore.Weighted 是 Go 生态里最轻量、最可靠的选择。
-
Acquire(ctx, n)是核心：n 表示这次操作要占几个“舱位”，比如一次 DB 批量查询占 2 个槽位，普通 GET 只占 1 个 - 必须配
ctx：超时或取消时自动归还配额，否则舱位被永久卡住 - 返回的
func()一定要调用：用defer包一层最安全，哪怕 panic 也能释放
为什么不用 sync.WaitGroup 或 chan struct{} 模拟舱壁
它们能做粗粒度限流，但没法表达“不同操作占用不同资源量”这个关键语义，也缺乏上下文感知能力。
常见错误现象：chan struct{} 固定缓冲大小后，所有请求一律塞一个通道，结果高优先级小请求和低优先级大请求抢同一个队列；WaitGroup 更难控制配额回收时机，一旦 goroutine panic 未 Done，舱壁就永久泄漏。
立即学习“go语言免费学习笔记（深入）”；
-
semaphore.Weighted支持非阻塞尝试（TryAcquire(n)），适合快速失败场景 - 内部用
runtime_Semacquire，无额外 goroutine 开销，比 channel 轻 - Go 1.21+ 对
Weighted做了性能优化，吞吐差距已不明显
HTTP handler 中隔离下游依赖的典型写法
不是给整个 handler 加舱壁，而是对每个外部依赖单独配舱壁实例——DB、Redis、第三方 API 各自独立配额，互不影响。
比如你有 10 个 DB 连接，但想限制“订单查询”最多只用其中 3 个，那就给它单独建一个 semaphore.NewWeighted(3)，而不是共享全局连接池的信号量。
// 示例：为 Redis 调用单独设舱壁
var redisLimiter = semaphore.NewWeighted(5)
func handleUserRequest(w http.ResponseWriter, r *http.Request) {
// 尝试获取 1 个舱位，超时 500ms
if err := redisLimiter.Acquire(r.Context(), 1); err != nil {
http.Error(w, "service busy", http.StatusServiceUnavailable)
return
}
defer redisLimiter.Release(1) // 必须放 defer，不能写在 return 前
// ... 执行 Redis 操作
}
容易踩的坑：权重设错、忘记释放、跨 goroutine 误用
舱壁失效往往不是逻辑错，而是配额管理松动导致的隐性泄漏。
- 权重别硬编码成
1：如果某类操作实际消耗 CPU 或内存远高于其他操作，该设 2 或 3，否则配额形同虚设 - Release 必须和 Acquire 在同一个 goroutine：不要在子 goroutine 里 Release，主 goroutine 已经 return，信号量永远不归还
- 别把一个
Weighted实例在多个微服务间共享：舱壁是单服务内的资源边界，跨服务需用服务网格或熔断器 - 测试时注意：
Acquire(context.Background(), 1)永远不会超时，单元测试要用context.WithTimeout
舱壁真正的复杂点不在实现，而在权衡——设太紧，正常流量被拒；设太松，起不到隔离效果。上线前得用真实依赖压测，看平均响应时间和错误率拐点在哪。
