短信和普通接口调用不太一样。每一条都要走运营商通道，有成本，也直接落到用户手机上。阿里云对短信服务设限，一方面是防滥用、保护用户体验，另一方面也是为了满足通信行业的监管要求。开发者如果提前摸清这些限制，上线后遇到的突发故障会少很多。
常见的几类限制
用起来碰到的阿里云短信限制，大体可以归成下面几类：
- 签名和模板审核：签名、模板要先提交审核，没过审的内容发不出去。
- 频率限制：同一手机号在短时间内的发送次数有上限。超了，接口会返回限流错误，而不是发送失败的通用提示。
- 发送量与账户资质：未认证或资质较弱的账户，日发送量通常更低。
- 内容合规：文案里带敏感词，或者营销味太重，容易被拦截。
- 账户余额：余额不足或欠费时，请求会直接失败。
具体阈值会随政策和账户等级调整。别拿旧文章里的数字当依据，以控制台和官方文档的最新说明为准。
案例：验证码突然发不出去
某电商团队在一次营销活动后，注册页面突然收到大量“收不到验证码”的反馈。开发同学一开始怀疑通道出了问题，翻日志才发现接口返回的是频率限制的错误码。
问题出在哪
活动期间，前端在用户点了几次“获取验证码”之后，没有做倒计时控制。同一个手机号一分钟内被请求了十几次。后端也没有做节流，很快就触发了平台的频率限制，之后的请求全部失败。
怎么处理的
团队做了三件事。前端加上六十秒倒计时；后端按手机号和 IP 双维度限流；失败时返回明确的提示文案，不再直接把系统错误抛给用户。调整之后，验证码成功率明显回升，客服咨询也跟着少了。
开发阶段怎么规避
等线上出了问题再排查，代价通常不小。更省事的做法是在开发阶段就把限制算进去：
- 签名和模板尽早提交审核，别等到临近发布才去催。
- 测试环境用固定的测试号码反复调用，不要拿真实用户的手机号做压测。
- 业务层做好防重和限流，前端按钮和后端接口两边都要控。
- 发送失败时可以重试，但间隔要拉长，并设置次数上限，否则重试本身就会触发频率限制。
- 把每次调用的返回码记下来，配上监控告警。出问题时能很快看出是哪一类原因。
上线前的检查清单
正式启用短信功能之前，可以逐项对一下：
- 签名和模板都已通过审核，内容和实际业务场景对得上。
- 账户已完成实名认证，余额充足，并设置了用量提醒。
- 验证码接口已经有前后端双重限流。
- 错误码已经映射成用户看得懂的提示文案。
- 监控和日志能覆盖发送成功率、失败原因这些关键指标。
阿里云短信的限制本身不复杂。真正容易出事的，是业务侧没有提前预判。把限制当成系统设计的一部分来看，短信功能才能长期稳定跑下去。
