很多人第一次接短信功能，以为拿到 AccessKey、调一次接口，短信就能发出去。实际上到了上线前才会发现，短信内容要先过审，签名和模板少一个都发不出去。阿里云短信服务提供了标准 API，下面按接入时的实际顺序说明：先备好审核材料，再配置密钥、写调用代码，最后处理常见报错。
签名和模板要先过审
写代码之前，先到控制台提交短信签名和短信模板的审核。这两项没有通过，阿里云短信接口的调用即使格式完全正确，也发不出去。
- 短信签名一般用企业名或产品名，比如“某某科技”。提交时要附上营业执照等资质。审核时长以控制台显示为准，不要等到上线前一两天才提交。
- 短信模板按用途分为验证码、通知、营销等类型。变量用占位符表示，例如 ${code}。模板类型选错，或者在验证码模板里夹带促销文案，是最常见的驳回原因。
两项都通过后，记下模板 ID（TemplateCode）和签名名称（SignName）。这两个值会直接写进调用参数。模板改动通常要重新审核，所以最好先在测试环境里跑通，再定稿。
密钥别用主账号
调用接口需要 AccessKey。主账号的密钥权限最大，一旦外泄，账号下的所有资源都可能被拿去用，短信费用只是其中一项。更稳妥的做法是在 RAM 访问控制里新建子用户，只授予短信服务的发送权限，再为它生成 AccessKey。密钥放进环境变量或密钥管理服务，不要写进代码，也不要提交到仓库。仓库即使之后删掉了文件，历史记录里仍然可能找得到它。
发送参数：键名和占位符要对上
阿里云为主流语言都提供了 SDK。不管用哪种语言，发送一条短信的核心参数基本一致：
- PhoneNumbers：接收号码。国内号码填 11 位数字；国际号码要带上区号，漏写区号是很常见的低级错误。
- SignName：审核通过的签名名称，需要和控制台里的写法一字不差。
- TemplateCode：审核通过的模板 ID。
- TemplateParam：模板变量，是一个 JSON 字符串。验证码模板里通常只有一个 code 字段，值为六位数字。
TemplateParam 的键名要和模板中的占位符完全对应。键名拼错、多传或少传，接口会直接返回错误，不会发出一条内容残缺的短信。这一点反而省心，出错时用户至少不会收到奇怪的内容。变量值的长度也要留意，超出模板要求的部分同样会被拒绝。
验证码被刷：一个教育团队的例子
下面是根据常见做法整理的示例，并非某个真实项目的完整记录。某在线教育团队的登录页直接调用短信接口发送验证码，前端没有任何限制。某天凌晨，短信量在短时间内明显上涨，其中大部分号码并不属于真实用户，费用来得很快，团队这才意识到问题。
后来他们做了三处调整。第一，点击“获取验证码”前加入图形验证码，只有通过人机校验的请求才会进入后端。第二，后端按手机号和 IP 分别限流：同一号码一分钟只能发一次，同一 IP 每天的上限单独设置。第三，验证码有效期定为五分钟，连续校验失败超过次数限制后，这一条验证码直接作废，不能再试。
三处改完后，异常发送量明显下降，正常用户的登录基本没受影响。不过阈值要按自己的用户量和业务高峰来定。一分钟一次、每天多少次，并没有放之四海而皆准的数字。照抄别人的参数，可能会误伤正常用户，比如网络不稳定时反复点击的人。
通知类短信：漏发比慢发更麻烦
电商的发货提醒、订单状态通知属于通知类模板。这类短信的发送失败率一般比验证码低，但一旦漏发，客服很快会被大量咨询淹没。某电商团队的做法比较务实：发送失败后按指数退避的方式重试，间隔逐次拉长，并设定重试上限。超过上限的记录会留存下来，交给人工或其他渠道处理。
另一件容易被忽略的事是对账。定期查询发送明细，把发送状态和订单系统做比对，找出状态异常或长期未送达的记录。没有这一步，团队只能等用户反馈才知道出了问题，那时往往已经晚了。
发送失败，先看错误码
接入过程中，多数问题集中在下面几类，排查时可以按这个顺序来：
- 模板与参数不匹配：检查 TemplateParam 的键名、变量值长度，以及模板内容是否和实际发送场景一致。
- 签名未生效或不匹配：确认签名已审核通过，并且与所用模板对应。不要用别的业务的签名去发模板。
- 号码格式：国内号码 11 位，国际号码带区号。前端输入时最好先做一次格式校验。
- 触发频率限制：测试阶段反复调用同一号码最容易碰到。可以准备几个固定的测试号码，不要在自己的手机上连续点击。
- 余额或资源包：账户余额不足，或资源包已用完，都会导致发送失败。这一项最容易被忽略，建议提前设置费用告警。
遇到错误时，先看接口返回的错误码，再去官方文档里找对应说明。大部分问题从返回信息就能定位，不必靠猜。把每次失败的请求参数和返回内容记录下来，下次遇到同样的问题，排查会快很多。
上线前过一遍
正式开放给真实用户之前，逐项确认几件事：子用户的密钥已经生效，且权限只包含短信发送；验证码接口已加上图形校验和频率限制；模板内容和实际发送场景一致；失败重试和回执对账已经接入；费用告警也已设置。这几项都确认后再放量，比上线后补救省事得多。
