一、通知短信适合哪些场景？
| 场景 | 触发事件 | 短信内容重点 |
|---|---|---|
| 订单 | 下单、支付、取消、退款 | 订单状态、金额、时间和下一步操作 |
| 物流 | 发货、配送异常、签收 | 物流状态、运单号和客服入口 |
| 预约 | 预约成功、临近、变更 | 时间、地点、注意事项和取消方式 |
| 账单 | 账单生成、即将到期、支付成功 | 金额、期限和安全支付入口 |
| 系统告警 | 服务异常、阈值超限、安全事件 | 影响范围、严重级别和处理入口 |
二、事件触发和消息服务
通知短信应由业务事件自动触发。例如订单状态变化后，订单系统发布事件，统一消息服务接收事件并选择对应模板。业务系统不需要直接处理短信通道和供应商细节。
统一消息服务应完成号码标准化、模板变量校验、频率检查、优先级分配、API调用和状态保存。这样可以减少不同系统重复开发，也便于统一监控和更换通道。
三、幂等与重复发送控制
网络超时不代表平台一定没有收到请求。如果业务系统在超时后直接重新发送，用户可能收到两条相同通知。因此每个业务事件都应有唯一幂等键，例如“订单号+事件类型+状态版本”。
消息服务在提交前检查幂等键，已经发送或正在处理的请求不能重复创建。平台message ID、业务流水号和最终状态必须关联保存，便于排查重复、漏发和状态不同步。
四、重试策略不能一刀切
临时网络错误、平台限流和运营商短暂不可用可以延迟重试；号码无效、内容拒绝、用户退订和国家不支持通常不应重试。重试策略必须根据错误码分类。
建议采用有限次数和递增间隔，并设置消息有效期。预约提醒如果在预约结束后才重试成功，已经失去业务价值。系统告警还可以配置短信失败后的备用渠道，但要避免多个渠道反复骚扰同一用户。
五、状态回执与监控
API返回成功通常只是“已提交”。最终是否送达，需要通过Webhook或查询接口获得。回调处理要校验签名、允许重复回调、保存原始状态，并把不同平台状态映射为企业统一状态。
- 按业务类型监控提交量、送达率、失败率和延迟。
- 对失败率突然上升、回调中断和队列积压设置告警。
- 按国家、运营商、模板和错误码进行问题定位。
- 保留业务流水号、message ID和时间线供客服查询。
- 定期核对平台报告与企业内部发送记录。
六、模板变量和安全要求
通知模板应固定主体结构，只允许填充经过校验的变量。订单号、金额、时间、地点等变量需要设置长度和字符规则，避免空值、代码片段或异常内容进入短信。
短信中不要发送完整密码、银行卡号、身份证号或其他高敏感信息。链接应使用企业自有HTTPS域名，并避免把长期有效的敏感令牌直接放入URL。重要操作应要求用户重新登录或完成身份验证。