1. 先別急著寫代碼短信服務(wù)商的選型邏輯和那些被忽略的坑做Java后端的朋友遲早都會接到短信需求?？赡苁怯脩糇詴r的驗證碼可能是登錄二次校驗也可能是訂單通知、營銷觸達(dá)。我第一次接到短信接口對接任務(wù)時第一反應(yīng)是這有什么難的找個服務(wù)商SDK調(diào)一下就行了結(jié)果真正落地的時候才發(fā)現(xiàn)短信接口遠(yuǎn)不止調(diào)一個API這么簡單。這篇內(nèi)容我就以Spring Boot項目為例把從零對接短信接口的全流程拆開來講包括服務(wù)商如何選、配置怎么管、驗證碼怎么存、異步發(fā)送怎么做、回調(diào)怎么接、生產(chǎn)環(huán)境還有哪些必須處理的細(xì)節(jié)。適合剛接觸短信開發(fā)的后端工程師也適合準(zhǔn)備在自己的項目里接入短信驗證碼功能的朋友參考。先說結(jié)論短信服務(wù)商選型基本決定了你后面80%的踩坑體驗。市面上主流的國內(nèi)服務(wù)商就是阿里云、騰訊云、華為云這幾家還有一堆中小型短信平臺。我自己的判斷標(biāo)準(zhǔn)就三條第一是到達(dá)率和穩(wěn)定性第二是SDK質(zhì)量和文檔完善度第三是審核速度和售后響應(yīng)。價格其實反而沒那么關(guān)鍵短信本身就不貴一條幾分錢真正貴的是你上線之后發(fā)現(xiàn)到達(dá)率低、用戶收不到驗證碼導(dǎo)致流失的隱性成本。我最終選的是阿里云的短信服務(wù)一是因為他家SDK更新積極Java調(diào)用方式比較統(tǒng)一二是文檔和示例相對完善遇到底層報錯能查到解決方案三是簽名和模板審核有獨(dú)立的控制臺入口操作路徑清晰。騰訊云我也用過主要是它有個很實用的能力——正文模板內(nèi)支持變量動態(tài)拼接做營銷類通知很方便但如果你只是做驗證碼場景阿里云和騰訊云差別不大。選型階段還有兩個前置工作必須提前做因為它們的審核周期會直接影響你的上線計劃。一個是申請短信簽名一個是申請短信模板。簽名就是用戶收到短信時看到的發(fā)送方名稱比如某某科技模板就是你短信正文的格式比如您的驗證碼為${code}5分鐘內(nèi)有效。審核時長一般是一到兩個工作日如果涉及行業(yè)資質(zhì)可能更久。所以我的建議是項目啟動第一天就把簽名和模板申請?zhí)峤涣瞬灰却a寫完了再申請否則你只能干等著審核結(jié)果白白浪費(fèi)時間。注意簽名和模板的命名是有規(guī)范的個人開發(fā)者可選的簽名類型通常只有APP應(yīng)用和公眾號/小程序企業(yè)用戶可以有公司全稱/簡稱等更多類型。模板內(nèi)容不要出現(xiàn)營銷敏感詞比如加微信點擊鏈接領(lǐng)取紅包這類否則大概率被駁回。2. 工程地基Spring Boot項目如何把短信配置做成一個干凈的后端模塊服務(wù)商定了、簽名模板審核通過了接下來才是正式寫代碼。這里我建議從第一步就考慮好工程結(jié)構(gòu)不要直接把發(fā)送邏輯散落在Controller里。原因很簡單短信功能涉及配置管理、參數(shù)校驗、調(diào)用服務(wù)商、結(jié)果處理、日志記錄、重試策略多個環(huán)節(jié)任何一環(huán)寫腫了后續(xù)維護(hù)都很難受。2.1 Maven依賴怎么加新舊版SDK到底選哪個阿里云短信的Java SDK目前有兩個路線。老一代的是aliyun-java-sdk-core加aliyun-java-sdk-dysmsapi代碼寫起來比較繞需要手動組裝Request對象很多老項目里能看到它。新一代的是com.aliyun:dysmsapi20170525基于tea-openapi框架構(gòu)建用起來明顯更順手參數(shù)鏈?zhǔn)劫x值日志也更清晰。我建議新項目直接上新版SDK別因為網(wǎng)上老教程多用舊版就跟著踩坑。dependency groupIdcom.aliyun/groupId artifactIddysmsapi20170525/artifactId version2.0.24/version /dependency這個版本號不一定是當(dāng)前最新的你可以在Maven中央倉庫確認(rèn)一下。需要注意一個點新版SDK傳遞依賴了com.aliyun:tea-openapi和com.aliyun:tea如果你的項目里已有老舊的阿里云SDK版本可能產(chǎn)生類沖突。解決辦法是統(tǒng)一升級到該SDK依賴的最新版本或者排除掉沖突傳遞依賴。2.2 配置文件里到底該放什么不該放什么短信配置的核心是AccessKey ID和AccessKey Secret這兩個東西幾乎等價于你賬號的鑰匙。密鑰一旦泄露別人就能拿你的賬號發(fā)短信導(dǎo)致的直接后果是余額被刷光更嚴(yán)重的是簽名和模板可能被標(biāo)記為惡意從而被服務(wù)商封禁。我見過不少項目把AccessKey Secret直接明文寫在application.yml里還給提交到Git倉庫。這是非常危險的習(xí)慣。即使只是內(nèi)網(wǎng)項目也不建議這么做?，F(xiàn)在阿里云控制臺里可以直接創(chuàng)建子用戶AccessKey并限制其權(quán)限只能調(diào)用短信服務(wù)。生產(chǎn)環(huán)境更建議配合配置中心比如Nacos或Apollo把明文密鑰放在配置中心并做權(quán)限控制本地application.yml只保留開發(fā)環(huán)境的測試密鑰。spring: application: name: sms-service aliyun: sms: # 生產(chǎn)和測試環(huán)境使用不同的key通過profile切換 access-key-id: ${SMS_ACCESS_KEY_ID} access-key-secret: ${SMS_ACCESS_KEY_SECRET} sign-name: 某某科技 template-code: SMS_123456789 endpoint: dysmsapi.aliyuncs.com我習(xí)慣把AccessKey等敏感配置通過環(huán)境變量的方式注入這個做法在Docker部署和Kubernetes部署時尤其方便。你只需要在運(yùn)行環(huán)境中設(shè)置好環(huán)境變量代碼里用${SMS_ACCESS_KEY_ID}占位Spring Boot會自動完成替換。2.3 配置綁定和客戶端封裝要讓調(diào)用方無感知配置綁定我一般會建一個SmsProperties類用ConfigurationProperties自動綁定配置項。這樣做的好處是后續(xù)無論是切換服務(wù)商還是增加簽名和模板的映射關(guān)系只需改動配置和這一個類業(yè)務(wù)代碼完全不受影響。Component ConfigurationProperties(prefix aliyun.sms) Data public class SmsProperties { private String accessKeyId; private String accessKeySecret; private String signName; private String templateCode; private String endpoint; }然后是客戶端初始化。新版SDK的初始化方式如下Configuration public class SmsClientConfig { Bean public com.aliyun.dysmsapi20170525.Client smsClient(SmsProperties properties) { com.aliyun.teaopenapi.models.Config config new com.aliyun.teaopenapi.models.Config() .setAccessKeyId(properties.getAccessKeyId()) .setAccessKeySecret(properties.getAccessKeySecret()); config.endpoint properties.getEndpoint(); try { return new com.aliyun.dysmsapi20170525.Client(config); } catch (Exception e) { throw new RuntimeException(初始化短信客戶端失敗, e); } } }這里有一個經(jīng)驗Client是線程安全的可以全局復(fù)用不要每次發(fā)送都new一個。如果你參照網(wǎng)上某些教程把Client放在方法里創(chuàng)建在高并發(fā)場景下你會頻繁創(chuàng)建連接既浪費(fèi)資源又增加了超時概率。3. 核心發(fā)送邏輯這樣設(shè)計驗證碼場景的存儲、校驗與異步發(fā)送一步到位短信發(fā)送的代碼本身不難難的是把發(fā)送邏輯設(shè)計得扛得住線上真實壓力。這部分的重點不只是調(diào)通接口而是想清楚驗證碼怎么存、怎么校驗、重復(fù)發(fā)送怎么攔截、接口超時怎么辦。下面這三個小節(jié)是我做短信功能時沉淀下來的核心設(shè)計。3.1 發(fā)送短信的主流程代碼這樣寫最不容易出問題一條短信的發(fā)送邏輯從業(yè)務(wù)側(cè)看很簡單手機(jī)號、簽名、模板、模板參數(shù)四樣?xùn)|西齊了就能調(diào)。但實際工程里我們還要在調(diào)用服務(wù)商之前做好參數(shù)校驗避免把亂七八糟的數(shù)據(jù)傳給第三方。Service public class SmsServiceImpl implements SmsService { Resource private Client smsClient; Resource private SmsProperties smsProperties; Resource private StringRedisTemplate redisTemplate; Override public void sendSmsCode(String phone) { // 1. 參數(shù)合法性校驗手機(jī)號格式不對直接拒絕 if (!PhoneValidator.isValid(phone)) { throw new BizException(手機(jī)號格式不正確); } // 2. 防刷校驗同一手機(jī)號60秒內(nèi)只能發(fā)一次 String sendFlagKey sms:send:count: phone; Boolean absent redisTemplate.opsForValue() .setIfAbsent(sendFlagKey, 1, Duration.ofSeconds(60)); if (Boolean.FALSE.equals(absent)) { throw new BizException(發(fā)送過于頻繁請稍后再試); } // 3. 生成6位隨機(jī)驗證碼 String code String.valueOf(ThreadLocalRandom.current().nextInt(100000, 999999)); // 4. 驗證碼先入庫這里用Redis設(shè)置5分鐘有效 redisTemplate.opsForValue() .set(buildCodeKey(phone), code, Duration.ofMinutes(5)); // 5. 異步調(diào)用服務(wù)商發(fā)送 asyncSendSms(phone, code); } Async(smsExecutor) protected void asyncSendSms(String phone, String code) { try { com.aliyun.dysmsapi20170525.models.SendSmsRequest request new com.aliyun.dysmsapi20170525.models.SendSmsRequest() .setPhoneNumbers(phone) .setSignName(smsProperties.getSignName()) .setTemplateCode(smsProperties.getTemplateCode()) .setTemplateParam({\code\:\ code \}); com.aliyun.dysmsapi20170525.models.SendSmsResponse response smsClient.sendSms(request); if (!OK.equals(response.getBody().getCode())) { log.error(短信發(fā)送失敗, phone:{}, code:{}, resp:{}, phone, code, response.getBody()); } } catch (Exception e) { log.error(短信發(fā)送異常, phone:{}, phone, e); } } }簡單解釋一下setIfAbsent是Redis的原子操作當(dāng)key不存在時才會寫入利用它可以直接實現(xiàn)60秒內(nèi)不能重復(fù)發(fā)送的防刷邏輯。驗證碼先寫入Redis再異步發(fā)送是因為用戶體驗優(yōu)先——接口要快速返回不能卡在第三方網(wǎng)絡(luò)請求上。至于異步發(fā)送失敗怎么辦下一節(jié)細(xì)說。3.2 驗證碼的存儲與校驗正是體現(xiàn)后端功力的時候短信驗證碼最常見的場景是用戶注冊或登錄時的校驗。它的核心訴求有三個驗證碼不能明文存數(shù)據(jù)庫、必須有過期時間、校驗時要能防止暴力嘗試。用Redis存驗證碼是目前最主流的做法。我把驗證碼的key設(shè)計成sms:code:{phone}value直接存6位數(shù)字。校驗的時候取出Redis里的值和用戶提交的驗證碼比較相等則校驗通過并立即刪除一次性使用不相等則記錄失敗次數(shù)超過5次就刪除驗證碼要求用戶重新獲取。Override public boolean verifySmsCode(String phone, String code) { String key buildCodeKey(phone); String cachedCode redisTemplate.opsForValue().get(key); if (cachedCode null) { throw new BizException(驗證碼已過期請重新獲取); } // 校驗失敗次數(shù)防止暴力破解 String failKey key :fail; Long failCount redisTemplate.opsForValue().increment(failKey); if (failCount ! null failCount 5) { redisTemplate.delete(key); redisTemplate.delete(failKey); throw new BizException(嘗試次數(shù)過多請重新獲取驗證碼); } if (cachedCode.equals(code)) { redisTemplate.delete(key); redisTemplate.delete(failKey); return true; } redisTemplate.expire(failKey, Duration.ofMinutes(5)); throw new BizException(驗證碼錯誤); }這里有個容易被忽視的細(xì)節(jié)驗證碼是敏感信息不管在日志還是數(shù)據(jù)庫里都不能以明文形式整體出現(xiàn)。非要記錄日志建議只打印后四位或者做脫敏處理。因為驗證碼短信一旦被中間人截獲或日志泄露攻擊者可以直接用來重置密碼、登錄賬號。3.3 異步發(fā)送和重試機(jī)制是短信接口穩(wěn)定性的關(guān)鍵保障短信發(fā)送依賴第三方服務(wù)商的網(wǎng)絡(luò)大概率會出現(xiàn)偶發(fā)性超時或失敗。如果發(fā)送邏輯寫成同步用戶請求就會一直轉(zhuǎn)圈如果失敗后不做任何處理用戶就永遠(yuǎn)收不到驗證碼只能重新觸發(fā)發(fā)送。這兩者都是糟糕體驗。我的方案是使用Spring的Async注解配合自定義線程池將短信發(fā)送從主線程中剝離。實際項目中我通常單獨(dú)定義一個SmsExecutorConfigConfiguration public class SmsExecutorConfig { Bean(smsExecutor) public ThreadPoolTaskExecutor smsExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(4); executor.setMaxPoolSize(8); executor.setQueueCapacity(200); executor.setThreadNamePrefix(sms-exec-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }為什么用CallerRunsPolicy而不是直接丟棄因為當(dāng)任務(wù)隊列滿了說明系統(tǒng)短時間內(nèi)的短信請求量已經(jīng)很大這時候用調(diào)用者線程執(zhí)行相當(dāng)于天然限流避免任務(wù)靜默丟失。同時我在異步發(fā)送方法內(nèi)重試兩次第一次間隔2秒第二次間隔4秒。如果兩次重試都失敗就打WARN級別日志并標(biāo)記一條失敗記錄后續(xù)通過定時任務(wù)補(bǔ)償。這里要額外注意Async生效的前提是調(diào)用方和被調(diào)用方不能是同一個類內(nèi)部調(diào)用且必須是Spring Bean。所以我把a(bǔ)syncSendSms設(shè)計成了protected方法從sendSmsCode里跨類調(diào)用如果是同一個ServiceImpl內(nèi)部調(diào)用會出現(xiàn)自調(diào)用不代理的問題異步注解失效。初次接觸Spring異步的朋友經(jīng)常在這里踩坑以為注解寫上就行結(jié)果發(fā)現(xiàn)還是同步執(zhí)行就是這個原因。4. 跑通本地聯(lián)調(diào)和回調(diào)接收如何讓短信真正發(fā)出去并拿到狀態(tài)報告代碼寫完了怎么驗證邏輯對不對最直接的方式就是寫一個測試Controller傳入真實手機(jī)號看短信能不能收到。但這一階段有些細(xì)節(jié)值得說一說因為很多人卡在本地調(diào)不通回調(diào)接不到這類問題上。4.1 本地測試環(huán)境如何配置避免誤發(fā)線上短信短信是花錢的服務(wù)本地開發(fā)聯(lián)調(diào)時如果每次都用真實手機(jī)號發(fā)送一天下來費(fèi)用也夠點幾頓外賣了。阿里云控制臺提供了測試專用簽名和測試模板申請通過后測試模板有固定的格式比如您的驗證碼為${code}您正在使用測試模板發(fā)送短信。用測試模板發(fā)短信不會真正觸達(dá)用戶手機(jī)號碼而是在控制臺的短信記錄中看到發(fā)送詳情。如果你確實需要在自己手機(jī)上收到真實短信那就必須用已審核通過的正式簽名和模板。建議把測試手機(jī)號放到配置里只在開發(fā)環(huán)境使用比如# application-dev.yml aliyun: sms: test-phone: 13800000000Controller接口里可以加一個邏輯當(dāng)spring.profiles.activedev且手機(jī)號不在白名單中時直接返回開發(fā)環(huán)境僅允許測試號碼發(fā)送。這樣能防止聯(lián)調(diào)時誤把測試數(shù)據(jù)發(fā)到真實用戶手機(jī)里。4.2 回調(diào)接口的正確接入姿勢短信服務(wù)商會異步推送短信的狀態(tài)報告比如已發(fā)送已到達(dá)發(fā)送失敗用戶拒收等。這個回調(diào)是HTTP POST請求服務(wù)商把狀態(tài)數(shù)據(jù)以JSON格式POST到你提供的回調(diào)地址上?；卣{(diào)接口本質(zhì)上是接收第三方數(shù)據(jù)的入口寫起來不復(fù)雜但有幾個安全性和業(yè)務(wù)性的問題必須處理。RestController RequestMapping(/sms/callback) public class SmsCallbackController { PostMapping(/status) public MapString, Object receiveStatus(RequestBody MapString, Object body) { log.info(收到短信狀態(tài)回調(diào): {}, body); // 解析手機(jī)號、消息ID、狀態(tài)碼、狀態(tài)描述 String phone String.valueOf(body.get(phone_number)); String messageId String.valueOf(body.get(out_id)); String status String.valueOf(body.get(report_status)); String description String.valueOf(body.get(err_msg)); // 更新本地數(shù)據(jù)庫中的發(fā)送記錄表 smsReportService.updateReport(messageId, status, description); // 返回success告訴服務(wù)商消息已收到否則服務(wù)商以為你沒收到會重復(fù)推送 return Map.of(code, 0, msg, success); } }回調(diào)處理的關(guān)鍵點有兩個一是必須給服務(wù)商返回明確的成功響應(yīng)否則它們會按自己的重試策略重復(fù)推送二是要做冪等處理因為消息可能推多次你的業(yè)務(wù)表要通過messageId或out_id做唯一約束重復(fù)接收時只更新不重復(fù)寫入。另外回調(diào)接口沒有用戶身份信息的只要URL被猜到任何人都可以往你接口上POST假數(shù)據(jù)。所以生產(chǎn)環(huán)境的回調(diào)地址建議加一個請求頭校驗或簽名校驗。阿里云的回調(diào)支持配置Token接收到請求時校驗Header中的Token是否匹配這一步一定不要省。我的做法是自己封裝了一個SmsCallbackAuthFilter對所有/sms/callback/*的請求統(tǒng)一校驗Token。提醒回調(diào)地址必須是公網(wǎng)可訪問的HTTPS地址。本地調(diào)試時可以利用內(nèi)網(wǎng)穿透工具把回調(diào)地地址臨時暴露到公網(wǎng)但在生產(chǎn)環(huán)境千萬不要圖方便繼續(xù)用這類工具直接配置公網(wǎng)域名加HTTPS才是正解。4.3 手機(jī)號加密傳輸與合規(guī)存儲短信接口對接的過程中手機(jī)號屬于用戶敏感信息。雖然這不是本篇重點但我強(qiáng)烈建議你在設(shè)計短信服務(wù)模塊時就考慮合規(guī)問題。前后端交互時手機(jī)號字段最好用加密傳輸比如AES或國密SM4服務(wù)端落庫時做脫敏處理。日志打印時手機(jī)號只保留前三位和后四位。這個習(xí)慣越早養(yǎng)成越好等日后被合規(guī)審計要求整改的時候再來逐個字段checkout成本就高了。5. 生產(chǎn)環(huán)境不能回避的問題限流、冪等、監(jiān)控和成本控制測試通過了代碼上線了短信功能看起來已經(jīng)跑起來了。但真實生產(chǎn)環(huán)境比測試環(huán)境復(fù)雜得多短信接口有幾個問題如果不在上線前處理遲早會變成線上事故。這章我逐個說。5.1 限流不只是防刷更是保護(hù)自己短信接口天然是攻擊者的目標(biāo)——只要能無限調(diào)用你的發(fā)送接口對方就能用你的短信通道轟炸任意手機(jī)號碼既刷你的余額也損害你域名的信譽(yù)。更可怕的是如果你的發(fā)送接口業(yè)務(wù)邏輯里還帶著用戶查詢或創(chuàng)建操作攻擊者甚至可以利用它做批量探測。所以網(wǎng)關(guān)層限流是必須的。如果你用Spring Cloud Gateway或Nginx可以直接對/sms/send這類路徑做QPS限制。如果是單機(jī)應(yīng)用也可以用Guava的RateLimiter或RedisLua實現(xiàn)分布式限流。我的實踐是兩層限流第一層是接口級QPS限制比如單機(jī)每秒最多200個請求超出直接拒絕第二層是業(yè)務(wù)級限制即每個手機(jī)號每天最多發(fā)10條驗證碼每個IP每分鐘最多發(fā)5條。// 每天上限限制 String dailyKey sms:daily:limit: phone; Long count redisTemplate.opsForValue().increment(dailyKey); if (count ! null count 1) { redisTemplate.expire(dailyKey, Duration.ofDays(1)); } if (count 10) { throw new BizException(今日短信發(fā)送已達(dá)上限); }這個限流邏輯本身不會有太高性能消耗Redis的原子自增操作是常數(shù)復(fù)雜度。但要注意每次發(fā)送都做兩次Redis操作間隔限制和每日上限高峰期要觀察一下你Redis的QPS增長情況如果成為瓶頸可以用本地緩存CaffeineRedis兩級方式優(yōu)化。5.2 發(fā)送記錄的持久化別等查不到日志才后悔短信發(fā)送記錄必須落庫。我維護(hù)過多個短信模塊最深的感觸是沒有發(fā)送記錄表出現(xiàn)問題排查的成本會高到讓人抓狂。用戶投訴說沒收到短信服務(wù)商說已經(jīng)發(fā)出去了如果兩邊各執(zhí)一詞你手里沒有證據(jù)鏈根本無法定位問題。CREATE TABLE sms_send_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, phone VARCHAR(20) NOT NULL COMMENT 接收手機(jī)號, template_code VARCHAR(64) NOT NULL COMMENT 模板ID, template_param VARCHAR(500) COMMENT 模板參數(shù)JSON, biz_id VARCHAR(64) COMMENT 服務(wù)商返回的消息ID, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-發(fā)送中 1-成功 2-失敗, err_code VARCHAR(64) COMMENT 錯誤碼, err_msg VARCHAR(255) COMMENT 錯誤描述, request_time DATETIME NOT NULL COMMENT 請求時間, report_time DATETIME COMMENT 回執(zhí)時間, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_phone_time (phone, request_time) ) COMMENT 短信發(fā)送記錄表;記錄表的意義包含但不限于第一核對服務(wù)商賬單時用它做總量核對第二排查用戶投訴時查它判斷短信真實狀態(tài)第三統(tǒng)計到達(dá)率、發(fā)送成功率評估不同服務(wù)商的通道質(zhì)量。我在對接初期就設(shè)計了這張表后來服務(wù)商對賬和問題排查都靠它。5.3 監(jiān)控指標(biāo)和異常告警短信模塊的監(jiān)控我建議重點關(guān)注四個指標(biāo)發(fā)送成功率、到達(dá)率、發(fā)送耗時、調(diào)用量。到達(dá)率依賴于回調(diào)的及時性如果你發(fā)現(xiàn)某個時段到達(dá)率低于正常值優(yōu)先懷疑服務(wù)商通道問題及時切換備用通道。發(fā)送耗時如果從200毫秒漲到2秒大概率是SDK連接池或網(wǎng)絡(luò)問題。我每次發(fā)布短信相關(guān)改動后都會盯著這四個指標(biāo)看半小時再離開。告警規(guī)則上成功率低于95%告警單日調(diào)用量環(huán)比上漲超過50%告警回執(zhí)超時超過10分鐘告警。告警通道可以用企業(yè)微信機(jī)器人或釘釘機(jī)器人把異常信息推送到群里這樣不用等用戶投訴就能第一時間感知。6. 回頭看這些坑我踩過希望你繞過最后分享幾個我在短信接口對接和線上運(yùn)維過程中踩過的坑每個都對應(yīng)一個真實的線上教訓(xùn)。第一模板參數(shù)必須嚴(yán)格按照模板定義傳。阿里云模板變量是通過JSON字符串傳遞的比如{code:123456}。如果你模板里定義的變量是${name}傳參時key就必須叫name大小寫都敏感。我有一次把變量名寫成Name結(jié)果發(fā)送報錯isv.SMS_TEMPLATE_ILLEGAL排查了半天才發(fā)現(xiàn)是大小寫問題。第二別把endpoint配錯了。新版SDK的endpoint應(yīng)該是dysmsapi.aliyuncs.com如果配成dysmsapi.aliyuncs.com.cn之類就會出現(xiàn)未知異常。這類配置項我一般直接抄官方文檔不要自己拼。第三Spring Boot項目如果同時引入了多個阿里云SDK要特別留意版本兼容問題。舊版aliyun-java-sdk-core和新版dysmsapi20170525共用部分類名可能引發(fā)奇怪的NoSuchMethodError。解決方式是盡可能將阿里云所有SDK統(tǒng)一到最新的兼容版本或者在引入時排除沖突的傳遞依賴。第四異步發(fā)送的重試要設(shè)置最大次數(shù)避免服務(wù)商不可用時無休止重試導(dǎo)致線程池被打滿。我遇到過一次短信服務(wù)商大面積故障重試任務(wù)堆積排滿了隊列直接導(dǎo)致整個應(yīng)用響應(yīng)變慢。后來我加了熔斷邏輯當(dāng)連續(xù)失敗超過20次時暫停短信發(fā)送并開啟降級開關(guān)故障恢復(fù)后自動放開。根據(jù)我個人的實際操作經(jīng)驗短信接口對接這件事本身不難真正拉開差距的是對異常鏈路、數(shù)據(jù)閉環(huán)和成本控制的處理。你把這篇文章里的設(shè)計思路落地到項目里基本就能避免我踩過的那些坑。如果你正在做Spring Boot集成短信功能的方案設(shè)計希望這篇內(nèi)容能幫你把方案做得更完整。