短信 API 本质上就是短信一段代码替你拨号。你不需要知道运营商基站怎么握手，短信也不用管短信中心排队逻辑，短信只要把手机号和内容丢给一个 HTTP 接口，短信剩下的短信它自己跑完。

我最早接触这东西是短信给一个电商后台做订单通知。那时候用某云厂商的短信短信服务，文档写得很漂亮，短信但真接进去才发现坑不少。短信比如手机号格式，短信国内要加 +86，短信国际要按 E.164 标准，短信少一位直接返回 400，短信连个友好提示都没有。短信后来学乖了，短信发送前先本地正则过滤一遍，省得浪费请求次数。

短信 API 的调用方式通常分两种：一种走 HTTP 请求，POST 或 GET 把参数拼过去；另一种走 SDK，封装好签名和重试逻辑。小项目用 HTTP 就够了，curl 一行能跑通。大一点的服务建议用 SDK，因为签名算法经常变，手动维护容易出错。我见过一个团队为了省依赖，硬是自己实现 HMAC-SHA256 签名，结果时间戳没同步，短信全发不出去，排查了一下午。

接口返回的 JSON 里，关键字段就几个：code、message、request_id。code 为 0 或 200 表示提交成功，但不代表用户收到了。真正送达状态要靠回执，也就是状态报告接口。很多新手以为返回成功就完事了，其实短信可能被运营商拦截、手机停机、或者进了垃圾箱。回执通常异步推送，你得配一个公网可访问的回调地址，或者定时轮询。

费用方面，国内短信一条大概 0.03 到 0.05 元，量大能谈。国际短信贵得多，美国方向 0.008 美元左右，东南亚有些地区能到 0.05 美元。计费按提交成功算，不管用户收没收到。所以别拿短信 API 做验证码轰炸测试，钱包扛不住。

内容审核是另一个容易翻车的地方。运营商对短信模板有严格限制，营销类必须带退订回 T，通知类不能含链接除非报备。我写过一个告警通知，内容里有“系统异常，请立即处理”，结果被拦截了，理由是“疑似诈骗”。后来改成“您的服务出现波动，建议查看”，秒过。措辞稍微温和点，通过率差很多。

并发和限流也得留意。普通账号默认每秒 100 条，企业认证后能提到 1000 甚至更高。但别真按上限压，运营商那边有流控，超了直接丢包。稳妥做法是加个队列，匀速发送，失败的重试两次，间隔拉长。重试策略别用固定间隔，指数退避更安全。

选服务商的时候，别只看价格。小厂商便宜，但通道质量不稳定，延迟高、丢包多。大厂贵一点，胜在覆盖广、回执及时。我一般建议客户先买最小套餐测一周，重点看三样：到达率、延迟中位数、回执推送的及时性。到达率低于 95% 的直接换，别犹豫。

最后说个细节：短信 API 的文档里通常有个“测试模式”，可以模拟发送不扣费。开发阶段一定打开它，别拿真号码试。我见过有人把测试环境的密钥配到生产，半夜给全量用户发了“测试短信”，第二天被老板叫去喝茶。

短信 API 不复杂，但细节多。把它当成一个需要调优的外部服务，而不是一个简单的函数调用，能省很多麻烦。