发送HelloWorld短信的核心流程是：选合规短信服务商并完成企业认证，获取API凭证；选择合适通道(HTTP/HTTPS或SMPP)并实现UTF-8编码的请求；构建并签名请求体，处理提交响应、回执和上行回复；实施内容合规过滤、频率控制和重试策略；记录日志并监控送达率，同时遵守目标国家法律和隐私。
为什么要有一份完整的发送指南
先说明一点：看起来很像在做工程文档，但其实这是把“如何把一句HelloWorld送到对方手机上”拆成了可操作的步骤。很多问题都是从准备阶段就埋下的伏笔——通道选择、编码、合规、回执处理、重试策略、日志，缺一不可。下面我会一步步把这些环节讲清楚，像给刚上手的同事解释一样，尽量把细节和常见坑都列出来。
总体流程概览
- 注册并认证账号（企业资质、签约、签名备案）。
- 获取并保管好API凭证（API Key/Secret）或SMPP账户信息。
- 选择发送通道：HTTP/HTTPS API 或 SMPP（短连接/长连接），根据需求和规模决定。
- 准备短信内容：模板、变量替换、编码（UTF-8/ UCS-2）、长度拆分。
- 发送请求并处理响应；保存发送日志。
- 处理回执与上行（delivery report & MO），更新业务状态。
- 监控送达率、失败率、延迟，并进行告警和优化。
第一步：选择合规的短信服务商
这一步比预想中重要得多。不同国家对商业短信、验证码、通知类短信有不同法律和运营商规则。合规性直接影响到发信通道、签名方式和送达率。
选择考虑要点
- 资质与备案：服务商是否能提供企业资质支持，是否协助在目的国做签名备案或变更。
- 通道能力：是否支持直连运营商（高送达率）或仅聚合商道（成本低但不稳定）。
- 国际覆盖：目标国家是否在其直连/优质通道列表中。
- 合规服务：是否提供内容合规检测、退订机制、频率控制功能。
- 技术支持：是否有稳定的API文档、测试沙箱和快速响应支持。
账号与认证：企业信息和API凭证
通常你需要完成企业认证，上传营业执照、联系人信息、签名样例等。审核通过后拿到API Key/Secret或SMPP帐号。
- 保管凭证：API Key应只在服务器端使用，Secret从不放在前端代码或公共仓库。
- 环境区分：建议分为测试/预发/正式三个环境并使用不同凭证。
选择发送通道：HTTP API vs SMPP
两者各有优劣，按需选择。
- HTTP/HTTPS API：调用简单，适合中小规模或以简化集成为主的场景；通常是REST接口，返回状态码和messageId。
- SMPP：电信业标准，适合大流量、低延迟、双向通信（需要处理大量上行）。但集成复杂，需维持长连接、处理PDU与序列号。
如果你刚开始，建议先用HTTP API做功能验证，然后根据并发和延迟要求再考虑SMPP。
消息构建：编码、长度、分段
看起来简单的HelloWorld，在国际短信里会被编码和计费规则搞晕。最常见的是GSM-7、UCS-2（或称UCS2/UTF-16）等编码。
- GSM-7：主要用于拉丁字母和常见符号，单条上限160字符，分段每段153字符（因为要保留分段头）。
- UCS-2/UTF-16：用于中文、日语、韩语等双字节字符，单条上限70字符，分段每段67字符。
- UTF-8：API层通常用UTF-8传输，但运营商计费基于GSM或UCS-2。因此要在客户端或服务端先检测实际编码并决定是否需要拆分。
实务建议：发送前先用工具库检测是否只包含GSM-7字符；否则按UCS-2计费并拆分。
签名、模板与变量替换
商业短信通常要求签名（例如公司名）预先备案。验证码类通常支持短模板+变量。
- 签名位置：有些国家要求签名放在短信正文前，有些则必须放末尾或通过独立字段传输，务必按目的国要求。
- 模板系统：生产环境建议使用模板管理，避免发未经审查的文案，降低被拦截风险。
- 参数化：变量替换必须做长度与编码校验（防止注入长字符串导致分段）。
API调用示例（HTTP/HTTPS）
下面是一个简化的伪示例，示范请求要点。注意字段命名在不同服务商处会不同。
{
"api_key": "your_api_key",
"to": "+8613712345678",
"from": "YourBrand",
"text": "HelloWorld，您的验证码是123456",
"encoding": "UTF-8"
}返回通常包含messageId和状态码。拿到提交成功并不等于送达，必须另外处理回执（delivery report）。
回执（Delivery Report）与上行（MO）处理
很多人忽略回执逻辑，结果看不到真实送达率。回执和上行是两个独立的通道：
- 送达回执（DLR）：运营商或服务商会异步通过回调接口或SMPP deliver_sm回复状态，例如SUCCESS/FAILED/EXPIRED等。
- 上行（MO）：用户回复短信或执行退订，会以上行消息的形式到你的回调地址，需要妥善解析并入业务流程。
回执处理要考虑幂等（同一messageId可能重复回调）、状态更新策略、以及未回执时的超时补偿逻辑。
常见状态码与含义（示例表）
| 状态码 | 含义 | 处理建议 |
| 0 / SUCCESS | 提交成功或送达 | 标记为已送达，触发业务回调 |
| 1 / QUEUED | 已排队，等待发送 | 监控队列长度，适当重试 |
| 2 / FAILED | 送达失败（号码不可达、停机等） | 记录原因，分类处理（永久失败或临时失败） |
| 3 / EXPIRED | 超过有效期未送达 | 考虑重发或通知用户 |
合规要点：内容与用户同意
这部分不能偷懒：不同地区对商业信息、验证码、促销内容限制不同。常见要求：
- 明确的用户同意（opt-in），并提供 opt-out 退订方式。
- 不得发送违法、欺诈或敏感词汇，敏感词会导致运营商拦截。
- 按照目的国要求展示公司名或号码（签名），并提前备案。
- 用户数据保护：确保在传输和存储环节符合隐私法规（如GDPR类原则）。
速率控制与批量发送策略
一次把整个客户表推给API通常会被限速甚至封号。要合理设计速率控制。
- 了解服务商的TPS（每秒吞吐）限制，按限制分批发送。
- 实现令牌桶或漏桶算法控制并发。
- 在高峰时段分时段发送，避免短时间流量峰值。
- 对高优先级短信（验证码）和低优先级短信（促销）分开通道或队列。
失败重试与幂等设计
网络波动会带来短暂失败。关键是定义失败类型并采取合适策略：
- 可重试错误（网络超时、临时服务不可用）：指数退避重试3-5次。
- 不可重试错误（号码格式错误、非法签名）：不要重试，要告警并记录原因。
- 每条消息应有唯一id（外部messageId），重试时使用同一id以保持幂等。
日志、监控与指标
不记录就等于没有发生。你至少需要以下指标：
- 提交率（requests/min）、成功率、失败率。
- 送达率（delivery reports中SUCCESS比例）。
- 平均延迟（从提交到运营商确认、以及从提交到送达）。
- 上行量与退订率（用户主动回复/退订）。
日志要包含：时间、messageId、to、from、文本摘要、状态码、服务商响应、重试次数。日志保留策略应满足审计与故障排查需求。
测试与上线流程（建议）
- 先在沙箱环境做功能验证：提交、回执、上行回调全流程测试。
- 用不同国家的真实号码进行小规模试点，观察送达率与被拦截情况。
- 上线前做好合规审查：签名、模板、退订机制、隐私告知。
- 正式上线分批放量，观察1小时和24小时内的关键指标，必要时回滚。
常见坑与实战小贴士
- 不要把Secret放在前端或移动App内；只在服务器端签名请求。
- 字段长度和编码不一致导致内容被截断或乱码——先用库做编码检查。
- 运营商可能会替换发件号或签名；务必与服务商确认签名格式。
- 高并发下SMPP需要连接维护和序列号管理，记得实现自动重连与PDUTimer处理。
- 短信验证码请设置适度有效期（通常3~10分钟），并避免频繁重发同一验证码。
扩展：SMPP简要流程（如果你准备上SMPP）
SMPP是面向会话的二进制协议，核心流程很直白：
- 建立TCP连接并bind（transmitter/receiver/transceiver）。
- 提交短信（submit_sm），每条消息有sequence_number与message_id。
- 接收deliver_sm用于上行或回执，注意区分deliver_sm里dlr参数。
- 维持enquire_link心跳，处理unbind与重连。
实现SMPP时需要考虑线程/连接池管理、PDU序列号回收、长短信分片与重新组装、以及并发下的回执匹配。
示例检查清单（可以打印粘贴）
- 已完成企业认证并获取API凭证
- 签名已备案并确认放置位置
- 模板已审核，变量有长度限制
- 编码检测与分段逻辑已实现
- 回执与上行回调地址已部署并支持幂等
- 速率控制与重试机制已部署
- 日志、监控和告警配置就绪
- 小规模试点通过，合规检查通过
结尾话（随手写几句）
说实话，短信这件事看起来简单，但真正做到稳定可靠又合规，是工程和流程的结合。你会发现很多细节在一开始看不到，直到上线后才暴露。先把基础打牢：合规、编码、回执和限速；剩下的问题大多可以用监控和分批迭代解决。写到这里我想起来曾经因为编码判断不严把一个模板发成了半中文半乱码，客户那边差点炸了——所以编码检测和模板审核别偷懒。