短信状态报告回调是运营商或平台在短信送达或失败后主动向你指定URL推送结果的HTTP请求；收不到主因是服务未正确暴露、监听路径错误或回调地址不可达，需确保公网可访问、端口开放、URL无误、返回200且验签正确。
短信状态报告回调是什么，为什么收不到
短信状态报告回调不是你主动调用的接口，而是运营商或短信平台在短信送达（或失败）后，**主动向你指定的 URL 发起 HTTP 请求**，把结果推给你。收不到，大概率是你的服务没正确暴露、没监听对应路径，或者平台配置的回调地址根本不可达。
常见错误现象：404 Not Found、502 Bad Gateway、Connection refused、平台后台显示“回调超时”或“回调失败”。这些都不是短信没发出去，而是你这端没接住。
- 确保回调地址是公网可访问的（不能是
localhost或内网 IP） - 确认 Web 服务监听了正确的端口（如 80/443），且防火墙/安全组放行
- 检查平台配置的回调 URL 是否带了多余空格、中文或未编码字符
- 部分平台要求必须返回
200 OK响应体（哪怕空内容），否则视为失败重试
如何解析不同平台的回调参数（以阿里云、腾讯云、容联云为例）
各平台字段名、签名方式、HTTP 方法（GET/POST）、编码格式（UTF-8 / GBK）都不统一，硬写通用逻辑容易翻车。关键不是“怎么解析”，而是“先看清你用的是哪家”。
阿里云 SendSmsResponse 不返回状态报告，需单独开通 SMSSendReport 订阅，回调体是 JSON，含 receive_time、err_code（DELIVRD 表示成功）、phone_number；腾讯云用 callbackData 字段传 Base64 编码的 JSON；容联云默认 POST 表单，字段包括 respCode（000000 为成功）、mobile、reportTime。
- 务必查阅你所用平台的最新文档，搜索关键词：
短信状态报告回调格式 - 不要信任旧博客里的“万能解析函数”，先用
print(request.body)或console.log(req.rawBody)把原始请求打出来看一眼 - 注意时间戳格式：有的是秒级 Unix 时间戳，有的是
yyyy-MM-dd HH:mm:ss字符串，别直接丢进new Date()或datetime.fromtimestamp()
回调验签为什么总失败？三个高频坑
验签不是可选项——不校验签名，攻击者伪造回调就能把你的数据库标记成“全部发送成功”。但签名校验失败，90% 是因为没对齐原始数据源。
- 平台文档写的“按参数名升序拼接”，指的是排序前的原始字段值，不是你
JSON.parse()后再取的值（比如有些字段是数字类型，但回调里是字符串） - 签名密钥（
SecretKey）和 API 密钥（AccessKey）不是一回事，别混用；部分平台要求用 MD5、有的用 HMAC-SHA256，算法错一个字节就全崩 - HTTP Header 中的
X-Timestamp和X-Nonce有时也要参与签名，文档小字里藏着，不细读就漏掉
收到回调后该做什么，而不是做什么
状态报告只说明“这条短信是否抵达运营商网关”，不代表用户手机已弹窗或已读。它唯一可靠用途是更新你本地数据库中的发送记录状态（status 字段），用于对账、重发判断、客户投诉溯源。
- 别在回调里触发耗时操作：如发邮件、调第三方 API、写大文件——超时会引发平台重复推送
- 别用回调 ID 直接查数据库并
UPDATE ... SET status = 'success'就完事：要加幂等判断（比如检查当前status是否已是终态） - 必须记录原始回调日志（含完整请求头、body、时间戳），否则出问题时连“平台到底发了什么”都说不清
最常被忽略的一点：状态报告有延迟，可能比短信实际到达晚几分钟甚至更久；而一条短信可能触发多次回调（如首次失败后重试成功），所以你的处理逻辑必须天然支持重复推送。
