带缓冲channel设容量零值即chan Task是nil，直接写入会panic；无缓冲channel导致生产者阻塞；select+default可非阻塞写入，但无法防背压，需结合限流、告警或context超时控制。
为什么用带缓冲 channel 做队列必须设容量
零值 chan Task 是 nil，直接写入会 panic；无缓冲 channel 则会让生产者卡在 ch 直到有消费者接收，上游一压就崩。缓冲容量不是越大越好——设成 <code>make(chan Task, 1000) 比不设强，但若按峰值 1000 QPS 设成 10000，内存可能瞬间吃满。
实际建议：缓冲大小按「典型峰值 × 1.5」预估，再结合 GC 压力微调。比如压测发现每秒稳定入队 800 个、P99 处理耗时 120ms，那缓冲设 1200 左右较稳；上线后用 len(ch) 定期采样，持续 >80% 就该告警扩容或限流。
select + default 非阻塞写入怎么防背压
只写 ch 是同步阻塞的，一旦队列满，goroutine 就挂住，积压越来越多，最终 OOM。必须用 <code>select 包一层：
select {
case ch <- task:
// 入队成功
default:
// 队列满，执行降级逻辑
return ErrQueueFull
}注意点：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
default分支不能空着打日志就完事，得明确返回错误或走异步落盘/重试 - 别在
default里加time.Sleep等重试——这等于把背压转嫁给调用方，还拖慢整个链路 - 如果业务允许丢弃，
default直接 return；如果必须可靠，这里该触发限流器limiter.Wait(ctx)或写入本地磁盘暂存
轮询选节点时 atomic.AddUint64 为什么不能替代健康检查
用 atomic.AddUint64(&idx, 1) % uint64(len(servers)) 能解决并发索引竞态，但完全不管节点死活。常见错误是把轮询逻辑和健康检查割裂开：先轮询拿到 servers[i]，再单独调 node.IsHealthy()，结果中间节点已宕，请求照样发出去。
正确顺序是：
- 先获取当前健康节点快照（深拷贝 or
sync.RWMutex.RLock()读取） - 在快照上做轮询或随机选择
- 快照为空时立即返回
ErrNoAvailableNode，不 fallback
健康状态必须缓存（如 TTL=30s），不能每次请求都发起 HTTP 探针——否则探针本身就成了性能瓶颈。
sync.Pool 复用结构体时最易忽略的生命周期问题
sync.Pool 不保证对象一定复用，更不保证对象不会被跨 goroutine 误用。高频出错场景：
- 从
taskPool.Get()拿到结构体后，在 goroutine 里启动新 goroutine 并传入该结构体，主线程很快Put()回池，子 goroutine 却还在读写——数据竞争 - 结构体里存了
context.Context或http.Request这类短生命周期对象，Put()后没清空，下次Get()出来直接用，导致 context 已 cancel 或 request.Body 已 close - 在
Put()前忘了把敏感字段置零（如 token、user ID），下一次Get()出来带着旧数据跑，引发越权或脏数据
安全做法：每次 Get() 后显式初始化关键字段；Put() 前手动清空非零值字段；绝不把 Pool 对象暴露给不确定生命周期的 goroutine。
