GreedyAbyss做短信验证码登录这件事，我前前后后在好几个项目里都接过，从最简单的单机应用，到后面基于若依微服务框架的一整套环境迁移到阿里云ECS，中间踩过的坑可以说相当多。最惨的一次是上线当晚，用户怎么点都收不到验证码，排查到快崩溃，最后发现是RAM子账号权限漏了一条。这篇文章就把我整个使用阿里云短信的过程记录下来，从开通配置、签名模板申请、验证码登录的完整实现，再到接口测试、若依框架集成、以及迁移云环境和压测时的注意事项，全部摊开来讲，希望能帮你少走点弯路。
1. 项目背景：短信在业务系统里到底承担了什么
1.1 从场景反推需求
很多人一说到“发短信”，第一反应就是发验证码。但实际接进系统之后你会发现，短信的用途远比这个广：
- 用户注册和登录时的验证码，这是最核心的场景；
- 密码找回、手机号换绑时的身份校验；
- 订单状态变更、支付结果、系统告警的通知推送；
- 运营活动里的营销短信。
不同场景对短信的要求不太一样：验证码类看重到达速度和成功率，通知类看重模板规范和发送量，营销类则更关注成本和审核规则。大多数项目最初都是从验证码登录入手的，所以这篇文章会以“手机号+验证码登录”为主线，再往外延伸到通知类和测试、部署、压测这些周边环节。
我当时手里那套业务系统，用户量不大，但对短信的稳定性要求极高。客户的诉求很直接：手机号能收码、登录不卡顿、发送记录可追溯、费用可控。这几个要求看起来简单，真正落地时涉及的东西却不少，包括短信服务商的选型、签名和模板审核、后端接口设计、频控策略、日志埋点，甚至压测时如何避免把短信额度打爆。这些我都会在后文里面逐个展开。
1.2 为什么选了阿里云短信
市面上短信服务商很多，云厂商、短信平台、短信猫一类的第三方都有。我当时对比了一圈，最后定下阿里云，主要基于这几点：
第一，接口稳定，生态完善。阿里云短信服务（Dysmsapi）作为云上标准产品，OpenAPI很规范，SDK覆盖了Java、Python、Go、Node.js等主流语言，文档还算清晰。对于团队来说，能减少学习和接入成本。
第二，和业务系统部署环境能直接打通。如果业务都在阿里云ECS上，短信API走内网或公网都方便，网络延迟和稳定性更有保障。这一点在我们后来做ECS迁移和压测时体现得很明显。
第三，控制台的可视化能力够用。签名、模板的审核状态，发送记录的查询，套餐包的用量统计，都有现成的界面，不用自己再造轮子。
第四，费用透明，按量付费。对于中小规模业务，成本可控，而且有套餐包可以抵扣，对预算敏感的项目比较友好。
当然，阿里云不是唯一选择。如果你只需要极低量的通知短信，或者业务高度依赖某个特定运营商的通道，可能其他服务商更适合。但从通用性和长期维护的角度看，阿里云是很稳的默认选项。
提示：选短信服务商时不要只看单价，还要关注到达率、审核时效、支持的语言和地区、以及是否有专门的客服对接。有些短信平台价格便宜，但审核能卡你两三天，关键时候很耽误事。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 开通与准备工作：从控制台到AccessKey，这些细节别忽略
2.1 开通短信服务和购买套餐包
登录阿里云控制台，搜索“短信服务”，进入产品页后按提示开通。这一步本身很简单，但有几个容易被忽略的点：
- 账号需要完成实名认证。个人认证可以申请部分签名，企业认证能申请更规范的签名和更多类型模板。如果项目主体是公司，建议尽早用企业账号认证，不然后面申请签名会卡壳；
- 开通服务后要先检查“套餐包”。短信是按条数计费的，可以先买一个小的套餐包用于测试，避免测试阶段把账户余额烧太多。购买时注意套餐包有效期的限制，有些特价包只有几个月有效期，别囤太多；
- 查看“免费额度”。部分新用户可能有免费短信条数，可以用于功能联调，但开通之前要看清楚额度是否适用于签名模板类型。
我自己的经验是：开通短信服务这件事要提前做，千万不要等代码写完了才去开通。有次项目赶工，我提前把签名和模板申请了，结果客户资料那边出了问题，模板审核卡了两天，差点影响上线计划。后来凡是接短信的项目，我都会把“开通+签名+模板”放到项目启动第一周。
2.2 创建RAM子用户和AccessKey，别用主账号密钥
AccessKey是调用短信API时用来标识身份的密钥，由AccessKey ID和AccessKey Secret组成。很多新手图省事，直接用主账号的AccessKey，这其实非常危险。主账号密钥一旦泄露，等于整个云账号对别人敞开了大门。
正确的做法是：
- 在阿里云控制台进入RAM访问控制；
- 创建子用户，例如“sms-sender”，并且只授予短信发送相关的权限；
- 为该子用户创建AccessKey；
- 在代码或配置文件中使用这个子用户的AccessKey，不要暴露明文到前端或Git仓库。
我踩过的一个坑就是：给子用户配的权限是“AliyunDysmsFullAccess”，但实际调用时却报“NoPermission”，后来才发现RAM里有些默认的SystemPolicy并不包含短信服务的全部操作，需要手动添加自定义授权或选择正确的系统策略。经验是：在RAM授权时，直接搜索“Dysms”或“短信”相关权限，仔细核对之后再保存。
AccessKey的管理还有几个小建议：
- 定期轮换密钥，尤其是有人离职时要及时禁用或删除；
- 使用阿里云KMS或配置中心来管理密钥，尽量不写在配置文件里；
- 如果代码仓库是公开的，记得先检查历史记录里有没有泄露过AccessKey，阿里云控制台有安全告警功能，会提示是否存在泄露风险。
2.3 申请签名和模板：一次过审的实操要点
阿里云短信发送前必须准备好两样东西：签名和模板。
签名就是用户收到短信时显示的发送方名称，比如“【XX云】”。申请的时候根据账号认证类型，需要提交对应的资质材料。个人用户通常可以申请“APP名字”、“网站名字”或“个人名字”等签名；企业用户则可以用企业全称、简称、产品名称等作为签名。
我这边实际申请时的经验：
- 签名的名称要和资质材料一致，不要搞什么“XX客服”这类模糊的名字，审核很可能被打回；
- 申请后状态会经历“审核中 → 通过/拒绝”，一般在几小时到一天内出结果，但高峰期可能要等更久，所以一定要预留时间；
- 如果被拒，控制台会给出原因，常见的比如“签名与实际网站或APP不一致”、“材料模糊不清晰”，按提示修改后重新提交就行。
模板则是短信内容的格式，比如“您的验证码为${code}，5分钟内有效。”这里的${code}是一个变量，发送时由接口参数填进去。写模板时有几个规范要特别注意：
- 不能包含敏感词、广告词、促销词，个人开发环境下尤其要注意；
- 变量不能自定义太多，一般一个模板允许的变量数量有限，而且变量名最好用英文