短信发送成功率监控技巧全解析

本文深入剖析了短信发送成功率监控的核心逻辑与实践要点，明确区分了易被混淆的“发送成功率”（API调用层面的可控指标）与“到达率”（依赖运营商回执或短链归因的真实触达效果），并系统性地介绍了如何通过状态报告回调、安全签名校验、异步消息队列、结构化错误分类及跨通道err_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
• 务必校验回调签名（如阿里云的 Signature header），防止伪造请求刷坏统计数据
• 别把回调处理写成同步阻塞逻辑——高并发下容易超时丢弃，建议写入消息队列（如 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 反复验证解析逻辑，别信文档写的“理论上会返回”。

理论要掌握，实操不能落！以上关于《短信发送成功率监控技巧全解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！