简单 API 背后是一条复杂链路
一条国际 SMS 通常会经过：应用发起请求、网关或供应商（聚合商）路由、目标运营商或中间 hub、目标网络的 SMSC（存储转发节点，会在有效期内重试送达），最后到达手机。国内流量可能只有一跳，跨境流量往往至少经过一个中间供应商，因为没有哪家聚合商与所有国家的所有运营商都有直连协议。每多一跳，就多一个可能被延迟、过滤或丢弃的环节。
Sender ID、编码方式（GSM-7 每段 160 字符，Unicode 每段仅 70 字符）、有效期（各供应商与市场配置不同，并非统一的行业标准窗口）都会影响送达表现。
DLR 说明了什么，又没说明什么
DLR 是网络给出的报告，不是手机给出的报告。"已送达"通常只表示目标 SMSC 接受了投递到设备的请求，并不能可靠地说明手机是否真正渲染了消息，更不代表用户已读。
需要设计应对的几种失效模式：部分路由（尤其是低质量路由）会静默丢弃消息而不返回任何错误状态；部分供应商在低质量或灰色路由上会无论实际情况如何都返回"已送达"，因为这对它们有商业利益，来自不可信路由的 DLR 不能作为送达证据；即便是终端网络返回的真实"已送达"状态，说明的也只是网络层面的交接，而不是用户实际看到或做了什么。
DLR 适合用来发现路由层面的异常（某条路由失败率突然升高就值得排查），但不能替代在应用层衡量真实结果——用户是否点击了链接、输入了验证码、完成了消息本应触发的流程。健康看板应围绕这类转化信号搭建，而不是只看 DLR 百分比。
发送方注册
越来越多市场要求发送方身份在使用前完成注册：一些国 家要求字母数字 Sender ID 向监管机构或运营商预先注册，印度的 DLT 平台要求主体、Sender ID 和模板三重注册，尼日利亚 NCC 对 Sender ID 和未经请求消息也有相应规则，其他市场也有类似框架。未注册或配置错误的 Sender ID 通常会在运营商层面被过滤或拦截——往往是静默的，这也是为什么只看 DLR 会漏掉真实问题。注册周期和要求因市场和供应商关系而异，应按市场分别规划，而不是假设遵循统一的全球流程。
号码携号转网与按号段路由的失效
过去号码前缀能反映所属运营商，一些路由逻辑至今仍这样假设。携号转网（保号换商）在多数市场早已打破这一前提。如果路由决策依赖号段查表而不做实时携号状态核验，会把相当一部分流量误路由到错误的运营商，表现为送达失败或 DLR 失真，而这与路由质量本身无关。可靠的路由需要查询实时的携号/HLR 数据，而不是依赖静态号段表。
路由类型：直连、中转与灰色路由
直连路由是双边互联协议——运营商对运营商，或运营商与持有自有协议的持牌聚合商之间。这类路由的送达最可靠、DLR 最可信，因为报告来自与终端网络有直接合同关系的一方。
中转路由经过一个或多个持有区域运营商互联协议的中间供应商——多数国际短信实际上就是这样流动的，因为没有一家供应商与所有地方都有直连。经由持牌、负责任的供应商运营的中转路由完全可以是可靠的。
**灰色路由（SIM 卡/SIM 农场绕行）**是对正常互联通道的一种商业和技术上的绕行：流量以伪装成普通个人对个人短信的方式（常见做法是在目标国家部署大量 SIM 卡的"SIM box"）注入目标网络，而不是走正规的 A2P 商业协议。这对出售路由的一方更便宜，因为绕开了正规 A2P 协议需要支付的互联和终端费用。代价是真实的：发送方身份不可靠（收件人可能看到的是一个本地手机号而不是你的品牌 Sender ID）、送达不稳定、这类路径返回的 DLR 不可信，而且终端网络会主动识别并拦截或过滤这类流量，这也是灰色路由的量常常毫无预警地劣化或直接失效的原因。
有一点值得单独说清楚，因为它常被和灰色路由混为一谈：SS7 信令漏洞。SS7 是运营商之间用于路由通话和短信、管理用户位置的信令协议，其已知的一些弱点可能被具备信令网络访问权限的一方用于拦截、位置追踪或消息重定向——这是影响互联基础设施本身的网络安全问题，与 SIM 卡绕行是两回事，也不是一种省钱的路由手段——没有人会把 SS7 漏洞当作发送 A2P 活动流量的商业模式。把"便宜的灰色市场短信路由"和"SS7 漏洞"混为一谈，对两者的描述都不准确：一个是对正规路由商业渠道的绕行，另一个是行业整体面临的信令安全问题。
内容过滤与重试行为
运营商会在网络层出于多种原因过滤内容：垃圾信息识别、部分市场对特定类别内容的限制（金融推广、博彩、政治信息）、以及对 Sender ID 注册状态的执行。即使初始 DLR 显示正常，消息也可能在提交后被静默过滤，重试逻辑因运营商和供应商而异——有些会在有效期内积极重试，有些在首次软失败后完全不重试。这些从 DLR 本身都看不出来，进一步印证了上一节的结论：用应用层的转化信号作为真实依据，把 DLR 当作路由健康的诊断辅助，而不是送达保证。
该衡量什么
按类别拆分流量（OTP 与交易流量需要最快最可靠的路由，营销流量有不同的合规和时间要求，混用容易拖累时效性更强的流量）；监控 DLR 的路由级异常并设置突变告警，但要结合转化数据，而不是只看 DLR 百分比；对关键流量使用多供应商路由，把 OTP 和交易消息分散到多家持牌供应商上以降低单点故障风险，渠道 fallback（WhatsApp、RCS、语音）也能在某个市场短信送达劣化时挽回流程；按完成的动作计算成本，而不是按发出的消息计算成本；提前和每家供应商建立经过测试的升级流程——联系谁、多快响应、什么情况触发换路由。
Flowstates 运营这一层网关能力——多供应商路由、送达监控、发送方注册跟踪，以及按流量类别区分的 failover——可以架在我们直接销售的路由容量上，也可以架在你已有的路由和供应商合同上，或者两者混合，这样团队不必在"重建供应商关系"和"完全没有运营可见性"之间二选一。