阿里云短信服务让开发者通过 API 或控制台给手机号发送短信。验证码、订单通知、营销推广都能走这套服务，不必自己对接运营商。对中小团队来说，主要有两个好处：接入快，按量计费，发多少付多少。
先分清三类模板
阿里云短信里，每条短信都要套用一个已审核通过的模板。模板按用途分三类，选错类型轻则发送失败，重则被拦截。发送前先想清楚这条短信要做什么，再选类型。
- 验证码类：用于登录、注册、找回密码。内容里只放验证码和有效期这类固定信息，不要夹带促销文字。
- 通知类：用于订单状态、物流进度、预约提醒等服务性消息。变量要和业务动作一一对应，比如订单状态变了，短信里的状态文字也要跟着变。
- 推广类：用于促销和活动。必须附上退订方式，并且只在规定时段发送。
上手的五个步骤
- 开通服务并充值：登录阿里云控制台，进入短信服务完成开通。余额不足时调用会失败，上线前先确认余额够用。
- 申请签名：签名是短信开头的【公司或品牌名】。企业签名需要提交营业执照等资质。提交前核对签名名称和资质上的名称是否一致，名称对不上，审核时容易被退回。
- 提交模板：按类型写好内容，变量用占位符表示，例如“您的验证码是${code}，5分钟内有效”。一条模板只写一种用途，不要把通知和推广混在同一条里。变量不宜过多，文字也要具体，不要写“请注意查收”这类空话。
- 获取 AccessKey：在访问控制里创建子账号，只授予短信相关权限，不要直接用主账号的密钥。密钥放在环境变量里，不要写进代码，也不要提交到代码仓库。
- 调用接口测试：先用自己的手机号发一条验证码，检查签名、模板和变量是否都正常。最好再找两三个不同运营商的号码试一遍，确认没问题后再上线。
接口调用一般直接用官方 SDK。Java、Python、Node.js、Go 等语言都有对应版本。第一次接入时，最省事的做法是照着官方示例先跑通一条短信，再逐步加上业务逻辑。
案例：一家社区生鲜店的短信改造
下面是一个示意场景，文中的数字都是假设值，只用来演示计算方法，不代表真实数据。
某社区生鲜店原先靠人工在微信群里通知顾客取货。每天约 300 个订单，店员每天要花两个小时回复消息，还经常漏发。团队在阿里云短信上配置了两个通知模板：一个用于“订单已打包，请到店取货”，另一个用于“配送员已出发”。接入后，订单状态一变化，系统就自动发送短信。
按假设计算，每条通知算作一个计费单位，每天 300 条，一个月约 9000 条。这笔开销远低于一名兼职店员的工时。更直接的变化是，假设漏发率从 8% 降到接近零，客服咨询量减少了一半左右。团队需要用自己的真实数据替换这些数字，再对外使用。
费用与常见坑
短信按条计费，不同内容类型和地区的单价不同，国际短信单价更高。中文短信每条字数有上限，超出后会拆成多条计费，所以模板文字要精简。价格以阿里云官网公示为准，上线前到计费页面核对一次。
下面几个坑，大多出现在申请和发送阶段：
- 签名或模板被驳回，多半是用途描述写得不清楚，或者内容里带了营销词。补充说明时写清实际业务场景，例如“用户下单后的订单状态通知”，比只写“通知”更容易通过。
- 验证码模板里加入推广文字，会被判定为违规。验证码短信就只放验证码和有效期。
- 营销短信没有退订方式，既可能被投诉，也不符合相关规定。退订方式要写进模板，用户退订后要真的停止发送。
- 营销短信不应在晚上十点到次日早上八点之间发出。定时任务要避开这个时段，否则系统自动发出的消息也会违规。
- 验证码接口如果没有限制，容易被人刷量，产生不必要的费用。业务层要限制同一手机号每分钟、每天的发送次数，并在前端加上图形验证等前置校验。
合规要靠流程
短信直接到达用户手机，合规问题会持续影响发送效果。团队需要记录每条营销短信的用户授权来源，包括用户在哪里、什么时候同意接收。
另外，要定期清理长期不互动的号码，避免反复发给不关心的人。发送日志也要保留，出现投诉或纠纷时才查得到依据。把这些步骤写进运营手册，比出了问题再补救省力得多。
