发送成功率≠到达率：前者指API调用返回HTTP 200及正确code的比例，属出站可控范围；后者需依赖运营商回执或短链点击归因，反映短信实际触达用户终端的效果。
发送成功率 ≠ 到达率，先搞清指标定义
很多人一上来就埋头写监控逻辑，结果发现“发送成功”日志满天飞，用户却说没收到——这是因为 sendSms() 返回成功只代表短信已提交到系统或运营商网关，并不保证抵达手机。真正影响体验的是 到达率（含终端拦截、休眠、信号丢失等环节），而平台能直接拿到的可靠数据是 发送成功率（即调用 API 后返回 HTTP 200 + 正确 code 字段的比例）。
- 发送成功率：看你自己的服务调用短信通道（如阿里云 SMS、腾讯云 SMS）是否返回成功响应，属于「出站可控范围」
- 到达率：需依赖运营商回执（SMPP DELIVERED 状态）或第三方监测链接（带唯一 tracking ID 的短链点击归因），但后者仅适用于含链接的营销短信，验证码类基本不可用
- 阿里云等平台会在 24–48 小时内基于通道反馈自动更新「报备状态」为“报备成功”，但这只是资质验证，不是实时效果监控
用状态回执 + 异步回调实现准实时监控
光靠 sendSms() 的同步响应远远不够。必须启用通道提供的「状态报告」能力，否则你永远不知道某条验证码到底卡在哪——是被运营商限流？还是签名未报备？还是模板变量渲染失败？
- 阿里云/腾讯云都支持配置
ReportUrl，当短信状态变更（如 sent、delivered、failed）时，会向该地址推送 JSON 回调 - 回调里关键字段是
status（如"success"/"fail"）、err_code（如"isv.BUSINESS_LIMIT_CONTROL"表示触发频率限制）和phone_number - 务必校验回调签名（如阿里云的
Signatureheader），防止伪造请求刷坏统计数据 - 别把回调处理写成同步阻塞逻辑——高并发下容易超时丢弃，建议写入消息队列（如 Kafka/RocketMQ）再异步落库
Android 端本地发送需监听广播，但仅限本机
如果你在 App 内直接用 SmsManager 发送（比如离线应急场景），那只能靠系统广播获知「本机是否发出」，完全无法反映对方是否收到。
- 注册
PendingIntent绑定SENT_SMS_ACTION广播，可捕获RESULT_OK（发出成功）或RESULT_ERROR_RADIO_OFF（飞行模式）等本地状态 - 注意 Android 10+ 对后台启动 Activity 的限制，
BroadcastReceiver必须是应用前台活跃时才可能收到，否则要改用JobIntentService或前台服务兜底 - 该方式无法替代服务端监控——它不经过你的业务系统，也无法聚合统计，仅适合调试或极简场景
失败原因必须分类入库，否则监控等于摆设
只记「成功/失败」两个数字毫无价值。真正要盯的是失败里的结构化分布：是 70% 卡在签名未审核？还是 20% 因号码停机？或是某运营商通道突然抖动？
- 建表时至少包含字段：
sms_id、phone_number、channel、status、err_code、err_msg、created_at - 对
err_code做归类映射（如把阿里云的isv.INVALID_TEMPLATE_CODE和腾讯云的1015都映射为「模板失效」），方便统一告警 - 设置阈值告警：比如「单通道 5 分钟内失败率 > 5%」触发企业微信/钉钉通知，而不是等用户投诉才反应
最常被忽略的一点：不同通道的 err_code 含义不一致，且文档更新滞后。上线前务必用真实失败 case 反复验证解析逻辑，别信文档写的“理论上会返回”。
