保持稳定的内部契约，而不是直接调用供应商 SDK
最重要的早期决策是应用代码是否直接调用供应商 SDK。更好的做法是定义一个内部契约：发送请求携带目的地、消息内容或模板、traffic class、发送方标识和客户端引用；状态回调携带该引用、规范状态和规范原因，供应商原始载荷仅用于调试。所有供应商特定细节都封装在适配层背后。
认证、客户端引用与幂等性
凭证应存放在密钥管理系统中，并支持无停机轮换。每条消息在提交前都要生成自己的客户端引用并存储，因为最棘手的失败场景是请求超时——消息可能已发送、已送达，也可能没有。应优先使用供应商支持的幂等键，其次是按引用查询，最后才是针对每个 traffic class 的明确策略。
发送方标识与 traffic class
发送方标识不是发送时随意填写的字符串，而是取决于目的地市场的注册字母数字发送方 ID、长号或短码，注册周期常以周计。traffic class 必须是每次发送的必填字段，因为它决定发送方选择、路由和限速。
编码与分段
SMS 正文使用 GSM-7（单段 160 字符）或 Unicode（单段 70 字符）编码，一个字符就能让整条消息切换到 Unicode，从而改变计费段数和送达行为。段数计算应在提交前完成，并在模板保存时校验。
规范状态映射、webhook 与重试
供应商的状态和错误应映射到一个自己拥有的小型规范集合，保留原始值用于调试，并对未映射的值发出告警。Webhook 需要验证签名、防重放、容忍重复和乱序到达、异步处理，并配合定期对账任务。重试策略应由一处统一决定，设置有限次数和硬性截止时间。
吞吐量、结果衡量与退出能力
吞吐量需要按路由限速排队，并按 traffic class 分离队列。送达回执是结果的弱代理指标，更适合用贯穿业务事件、发送、回调和点击的关联 ID 在应用层衡量结果。退出能力是可检验的：能否通过配置将某个国家、渠道或 traffic class 切换到另一供应商，代码中是否残留供应商专属的状态字符串或 SDK 类型，是否保有可导出的消息历史、consent 和 suppression 记录。
Flowstates 提供消息路由，也可以运营这里描述的这一层；客户也可以通过 BYOV 保留自己的供应商合同，或采用混合模式，统一在一个合同和一个运营负责人之下。
SMS 的安全边界
普通 SMS 并非端到端加密，消息内容在送达链路的中间环节可见，并以明文形式保存在手机上。绝不应发送密码、完整账号信息或具有长期访问权限的凭证；一次性验证码应保持短时效、绑定会话，并对发放和验证都做限速。