发短信是很多产品绕不开的环节。验证码、订单通知、物流提醒、活动推广，都离不开它。阿里云短信的接口用起来不算复杂，开通之后容易卡住的地方通常是类型选错、签名对不上、模板写法被驳回。这篇按实际操作顺序讲一遍，最后用一个电商订单通知的例子串起来。
先想清楚你发的是哪一类短信
阿里云短信大致分两类场景：验证码类，以及通知营销类。这两类在审核口径、发送频率和计费上都不一样。选错了，模板多半会被驳回，或者发送量被限制。
- 验证码短信：用于登录、注册、找回密码、身份核验。内容固定，发送量大，对到达时间要求高。
- 通知类短信：用于订单状态、发货提醒、预约结果等，内容与用户刚做过的操作直接相关。
- 营销类短信：用于促销和活动推广。审核最严，要求用户明确同意接收，并提供退订方式。
项目初期就把类型定下来，申请签名和模板时才不容易来回改。
从开通到能发送，大致要走五步
- 注册阿里云账号，并完成实名认证。
- 进入短信服务控制台，按业务量购买或充值套餐。
- 申请短信签名。签名通常是企业名称、产品名称或网站名称，需要和资质信息一致，名称对不上是常见的卡点。
- 创建短信模板，变量用占位符表示，比如“您的验证码是${code}，5分钟内有效”。
- 创建 AccessKey。建议使用子账号或 RAM 用户的凭证，不要直接拿主账号密钥写进代码。
签名和模板的审核一般是几个小时到一两个工作日，以控制台显示为准。提交时把用途写具体。“用于通知”“用于系统消息”这类泛泛的说法，审核时很难判断，容易被打回。
案例：小电商的订单付款通知
假设一个小型电商团队要在用户付款成功后发一条订单确认短信。他们从模板开始做。
先写模板
模板内容是：“尊敬的用户，您的订单${orderId}已支付成功，预计${days}天内发货。”变量只放订单号和预计天数，不放收货地址之类的敏感信息。这类内容属于业务通知，通过率一般比营销类高。
用 Java SDK 发送
他们用的是阿里云官方 Java SDK。引入 aliyun-java-sdk-dysmsapi 依赖后，用 DefaultProfile 初始化客户端，构造发送请求，填入手机号、签名名称、模板编码和模板参数，再调用 sendSmsWithOptions 方法。AccessKey 从环境变量读取，不写进代码，也不提交到仓库。返回结果中 Code 为 OK，表示请求已提交。
接口返回成功，不等于用户收到
OK 只说明阿里云已经受理了请求。短信什么时候送达、是否送达，接口返回里看不出来。有些号码会因为运营商拦截或停机收不到，所以要配合短信回执查询或事件回调，把每条短信的最终状态记下来。对于反复失败的号码，设一个重试上限，否则同一个号码会一直重发，费用白白花掉。
用幂等防止重复发送
网络超时后重试很常见。如果没做处理，用户可能一次收到好几条相同的通知。这个团队的做法是：同一订单、同一状态只发一次。逻辑不复杂，但能直接减少用户投诉和无效的短信费用。
计费与发送频率
阿里云短信一般按条计费，不同地区、运营商和套餐档位的单价不一样。内容超过一定字数会被拆成多条计费，所以模板尽量写短。验证码场景要多防一层：设置单个号码每日发送上限，并在发送前加图形验证码校验，防止被人刷量。具体价格以阿里云官网最新公布为准，这里不列数字。
常见问题
- 模板被驳回：多数是内容和签名用途对不上，或者营销词出现在了被申请为通知类的模板里。
- 发送失败：先查 AccessKey 权限，再看签名和模板是否已审核通过，最后检查手机号是否为国际标准格式。
- 退订与授权：营销类短信要给出退订方式，发送前确认用户已授权接收。
- 数据安全：手机号属于个人信息，存储和传输都要加密，日志里不要打印完整号码。
刚接入时怎么走最稳
先用测试签名，拿几个自己的号码跑通完整流程，确认模板变量、回执和重试都正常，再开放给全部用户。量上来以后，再加监控告警和成本统计。这样出了问题，影响范围小，也好排查。
