简介阿里云短信接口开发示例压缩包面向需要快速对接短信服务的后端开发者适用于用户验证码、通知推送等场景。内容围绕阿里云短信服务的完整接入流程从账号注册、创建短信服务实例、申请AccessKey密钥到阅读官方SDK与API文档逐步说明SendSms接口的关键参数Action、PhoneNumbers、SignName、TemplateCode、TemplateParam以及模板变量的JSON格式用法并提示签名与模板需提前在后台审核配置。资源共92个文件包含68个C#源文件、18个动态链接库以及项目配置文件另有说明文档和示例图片压缩包仅485KB结构清晰便于查阅。源码内含可直接参考的发送短信实现、SDK依赖封装及HTTP调用示例并探讨了网络异常、错误码处理、重试机制以及短信频率限制和内容审核规则帮助开发者避开常见坑点。已有580人学习下载适合初次接触阿里云短信接口的开发者快速落地项目。1. 短信接口开发项目一条验证码背后的完整链路做用户注册、登录验证、订单通知短信几乎是每个业务系统都绕不开的基础能力。但短信服务跟普通 HTTP 接口不一样它不是一个 URL 就能调通的——签名要审核、模板要规范、频率有限流、返回码要处理这中间任何一环出问题线上就会直接丢消息。这个阿里云短信接口开发例子正好把从开通服务到发送成功的完整链路走了一遍适合两类人一是刚接手公司短信需求、想把验证码和通知功能跑起来的后端开发二是想搞懂短信服务底层到底怎么跟业务代码对接的进阶学习者。读完你会看到一套完整的工程写法而不是零散的 API 片段。2. 项目结构与技术选型从开通服务到工程落地2.1 工程目录一个短信模块在 Spring Boot 里怎么摆先说结论这个项目不是把所有短信逻辑堆在一个 Controller 里而是按「配置 - 客户端 - 服务 - 接口」四层拆开的。我拆解后的目录结构大致是这样src/main/java/com/example/sms/ ├── config/ │ └── SmsConfig.java # 读取 accessKey、签名、模板等配置 ├── controller/ │ └── SmsController.java # 对外暴露 HTTP 接口 ├── service/ │ ├── SmsService.java # 业务接口定义 │ └── impl/ │ └── SmsServiceImpl.java # 发送短信的核心逻辑 ├── model/ │ ├── SmsRequest.java # 请求参数封装 │ └── SmsResponse.java # 统一返回封装 └── SmsApplication.java # Spring Boot 启动类这个结构的价值在于Controller 只负责收参数、做基础校验Service 层处理业务规则和重试逻辑Config 层把密钥和模板配置跟代码隔离。我第一次接短信需求时把所有代码写在一个类里后来换签名、换模板要改源码重新部署踩了坑才明白分层的重要性。这里把配置独立出来后续对接多个签名或者多个模板时只改配置不动代码就能完成。资源里附带的SmsRequest对象做了参数校验比如手机号格式、模板参数是否为 JSON 字符串这些前置校验能挡掉一部分无效请求避免白白消耗短信条数。2.2 依赖选型新版 SDK 为什么比旧版省心阿里云短信的 SDK 有两代旧版aliyun-java-sdk-core加aliyun-java-sdk-dysmsapi的组合DefaultProfile那一套初始化方式写起来非常啰嗦新版则是dysmsapi20170525独立的模块Config对象直接初始化代码量少一半。这个项目用的是新版 SDK依赖大致长这样dependency groupIdcom.aliyun/groupId artifactIddysmsapi20170525/artifactId version3.0.0/version /dependency dependency groupIdcom.aliyun/groupId artifactIdtea-openapi/artifactId version0.2.5/version /dependencydysmsapi20170525是短信服务专用的 SDK里面封装了SendSms、QuerySendDetails、SendBatchSms这些接口的请求与响应模型。tea-openapi是阿里云 OpenAPI 的通用运行时负责处理 HTTP 通信和签名鉴权。两个依赖配合使用就能用流式的.setXxx()方法构造请求对象。装依赖有个小细节建议用 Maven 的dependencyManagement统一管理阿里云 SDK 版本因为多个阿里云服务一起接入时版本冲突会让运行时直接抛NoSuchMethodError这类问题排查起来比业务 bug 更费时间。2.3 前置准备签名和模板的申请才是真正的时间成本配置代码之前必须先在阿里云控制台完成三件事创建 AccessKey、申请短信签名、申请短信模板。AccessKey 在 RAM 访问控制里创建权限只需要AliyunDysmsFullAccess即可别给主账号的 AccessKey。签名和模板的审核是新手最容易卡住的环节。签名相当于发件人名称比如「某某科技」模板是短信的内容骨架比如「您的验证码为 ${code}5 分钟内有效」。审核规则有几个硬性要求签名必须跟企业名称、App 名称或公众号名称强关联个人开发者认证的账号申请签名时限制较多模板里的变量用${}包裹变量名不能是纯数字不能包含 URL 链接模板内容不能涉及营销、抽奖、返利等敏感词即使是测试内容也要避开提示测试阶段可以申请一个与业务强相关的签名模板内容明确写「测试」用途审核速度通常快一些。等项目上线前再补正式的签名和模板两条线并行能省不少等待时间。3. 核心模块拆解一次短信从组装到发送的完整链路3.1 配置加载与客户端初始化密钥不落代码SmsConfig这个类是整个短信模块的地基。它把 AccessKey、签名、模板编号等外部配置统一绑定到配置项上核心代码是这样的import com.aliyun.dysmsapi20170525.Client; import com.aliyun.teaopenapi.models.Config; import org.springframework.beans.factory.annotation.Value; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; Configuration public class SmsConfig { Value(${aliyun.sms.access-key-id}) private String accessKeyId; Value(${aliyun.sms.access-key-secret}) private String accessKeySecret; Value(${aliyun.sms.endpoint}) private String endpoint; Bean public Client smsClient() { Config config new Config() .setAccessKeyId(accessKeyId) .setAccessKeySecret(accessKeySecret); config.endpoint endpoint; return new Client(config); } }配置项通过Value注入意味着密钥不会出现在代码里。常见做法是在application.yml里用${ACCESS_KEY_ID}这类环境变量占位符引用或者对接配置中心动态刷新。这里把Client声明为Bean整个应用只维护一个短信客户端实例发送时复用连接资源比每次发送都 new 一个客户端高效得多。endpoint的值在阿里云短信服务文档里固定为dysmsapi.aliyuncs.com这个参数不能写错。我见过有人把其他服务的 endpoint 直接复制过来导致调用时报InvalidEndpoint。3.2 组装请求参数与发送主流程从手机号到消息落地的过程SmsServiceImpl里封装了发送的核心逻辑这也是整个项目最值得读的一段代码import com.aliyun.dysmsapi20170525.models.SendSmsRequest; import com.aliyun.dysmsapi20170525.models.SendSmsResponse; import com.alibabacloud.tea.TeaException; import org.springframework.stereotype.Service; Service public class SmsServiceImpl implements SmsService { private final Client smsClient; public SmsServiceImpl(Client smsClient) { this.smsClient smsClient; } Override public SmsResponse sendSms(SmsRequest request) { SendSmsRequest sendSmsRequest new SendSmsRequest() .setPhoneNumbers(request.getPhoneNumbers()) .setSignName(request.getSignName()) .setTemplateCode(request.getTemplateCode()) .setTemplateParam(buildTemplateParam(request.getParams())); try { SendSmsResponse response smsClient.sendSms(sendSmsRequest); return handleResponse(response); } catch (TeaException e) { // 捕获 SDK 抛出的业务异常e.getCode() 是阿里云返回的错误码 return SmsResponse.fail(e.getCode(), e.getMessage()); } } private String buildTemplateParam(MapString, String params) { // 将变量 Map 转换成模板所需的 JSON 字符串 return params.entrySet().stream() .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue)) .toString(); } }sendSms方法只做三件事构造请求、调用客户端、处理响应。SendSmsRequest有四个核心参数每个都不能缺phoneNumbers接收手机号国内短信直接传 11 位手机号国际短信需要加国家代码前缀比如 86 开头的8613800000000signName签名名称必须是已审核通过的签名比如「某科技」不带方括号templateCode模板编号形如SMS_123456789在控制台模板管理里能看到templateParam模板变量的实际值需要是 JSON 格式字符串比如{code:123456}这里有个容易翻车的点templateParam必须把变量名和模板里的${}内容做到一致。模板写的是${code}参数里就必须是code这个 key大小写、下划线都不能错。不一致时返回的错误码是isv.SMS_TEMPLATE_ILLEGAL但很多人看到这个错误会去怀疑模板状态其实问题出在参数组装上。捕获到的TeaException是阿里云 SDK 统一的异常类型e.getCode()返回的是业务错误码而不是 HTTP 状态码通过这个可以区分签名错误、模板错误、欠费、频率限制等不同场景。3.3 返回码处理与重试机制不是 sent 就结束了发送短信后服务端会返回一个Code字段OK表示发送成功其他都是失败。handleResponse方法里对此做了分流private SmsResponse handleResponse(SendSmsResponse response) { String code response.body.code; if (OK.equals(code)) { return SmsResponse.success(response.body.requestId); } // 记录失败日志方便后续排查 log.warn(短信发送失败code{}, message{}, requestId{}, code, response.body.message, response.body.requestId); return SmsResponse.fail(code, response.body.message); }requestId是一个很有用的排查线索。短信发送失败时把requestId提供给技术支持能直接定位到具体是哪条消息、在哪个环节被拦截。生产环境里建议把requestId连同手机号、模板编号一起存日志后续对账会方便很多。关于重试我的建议是不要对isv.BUSINESS_LIMIT_CONTROL流控限制做盲目重试这种场景重试只会加重限流。常见的重试策略是只对isp.SYSTEM_ERROR这类系统错误做最多两次退避重试间隔 3 秒、5 秒递增。代码里用的是最朴素的Thread.sleep加循环生产环境可以用 Spring 的Retryable注解来管理重试次数和退避策略。另外要明白发送成功不等于用户收到。阿里云短信的送达状态是通过消息回执异步通知的这个项目里虽没有实现回执接收但生产环境建议通过一个回调接口接收DeliveryStatus推送才能真正掌握每条短信的最终状态。这个后面在改造章节展开说。4. 踩坑记录签名、模板和频率限制的实战教训4.1 签名审核不通过内容写了「测试」被驳回现象申请签名「某科技」时用途说明填了「测试」审核被驳回理由是签名内容或用途不符合规范。原因签名审核规则要求签名必须与账号主体企业名称、App 名称、公众号名称有明确关联「测试」类用途在签名场景里通过率很低尤其是个人认证的账号基本会被打回。解决签名名称直接用公司简称或品牌名用途说明里写清楚业务场景比如「用户登录验证码短信」。另外签名申请前先确认企业认证是否完成个人认证的账号在签名数量、模板类型上都有更多限制顺手把认证升级了后续能省不少沟通成本。4.2 模板变量参数不是 JSON返回 isv.SMS_TEMPLATE_ILLEGAL现象控制台模板里写着您的验证码为${code}代码里setTemplateParam(code:123456)结果返回isv.SMS_TEMPLATE_ILLEGAL。原因templateParam必须是一个标准的 JSON 字符串键名要和模板变量完全一致。传入code:123456或者{code:123456}都不合法SDK 解析时就会报模板非法。解决用 JSON 工具类构造参数最简单的方式是JSONObject.toJSONString(paramsMap)。写代码时不要手动拼接 JSON 字符串一是容易出错二是遇到模板里有多个变量时很难维护。从那以后我每次接短信模板都先打印出templateParam的字符串确认是标准 JSON 再发请求。4.3 AccessKey 泄露到代码仓库一次惨痛的教训现象某次把配置类直接提交到了 Git 仓库几天后账号里多了大量非业务发送记录短信费用暴涨。原因AccessKey 属于高敏感凭证写到application.yml里提交到代码仓库后等于把钥匙交给了能读到仓库的任何人甚至会被爬虫扫到。解决立刻在控制台禁用并删除泄露的 AccessKey重新生成一对。代码里用环境变量或配置中心管理密钥application.yml里只写占位符比如${ALIBABA_CLOUD_ACCESS_KEY_ID}。项目里如果已经有历史提交记录还需要用 Git 过滤器清除历史中的密钥或者直接更换仓库不然密钥永远暴露着。现在我对所有涉及凭证的配置都会走一遍同样的检查代码仓库里搜索accessKey、secret、password关键词确保没有硬编码残留。4.4 手机号传了带「」号格式静默失败现象接口测试时用了8613800000000格式的手机号返回码是OK但用户收不到短信。原因阿里云短信的手机号参数要求是纯数字格式且不带国家代码前缀时不自动补带了号反而导致号码格式解析异常消息在网关处被静默丢弃。解决在SmsRequest里做入参规范化把、空格、横线等字符统一过滤掉。国际短信的需求单独走一个字段用国家代码加手机号的拼接方式不要直接在原号码上做字符串拼接。这个校验看着简单但漏掉了线上就会出现「发送成功但用户没收到」的投诉。4.5 批量发送用循环触发流控限制现象业务方要求一次给 200 个用户发通知直接在 for 循环里调用sendSms执行到第 50 条就报isv.BUSINESS_LIMIT_CONTROL。原因短信服务有默认的流控策略同一个签名或同一个模板的发送频率有上限短时间内高并发调用会被拦截。单条发送接口本身就不是为大批量场景设计的。解决改用SendBatchSms接口它支持一次传入最多 100 个手机号或者引入消息队列削峰把发送请求排队处理。这个项目里没有批量示例但改造时可以直接在代码里加一个sendBatchSms方法客户端同一个Client对象就能发送。5. 二次开发从单条发送到通知中心的三步改造拿到这个项目后想把它用在真实业务里建议顺着下面三步改造每一步都能独立验证效果。第一步扩展一个通用的短信模板配置表。项目里目前签名和模板编号是直接传参的业务一多调用方要记得一堆模板编码。常见做法是在数据库里建一张sms_template_config表字段为biz_type、template_code、sign_name、content_desc代码里按业务类型查表取模板而不是从请求里传。这样后续要换模板做 A/B 测试改表就能生效不用动代码。第二步对接送达回执。短信发送成功并不等于用户收到真实业务中用户反馈「没收到验证码」时你需要一个依据来判断是网关投递失败还是用户手机拦截。阿里云提供了消息回执推送需要在控制台配置回执 URL接收SmsReport和SmsUp消息。改造方法是在这个项目里新增一个SmsCallbackController接收 POST 请求解析 JSON 里的phone、success、err_code字段更新到短信发送记录表。做了这一步你的短信模块才真正具备追踪能力。第三步加发送记录表和幂等控制。每次发送都插入一条记录字段包括phone、template_code、template_param、send_status、request_id、create_time。配合一个简单的幂等逻辑同一手机号、同一业务类型、一分钟内不允许重复发送验证码。这个逻辑能挡住前端重复点击、流程重试导致的重复发送减少短信费用浪费也避免用户被连环短信轰炸。改造完这三步这个项目就从一个「能发短信的例子」变成了「可支撑业务的消息发送中心」。我自己改造时发现第三步的幂等控制最容易被忽略但上线后它带来的收益最直接——每月能省下相当比例的重复短信费用。从那以后我每次接短信需求都强制走一遍这个改造顺序先建配置表再接收回执最后做幂等。这套流程跑完短信模块的稳定性和可维护性都会提升一个档次希望帮到你。本文还有配套的精品资源点击获取