用途：帮助开发者在 Twilio 上大规模构建时避免生产故障，处理众所周知的 429 速率限制、吞吐管理与回调韧性。前提为已有一个可用的 Twilio 集成、了解预期量级（消息/秒、通话/秒），并配置好 StatusCallback URL。
主要能力：
- 指数退避加抖动：收到 429 时，初始延迟 100ms、每尝试翻倍、加 ±10% 随机抖动、单次上限 30 秒、最多 5 次重试；非 429 错误不重试。
- 每号码吞吐：本地长号码约 1 条短信/秒、1 路并发通话；免付费号码约 3 条/秒；短码 10-100 条/秒；Messaging Service 池为池内之和。发送速度与队列深度不透明，需靠组池扩容。
- 批量发送：按池容量而非期望速度设定 rate_per_second，分批限速发送，发送前验证同意记录并遵守静默时段。
- StatusCallback 韧性：采用瘦接收器（收到即入队并立刻返回 200，异步处理），用 {CallSid}-{CallStatus} 组合键去重，应对 Twilio 超时重试。
- 回退链：短信→语音→邮件逐级升级。
- 语音并发：账户并发通话、CPS 默认 1、会议最多 250 人、Twilio Functions 每服务 30 并发；外呼活动应提前申请 CPS 提升。
- Webhook 超时：语音与消息均需 15 秒内响应，应配置 fallback URL。
监控建议阈值：429 率 >5%、投递失败率 >2%、Webhook p95 >5 秒、队列持续增长、并发通话超限 80%。
限制：无法避免任何 Twilio API 的 429；无法提升单号码吞吐，只能加号码；无法配置 StatusCallback 重试行为；不得超过 Functions 限制（30 并发/服务、10 秒超时、256MB 内存）；无原生限流 API，需自行实现。