1. 项目概述一个被低估却高频使用的短信验证工具类“AliYunSmsUtils阿里云短信验证 java源码”——光看这个标题你可能觉得它平平无奇不就是个调用阿里云短信服务的Java工具类吗但如果你在某电商后台改过注册流程、在某教育平台加过登录二次校验、在某政务系统对接过实名认证模块那你大概率已经和它打过照面甚至亲手复制粘贴过它的某段代码。它不是炫技的微服务架构也不是高并发的分布式消息队列而是一把被磨得发亮的螺丝刀小、准、快、稳专治“短信发不出去”“验证码总超时”“签名模板老驳回”这类让开发半夜爬起来改配置的现实问题。我接触这个工具类最早是在三年前一个社区团购小程序的二期迭代里。当时运营反馈用户注册转化率掉了一成排查下来发现是短信发送延迟平均达8秒以上部分安卓机型甚至收不到首条验证码。我们临时替换掉原生HTTP直连方案接入封装好的AliYunSmsUtils仅用半天就将首条短信到达时间压到1.2秒内失败率从3.7%降到0.14%。后来在多个跨行业项目中复用——某高校教务系统的选课抢号通知、某医疗器械公司的设备绑定校验、某跨境物流平台的运单状态变更提醒——它都成了短信链路里最不起眼却最扛压的一环。它解决的从来不是“能不能发”的技术哲学问题而是“能不能准时、准确、合规、可追溯地发出去”的工程落地问题。核心关键词“阿里云短信”“Java”“验证”三个词背后实际串联起的是国内主流云厂商的OpenAPI规范适配能力、Java生态下线程安全与异常兜底的设计意识、以及面向真实业务场景如防刷、限流、签名白名单、国际号码兼容的细节预判。这不是一份教你怎么写REST Client的入门教程而是一份浓缩了数十次生产环境踩坑后沉淀下来的“短信发送防御性编程手册”。适合谁参考如果你正在做Spring Boot项目需要快速集成短信功能如果你的团队没有专职运维来维护自建短信网关如果你被“签名审核不过”“模板变量报错”“AccessKey泄露风险”反复折磨或者你只是想搞懂为什么同样调用SendSms接口别人能稳定扛住每秒2000并发你的服务一到大促就503——那这份源码值得你逐行读完、动手改透、再放进自己的公共SDK里。2. 整体设计思路与架构选型逻辑2.1 为什么不用Spring Cloud Alibaba或官方SDK直接调用这是接手这个工具类时我问的第一个问题。阿里云官方确实提供了aliyun-java-sdk-dysmsapi文档齐全Maven坐标清晰连Demo都写好了。但真正在生产环境跑起来你会发现它像一辆出厂配置齐全的轿车——方向盘、油门、刹车都有但没装行车记录仪、没配胎压监测、油箱盖还得手动拧开。比如官方SDK默认使用HttpClient 4.x而很多老项目还卡在Java 7HttpClient 3.x强行升级可能引发Jackson版本冲突它把所有异常都包装成ClientException/ServerException但业务层真正关心的是“是不是签名没过审”“是不是手机号格式错误”“是不是今日额度用尽”而不是去parse exception.getMessage()里的中文提示更关键的是它不内置重试机制——网络抖动导致的SendSms调用失败得靠业务代码自己捕获、判断、sleep、再调用而短信这种强时效性场景重试策略必须精细到“首次失败后立即重试第二次失败后间隔1秒第三次失败后放弃并告警”官方SDK只给你抛异常不告诉你怎么救。AliYunSmsUtils的作者显然经历过这些。它的整体设计不是“如何调通API”而是“如何让调用过程对业务透明”。核心思路就三点协议解耦、异常归一、行为可控。协议解耦不硬绑死HTTP客户端。源码里定义了SmsClient接口底下有DefaultSmsClient基于Apache HttpClient、OkHttpSmsClient基于OkHttp、甚至预留了FeignSmsClient的扩展点。这意味着你可以根据项目现状无缝切换底层通信库而上层业务代码完全不用动。我见过最极端的案例是某银行内部系统因安全策略禁用所有非国密算法的SSL握手他们直接实现了一个BouncyCastleSmsClient复用AliYunSmsUtils的全部上层逻辑三天就完成合规改造。异常归一把阿里云返回的几十种错误码如isv.BUSINESS_LIMIT_CONTROL、isv.INVALID_TEMPLATE_PARAM、isv.SMS_SIGNATURE_ILLEGAL全部映射为枚举SmsErrorCode每个枚举值自带业务含义、处理建议、是否可重试标识。业务方只需写if (result.getErrorCode() SmsErrorCode.SIGNATURE_NOT_APPROVED) { alertOps(); }不用再对着文档查code。行为可控所有可配置项都外置化。短信签名、模板Code、AccessKey ID/Secret、RegionId、Endpoint、超时时间、重试次数、日志开关……全通过SmsConfig对象注入支持Properties/YAML/数据库动态加载。最关键的是它把“发送”这个动作拆成了三步validateParams()参数合法性校验、buildRequest()构造请求体、execute()执行HTTP调用每一步都可被子类覆盖。某社交App就利用这个特性在execute()前插入了Redis计数器校验实现“同一手机号1分钟内最多接收3条验证码”的风控逻辑而没动一行原有短信发送代码。这种设计不是炫技而是对Java工程化本质的理解稳定比新颖重要可维护比简洁重要可扩展比一时爽重要。当你在凌晨两点接到告警说短信发不出去时你会感激那个把重试逻辑封装在RetryableSmsClient里、连退避算法都写清楚注释的前任开发者。2.2 为什么选择Java而非Go/Python做短信工具有人会问现在Go写微服务、Python做脚本不是更香为什么还要用Java写这种“胶水层”工具答案藏在企业级应用的真实约束里。首先Java的JVM生态决定了它对“向后兼容”的极致苛刻。一个编译好的AliYunSmsUtils-1.2.0.jar能在JDK 8到JDK 17的任意环境中运行而无需担心Go的CGO依赖或Python的pip源冲突。某省级政务云平台就明确要求所有中间件必须提供JAR包理由很实在他们的容器镜像基线是OpenJDK 11但下属200多个区县系统还在用WebLogic 12cJDK 8统一升级成本太高。其次Java的线程模型和监控体系更成熟。短信发送虽是IO密集型但高并发下仍需精准控制连接池大小、超时阈值、线程数。AliYunSmsUtils默认使用HttpClient的PoolingHttpClientConnectionManager最大连接数、每个路由最大连接数、空闲连接回收时间都可配。而Go的goroutine虽轻量但一旦上游API响应变慢goroutine堆积会导致内存暴涨需要额外写pprof监控Python的GIL则让多线程并发发送变成伪命题只能靠multiprocessing又带来进程间通信开销。最后也是最容易被忽略的Java的异常处理语义最贴近短信业务的决策逻辑。比如“手机号格式错误”该立刻返回前端提示“签名未审核”该记录日志并通知管理员“余额不足”该触发充值告警。Java的checked exception机制虽然源码里没强制throws但设计上区分了SmsBusinessException和SmsSystemException天然引导开发者思考“这个错误我该怎么处理”而Go的error return或Python的try-except容易让人写成if err ! nil { log.Fatal(err) }这种反模式。所以这不是语言优劣之争而是场景匹配度问题。当你面对的是一个需要嵌入到Spring MVC、Dubbo、ShardingSphere等复杂中间件栈中的短信模块时Java的“笨重”恰恰成了它的护城河。2.3 验证场景的特殊性为什么不能简单当成普通HTTP请求很多人初学时有个误区把短信发送当成和调用天气API一样的普通HTTP请求。直到第一次遇到“用户说没收到验证码但日志显示发送成功”才意识到短信验证是个典型的“异步不可靠通道”。阿里云短信的调用链其实是你的服务 → 阿里云API网关 → 阿里云短信平台 → 运营商网关 → 用户手机。其中任何一环都可能出问题运营商网关拥塞、手机处于弱网状态、系统弹窗被用户误拒、甚至某些安卓定制ROM会静默拦截“验证码”关键词短信。这意味着API返回Success只代表阿里云平台已接收请求并不保证用户最终收到。AliYunSmsUtils正是基于这个认知设计的。它不提供sendAndBlockUntilReceived()这种幻觉接口而是明确区分两种模式同步发送模式默认调用sendSms()后立即返回SendResult包含RequestId用于后续查询、BizId用于回执查询、Code阿里云返回码。业务方需自行决定是否要轮询查询发送状态。异步回执模式配置enableReceiptCallbacktrue后工具类会自动注册一个HTTP回调地址如/sms/receipt当运营商返回送达回执时阿里云会POST数据到该地址。源码里内置了ReceiptHandler接口你可以实现自己的逻辑比如“收到送达回执后更新用户表的last_login_time字段”。更关键的是它内置了幂等性保障。验证码场景最怕重复发送用户狂点“获取验证码”后端没做防重结果同一手机号1分钟内收到5条既浪费钱又惹用户烦。AliYunSmsUtils通过SmsIdGenerator接口生成唯一BizId默认用UUID手机号MD5并配合Redis缓存sms:send:lock:${phone}实现“1分钟内相同手机号只允许成功发送1次”。这个设计不是银弹但它把“防重”这个通用需求变成了开箱即用的配置项。这种对业务本质的把握才是它超越普通HTTP工具类的核心价值。3. 核心细节解析与实操要点3.1 源码结构深度拆解不只是一个Utils类拿到源码第一眼你可能会被AliYunSmsUtils.java这个单文件吓到——2000多行代码密密麻麻全是方法。但别急着划走它的结构其实非常清晰按职责分成了五个逻辑块每个块都对应一个真实痛点第一块配置中心化管理SmsConfig这是整个工具类的基石。它不接受零散的String参数而是强制要求构建一个SmsConfig对象。里面最关键的不是AccessKey而是这几个常被忽略的字段regionId必须填cn-hangzhou杭州或ap-southeast-1新加坡填错直接404。很多人以为填https://dysmsapi.aliyuncs.com就行殊不知这是全球Endpoint实际调用时会302跳转到具体Region徒增延迟。endpoint建议显式指定比如https://dysmsapi.aliyuncs.com避免DNS解析失败。源码里做了容错如果配置为空则根据regionId拼接默认Endpoint。connectTimeoutMs/socketTimeoutMs默认3000ms但实测在弱网环境下运营商网关响应可能长达8秒。我建议生产环境设为connectTimeoutMs5000, socketTimeoutMs10000并配合重试。提示SmsConfig支持Builder模式但源码里隐藏了一个彩蛋——SmsConfig.fromProperties(Properties props)方法可以直接读取application.propertieskey名严格对应aliyun.sms.access-key-idxxx、aliyun.sms.template-codeSMS_123456789。这意味着你不用改一行代码就能把配置从硬编码迁移到Spring Boot的配置中心。第二块参数校验与标准化SmsParamValidator这里干了三件救命的事手机号清洗自动过滤空格、横杠、括号支持8613812345678、138-1234-5678、(138) 1234-5678等多种格式统一转为13812345678。某金融客户曾因用户输入86-13812345678带国家码横杠被阿里云拒绝加了这行清洗后问题消失。模板变量校验检查${code}、${product}等占位符是否在模板内容中真实存在。避免“模板里写的是${code}代码里传的是params.put(verificationCode, 123456)”这种低级错误。签名白名单校验SmsConfig里可配置allowedSignNames[XX科技, YY平台]发送时自动校验signName是否在列表中。防止测试环境误用生产签名。第三块请求构造与签名SmsRequestBuilder这是最体现阿里云SDK功底的部分。AliYunSmsUtils没有简单拼接URL而是完整实现了 阿里云OpenAPI签名机制 步骤1对所有请求参数包括Signature按字典序排序步骤2URL编码键值对格式为key1value1key2value2步骤3拼接GET%2F URL编码后的字符串注意%2F是/的编码步骤4用HMAC-SHA1算法以AccessKeySecret 为key对步骤3结果签名步骤5Base64编码签名结果作为Signature参数源码里buildCanonicalizedQueryString()方法就是干这个的。我建议你把它抽出来单独测试——写个单元测试用已知的AccessKeySecret和参数对比生成的Signature是否和阿里云控制台调试工具一致。这能帮你彻底理解签名原理避免因编码差异如空格编码为还是%20导致签名失败。第四块HTTP执行与重试SmsHttpClient默认实现DefaultSmsHttpClient用了Apache HttpClient 4.5.x关键配置都在createHttpClient()方法里// 连接池最大总数 pool.setMaxTotal(200); // 每个路由最大连接数避免单个域名占满池子 pool.setMaxPerRoute(50); // 空闲连接存活时间避免DNS变更后连接失效 pool.setValidateAfterInactivityMs(5000); // 自动重试3次但仅对IOException重试如网络超时、连接拒绝 requestConfig.setSocketTimeout(10000); requestConfig.setConnectTimeout(5000);特别注意setValidateAfterInactivityMs(5000)——这是很多团队忽略的点。阿里云的Endpoint DNS可能变更如果连接池里的连接长期空闲下次复用时可能连到旧IP导致失败。这个配置让HttpClient在复用前先检查连接是否过期过期则重建。第五块结果解析与异常映射SmsResponseParser它把阿里云返回的JSON响应如{Message:OK,RequestId:ABC-123,Code:OK}解析为SendResult对象并做两件事如果Code不是OK则根据Message内容匹配预设的SmsErrorCode枚举。比如Message含签名未审核就映射为SIGNATURE_NOT_APPROVED。提取BizId并存入SendResult这是后续查询回执的唯一凭证。源码里特意加了注释“BizId由阿里云生成长度固定24位形如123456789012345678901234请妥善保存”。这五块环环相扣共同构成了一个“拿来即用改之即稳”的短信工具链。它不是教你造轮子而是告诉你一个工业级轮子应该长什么样。3.2 安全红线AccessKey管理的三种正确姿势AccessKey是阿里云API的命门泄露账户沦陷。AliYunSmsUtils源码里SmsConfig的accessKeySecret字段被标记为Deprecated这不是代码坏味道而是安全警示。它强制你必须通过安全方式传入密钥姿势一环境变量注入推荐给容器化部署在Kubernetes Deployment里这样写env: - name: ALIYUN_SMS_ACCESS_KEY_ID valueFrom: secretKeyRef: name: aliyun-sms-secret key: access-key-id - name: ALIYUN_SMS_ACCESS_KEY_SECRET valueFrom: secretKeyRef: name: aliyun-sms-secret key: access-key-secret然后在Java里SmsConfig config SmsConfig.builder() .accessKeyId(System.getenv(ALIYUN_SMS_ACCESS_KEY_ID)) .accessKeySecret(System.getenv(ALIYUN_SMS_ACCESS_KEY_SECRET)) // ...其他配置 .build();好处是密钥不进代码、不进镜像且K8s Secret支持加密存储。姿势二配置中心动态加载推荐给微服务架构用Nacos/Apollo时创建配置项aliyun.sms.access-key-idxxx aliyun.sms.access-key-secretyyy然后写个NacosSmsConfigLoader监听配置变更动态刷新SmsClient实例。某电商大促期间就靠这个实时切换了备用AccessKey主Key被恶意刷单耗尽额度全程无重启。姿势三KMS密钥解密推荐给金融/政务等强合规场景把加密后的AccessKey存入数据库启动时调用阿里云KMS的Decrypt接口解密。源码里预留了SecretDecryptor接口public interface SecretDecryptor { String decrypt(String encryptedSecret); }你可以实现KmsSecretDecryptor在SmsConfig.builder().secretDecryptor(new KmsSecretDecryptor()).build()里传入。这样密钥明文永远不会出现在内存堆栈里符合等保三级要求。注意绝对禁止以下操作把AccessKey写死在application.properties里在Git提交记录里搜索到accessKeySecret用System.setProperty()动态设置会被JVM参数dump出来在日志里打印SmsConfig.toString()会泄露密钥我见过最惨的案例是某创业公司开发者为图方便把AccessKey写在GitHub公开仓库三天后被黑客扫出发了200万条垃圾短信账单高达17万元。安全不是功能是底线。3.3 验证码场景的四大避坑指南短信验证不是发条通知那么简单它直面用户承载信任任何一个细节疏忽都会导致转化率暴跌。AliYunSmsUtils虽好但用错场景照样翻车。结合我踩过的坑总结四个必须知道的实战要点坑一模板变量大小写敏感但控制台不报错阿里云模板里写的是${code}你代码里传params.put(CODE, 123456)结果短信里显示${code}原样。因为模板引擎是严格按key名匹配的。AliYunSmsUtils的SmsParamValidator做了基础校验但不会帮你纠正大小写。我的做法是在buildRequest()前加一行// 强制转换为小写适配阿里云模板习惯 MapString, String safeParams params.entrySet().stream() .collect(Collectors.toMap( e - e.getKey().toLowerCase(), Map.Entry::getValue ));坑二国际号码格式不统一运营商拒收国内手机号13812345678没问题但发给海外用户1234567890可能被拒。阿里云要求国际号码必须带国家码且无号如美国号码应为1234567890前面补1日本为81312345678。源码里PhoneNumberUtil类提供了normalizeInternationalNumber()方法但默认不启用。你需要显式调用String normalizedPhone PhoneNumberUtil.normalizeInternationalNumber(1-234-567-890); // 返回 1234567890坑三高并发下Redis锁粒度太粗导致发送延迟默认的sms:send:lock:${phone}锁如果1000个用户同时请求验证码它们会排队获取锁第1000个用户可能等5秒。优化方案是“双锁”先用布隆过滤器BloomFilter快速判断该手机号是否在1分钟内已发送过命中则直接返回未命中再走Redis锁。AliYunSmsUtils预留了RateLimiter接口你可以实现BloomRateLimiter用Redis Bitmap做轻量级布隆过滤器。坑四用户收不到但日志显示Success查无此证这是最折磨人的。根源在于阿里云的“发送成功”只代表进入其队列不保证送达。解决方案是开启回执查询。在SmsConfig里配置.enableReceiptCallback(true) .receiptCallbackUrl(https://your-domain.com/sms/receipt)然后实现ReceiptHandlerpublic class MyReceiptHandler implements ReceiptHandler { Override public void handle(Receipt receipt) { if (SUCCESS.equals(receipt.getStatus())) { // 更新用户表标记验证码已送达 userDao.updateSmsStatus(receipt.getBizId(), DELIVERED); } else if (FAILED.equals(receipt.getStatus())) { // 触发重发或告警 alertService.send(短信送达失败: receipt.getReason()); } } }这样当用户说“没收到”你查数据库就能确认是“根本没发出去”还是“发出去但运营商没送到”排查效率提升十倍。4. 实操过程与核心环节实现4.1 从零开始集成Spring Boot项目实操步骤假设你正在一个Spring Boot 2.7.x项目中集成短信验证以下是完整、可复制的操作流程。我以一个真实的电商后台“用户注册验证码”功能为例每一步都附带命令和截图说明文字版。第一步添加Maven依赖在pom.xml中加入dependency groupIdcom.example/groupId artifactIdaliyun-sms-utils/artifactId version2.3.0/version /dependency !-- 注意如果项目已用HttpClient 4.5.x无需额外引入 -- !-- 如果用OkHttp需添加 -- dependency groupIdcom.squareup.okhttp3/groupId artifactIdokhttp/artifactId version4.11.0/version /dependency提示不要用scopesystem/scope引用本地jar这会导致CI/CD构建失败。正确做法是把jar发布到公司Nexus私服或用JitPack托管GitHub仓库。第二步配置阿里云短信参数在application.yml中写aliyun: sms: access-key-id: LTAI5tQZzXxxxxxx # 从RAM控制台获取 access-key-secret: 5jVqZxxxxxx # 同上注意保密 region-id: cn-hangzhou endpoint: https://dysmsapi.aliyuncs.com sign-name: 电商小站 template-code: SMS_123456789 connect-timeout-ms: 5000 socket-timeout-ms: 10000 max-retry-times: 2然后创建配置类Configuration ConfigurationProperties(prefix aliyun.sms) Data public class AliyunSmsProperties { private String accessKeyId; private String accessKeySecret; private String regionId; private String endpoint; private String signName; private String templateCode; private int connectTimeoutMs; private int socketTimeoutMs; private int maxRetryTimes; }第三步编写SmsService业务类Service public class SmsService { private final SmsClient smsClient; public SmsService(AliyunSmsProperties props) { // 构建SmsConfig SmsConfig config SmsConfig.builder() .accessKeyId(props.getAccessKeyId()) .accessKeySecret(props.getAccessKeySecret()) .regionId(props.getRegionId()) .endpoint(props.getEndpoint()) .signName(props.getSignName()) .templateCode(props.getTemplateCode()) .connectTimeoutMs(props.getConnectTimeoutMs()) .socketTimeoutMs(props.getSocketTimeoutMs()) .maxRetryTimes(props.getMaxRetryTimes()) .build(); // 创建客户端推荐用OkHttp性能更好 this.smsClient new OkHttpSmsClient(config); } /** * 发送注册验证码 * param phone 手机号11位纯数字 * param code 验证码6位数字 * return SendResult */ public SendResult sendRegisterCode(String phone, String code) { // 参数校验 if (!Pattern.matches(^1[3-9]\\d{9}$, phone)) { throw new IllegalArgumentException(手机号格式错误); } if (!Pattern.matches(^\\d{6}$, code)) { throw new IllegalArgumentException(验证码必须为6位数字); } // 构建模板参数 MapString, String params new HashMap(); params.put(code, code); // 注意key必须和模板里一致 try { // 调用发送 return smsClient.sendSms(phone, params); } catch (SmsException e) { // 统一异常处理 log.error(发送注册验证码失败手机号{}错误码{}消息{}, phone, e.getErrorCode(), e.getMessage(), e); throw new ServiceException(验证码发送失败请稍后重试, e); } } }第四步Controller暴露接口RestController RequestMapping(/api/sms) public class SmsController { private final SmsService smsService; private final RedisTemplateString, Object redisTemplate; public SmsController(SmsService smsService, RedisTemplateString, Object redisTemplate) { this.smsService smsService; this.redisTemplate redisTemplate; } PostMapping(/register-code) public ResultString sendRegisterCode(RequestParam String phone) { // 1. 防刷1分钟内同一IP最多请求5次 String ip getClientIp(); String ipKey sms:ip: ip; Long ipCount redisTemplate.opsForValue().increment(ipKey, 1); if (ipCount 1) { redisTemplate.expire(ipKey, 60, TimeUnit.SECONDS); } if (ipCount 5) { return Result.fail(请求过于频繁请1分钟后重试); } // 2. 防重1分钟内同一手机号只发1次 String phoneKey sms:phone: phone; Boolean isSent redisTemplate.hasKey(phoneKey); if (Boolean.TRUE.equals(isSent)) { return Result.fail(验证码已发送请勿重复提交); } // 3. 生成6位随机验证码 String code RandomStringUtils.randomNumeric(6); // 4. 发送短信 SendResult result smsService.sendRegisterCode(phone, code); // 5. 保存验证码到Redis5分钟过期 redisTemplate.opsForValue().set(verify:code: phone, code, 5, TimeUnit.MINUTES); // 6. 记录发送成功用于监控 redisTemplate.opsForValue().set(phoneKey, sent, 60, TimeUnit.SECONDS); return Result.success(发送成功); } private String getClientIp() { // 真实项目需从X-Forwarded-For头获取 return 127.0.0.1; } }第五步测试与验证启动项目用curl测试curl -X POST http://localhost:8080/api/sms/register-code?phone13812345678正常返回{code:200,message:发送成功,data:null}同时查看日志应看到类似INFO c.e.s.SmsService - 发送短信成功手机号13812345678RequestIdABC-123BizId123456789012345678901234此时去阿里云短信控制台的“发送记录”页搜索13812345678应能看到状态为“发送成功”。等待约30秒再查Redisredis-cli get verify:code:13812345678 # 应返回 123456整个流程从配置到可用不超过30分钟。这就是AliYunSmsUtils的价值它把“调通API”的时间压缩到极致让你聚焦在真正的业务逻辑上。4.2 关键参数计算与调优实践参数不是随便填的每个数字背后都有血泪教训。以下是我在不同规模项目中验证过的最优配置连接池参数HttpClient项目规模最大总连接数每路由最大连接数空闲连接存活时间依据日活1万502030秒小流量避免连接泄漏日活10万200505秒大促峰值QPS约300按1.5倍冗余日活500万10002001秒全链路压测发现空闲连接超过2秒易被运营商网关断开计算逻辑假设峰值QPS为P平均响应时间为T秒则理论所需连接数 ≈ P × T。但必须考虑突发流量所以乘以安全系数1.5~2。例如P500T0.02秒则基础连接数10但实际配200留足缓冲。超时时间毫秒connect-timeout-ms: 5000 # 建立TCP连接的最长等待时间 socket-timeout-ms: 10000 # 建立连接后等待响应的最长等待时间为什么不是更短因为阿里云短信API在大促时后端处理可能达3~5秒。设成3000ms会导致大量超时重试反而加重压力。实测数据杭州Region平均响应120ms99分位2.3秒新加坡Region平均380ms99分位8.1秒。所以socket-timeout-ms必须大于99分位值。重试次数与退避策略源码默认重试2次策略是固定间隔1秒。但更优的是指数退避public class ExponentialBackoffRetryer implements Retryer { private final int maxRetries; public ExponentialBackoffRetryer(int maxRetries) { this.maxRetries maxRetries; } Override public boolean shouldRetry(int attempt, Exception e) { if (attempt maxRetries) return false; if (e instanceof IOException) return true; // 网络异常可重试 if (e instanceof SmsSystemException) return true; // 系统异常可重试 return false; // 业务异常不重试 } Override public long getDelayMillis(int attempt) { // 第1次重试延时1秒第2次2秒第3次4秒... return (long) Math.pow(2, attempt - 1) * 1000; } }这样既避免雪崩又给系统恢复时间。某直播平台用此策略后短信失败率从1.2%降至0.03%。并发线程数Spring Boot如果你用Async异步发送线程池配置至关重要Configuration EnableAsync public class AsyncConfig { Bean(smsTaskExecutor) public Executor smsTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); // 核心线程数 executor.setMaxPoolSize(50); // 最大线程数 executor.setQueueCapacity(1000); // 队列容量 executor.setThreadNamePrefix(sms-async-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); return executor; } }为什么队列容量设1000因为短信发送是IO密集型线程大部分时间在等网络响应所以可以适当放大队列避免任务被拒绝。CallerRunsPolicy是最后防线当队列满时由调用线程自己执行任务保证不丢消息。这些参数不是玄学而是