fan-out 比串行快因并发提升吞吐，但滥用 goroutine（如启100万）会导致连接池耗尽、http复用失效、被限流；应控制并发数并复用资源，如用带缓冲channel（如容量100）限流。
为什么 fan-out 比串行发 push 快，但用错 goroutine 反而更慢
因为并发不是越多越好。起 100 万个 goroutine 去调推送 SDK，大概率触发连接池耗尽、HTTP 客户端复用失效、甚至被目标服务限流或断连。真正有效的扇出，是控制并发数 + 复用底层资源。
实操建议：
- 用带缓冲的
channel控制最大并发数（比如make(chan struct{}, 100)），每个 goroutine 发送前先，发完再 <code>sem - 所有 goroutine 共享同一个
*http.Client，别在循环里 new；尤其要设置Transport.MaxIdleConns和MaxIdleConnsPerHost（建议 ≥ 并发数） - 避免在 goroutine 内部做阻塞日志、同步写文件等操作——这些会拖慢整个扇出队列
context.WithTimeout 必须套在每个推送请求上，不能只套外层
单个推送请求卡住（比如第三方服务响应超慢），会把对应 goroutine 挂死，导致该 goroutine 占着并发槽位不释放。外层 timeout 只能杀掉启动逻辑，拦不住已跑起来的 goroutine。
常见错误现象：goroutine 数持续上涨、内存缓慢增长、部分用户收不到通知但无报错
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 每个推送调用都包一层
ctx, cancel := context.WithTimeout(parentCtx, 5*time.Second)，用完立刻cancel() - 如果推送 SDK 不支持
context.Context（如老版本apns2），得自己加select+time.After做超时兜底 - 注意：不要复用同一个
ctx给多个请求——子 ctx 的 cancel 会影响其他请求
用户分片和错误重试必须解耦，别让失败用户堵住整批扇出
直接把千万用户切块后扔进 goroutine，某一块里有个 token 失效或网络抖动，整个 chunk 就算失败，重试时又得重走扇出流程，浪费资源还拖慢整体。
使用场景：iOS token 过期、Android FCM 设备离线、华为 HMS 接口返回 8000 错误
实操建议：
- 扇出只负责“发起请求”，成功/失败都通过
chan Result归集，主流程不做阻塞等待 - 失败项（含 HTTP 5xx、token 无效、设备不可达）单独收集，走异步重试队列（比如用
redis zset延迟重试） - 分片大小建议 100–500 人/片，太小增加调度开销，太大失败影响面大
别忽略推送结果的幂等解析，APNs 和 FCM 的错误结构完全不同
APNs 返回 410 表示 token 失效，FCM 返回 "error": "NotRegistered" 才是等价含义；华为 HMS 则用 8000 码表示设备离线。混用判断逻辑会导致大量脏数据残留。
性能影响：错误码解析不精准 → 无效重试增多 → 推送通道被限频 → 后续正常请求也被拒
实操建议：
- 为每种推送通道写独立的
parseError(resp)函数，返回标准化的PushResult{Status: "invalid_token", RawErr: ...} - 对 APNs，检查响应 header
apns-id和 body 中reason字段；对 FCM，必须读 response body JSON，不能只看 HTTP status - 记录原始响应体（至少采样 0.1%），否则线上遇到新错误码根本没法定位
最麻烦的其实是错误归因——同一份日志里可能混着网络超时、证书过期、token 格式错误、设备厂商策略变更。没做通道级错误分类，查问题就是碰运气。
