验证码、订单通知、物流提醒，这类消息对时效和到达率的要求都很高。不少团队一开始用自建通道或第三方小平台，用久了才发现账号分散、模板审核慢，出了问题也很难查。阿里云短信服务把通道、签名、模板和调用接口放进同一个控制台，中小团队的接入和维护成本都比较好控制。
这篇文章跟着一个小团队的迁移过程，讲清楚阿里云短信发送从开通到上线的几个环节，以及每一步要注意什么。界面和参数名以官方文档和控制台当前显示为准，细节可能随版本变化，上线前再核对一遍。
案例背景：生鲜配送团队的订单通知
一家做本地生鲜配送的小团队，日订单量在几千单左右。之前他们用一个小平台发送发货提醒，偶尔延迟，客服三天两头接到用户说“没收到短信”。技术负责人小周决定迁到阿里云，目标很具体：发送稳定，出了问题能快速查到原因，文案能按模板统一管理。
开通服务，先送审签名和模板
进入阿里云控制台，找到短信服务，完成实名认证并开通。发送任何短信之前，短信签名和短信模板都要先通过审核。签名一般是企业或产品名称，申请时需要提供营业执照等材料。模板是固定文案，可变的部分用占位符表示，比如“您的订单{code}已发货，请注意查收”。
小周在这一步踩过坑。他最早的模板用途写得太宽泛，类似“各类通知”，直接被退回。后来改成“订单发货通知”这样的具体场景，变量也只留必要的，一次就过了。模板越贴近真实业务，审核越顺利。文案里尽量不要出现营销词汇。
用子账号和最小权限代替主账号密钥
测试阶段直接用主账号的 AccessKey 调接口，还可以理解。上线后就不能这么做了。主账号权限很大，密钥一旦泄露，影响范围没法控制。更稳妥的做法是在访问控制（RAM）里建一个子账号，只授予短信服务相关权限，再为它生成 AccessKey。
小周把 AccessKey 放在服务器的环境变量里，代码仓库中不留任何密钥。这件事做起来不难，但很容易被忽略。临时写的脚本最容易把密钥硬编码进去，提交代码前要检查一遍。
发送接口的关键参数
阿里云短信服务提供标准的发送接口，核心参数大致如下：
- PhoneNumbers：接收手机号。多个号码用英文逗号分隔，且必须是国内号码格式。
- SignName：已审核通过的短信签名，名称要和审核时一致。
- TemplateCode：已审核通过的模板编号。
- TemplateParam：模板变量，以 JSON 字符串传入。变量名必须和模板里的占位符一一对应。
- OutId：可选的外部流水号。业务系统需要对账的话，建议带上。
小周在业务代码里对每个参数做前置校验。手机号先过一遍正则，模板变量为空就直接拦截，不等接口报错。这样既减少无效调用，日志也干净不少。
发送成功后，接口会返回请求 ID 和回执的基本信息。但接口返回成功，不代表用户已经收到。投递状态要通过回执查询或消息推送来确认。报表里的“发送成功”和用户手机上的“已送达”要分开统计，否则两边的数字对不上。
区分错误类型，再设计重试
网络抖动、限流、号码异常，都可能导致发送失败。小周把错误分成两类。一类是参数错误，比如模板未审核、号码格式不对，重试没有意义，记录下来并告警就行。另一类是临时错误，比如超时或服务端繁忙，可以用指数退避的方式重试两到三次。
验证码和通知类短信的重试策略要分开设计。验证码有时效，过了几十秒再重试，基本没有价值。订单通知可以把重试窗口放宽一些，但要防止同一个用户短时间内收到重复短信，那样体验会很差。
灰度上线与监控
正式切换前，小周先用测试号码小范围灰度，覆盖三大运营商和不同地区的号码，确认模板显示正常、变量替换没有问题。之后把流量从旧通道逐步切到新通道，每天对比发送量和回执率。
上线后，他在监控面板里设置了发送失败率、回执延迟和单日发送量波动这几项指标。失败率超过阈值时，系统自动通知值班人员。这套监控运行两周后，“没收到短信”的咨询明显少了，团队也能在用户反馈之前发现问题。
发送异常时的排查顺序
遇到发送异常，可以按下面的顺序查：
- 确认签名和模板仍是审核通过的状态。状态变过，就要重新核对一次。
- 核对 TemplateParam 的变量名和数量，必须和模板完全一致。少传一个变量，最常见的错误就是这个。
- 确认 AccessKey 对应的子账号有短信服务权限，并且密钥没有过期或被禁用。
- 用请求 ID 查发送记录，判断是接口调用失败，还是运营商侧没有投递成功。两种情况的处理方向不同，别混在一起查。
- 批量发送时，检查是否触发了频率限制。如果是，拆成小批次，批次之间加上间隔。
多数问题前三步就能定位，不必一上来就怀疑服务本身。
小结
阿里云短信发送要管好三件事：签名和模板提前送审，密钥用子账号做最小权限管理，发送和回执分开监控。小周的例子说明，小团队把这几个环节理顺，短信通道的稳定性和可维护性都能明显改善。上线前多做灰度，上线后盯住关键指标，大部分问题都能及时发现。
