企业官网建设流程全解析

1. 项目概述：为什么“超简单”三个字值得深挖

“SpringBoot项目集成短信验证码（超简单）”——这个标题在开发者社区里出现频率极高，但真正能让人拍着大腿说“确实超简单”的案例却少之又少。我带过不少刚从校招进来的新人，在接到“加个短信登录”需求时，第一反应不是查文档，而是翻群聊、搜GitHub、问前辈：“有没有现成能跑的demo？”结果往往下载下来一跑就报错：依赖冲突、配置项漏填、签名模板审核不通过、测试环境发不出去、生产环境被限频……最后发现，“超简单”背后藏着至少5类隐性门槛：通信资质合规性、运营商通道适配逻辑、验证码生命周期管理、防刷策略落地细节、以及最关键的——SpringBoot生态下的轻量级集成范式。

这根本不是“引入一个starter、配几个yml参数”就能闭环的事。它横跨了应用层、中间件层、通信服务层和监管合规层。所谓“超简单”，其实是把大量底层复杂度封装掉，只暴露3~4个核心决策点给开发者：用哪家服务商？怎么设计验证码缓存结构？如何与Spring Security联动？失败时要不要降级为图形验证码？这些选择没有标准答案，但每个都直接影响上线后的稳定性、用户体验和运维成本。

我去年在某高校实验室协助搭建一套面向师生的轻量级选课系统时，就踩过完整闭环的坑。当时团队想快速上线手机号绑定功能，选了某云厂商的短信服务，结果在压测阶段发现：单机QPS超过80后，验证码发送延迟从200ms飙升到3s以上，且偶发重复发送；更麻烦的是，当用户连续点击“重新获取”，后台没做请求合并，导致同一号码1分钟内触发了17次调用，直接被服务商熔断。后来我们重构时，把整个流程拆成了“预校验→令牌生成→异步投递→状态回写→前端倒计时同步”五个原子环节，每个环节都加了可观测埋点，才真正实现“业务无感、用户无感、运维可控”。所以这篇内容不讲API怎么调，也不堆砌SDK文档，而是聚焦一个真实问题：在SpringBoot工程中，如何用最少的侵入、最稳的结构、最易维护的方式，把短信验证码这件事“做对”，而不是“做完”。

关键词“SpringBoot”“短信验证码”“超简单”不是营销话术，而是三个强约束条件：必须基于SpringBoot的自动装配机制、必须满足短信服务的强时效与高可用要求、所有实现必须控制在3个Java类+1份配置以内——这才是“超简单”的真实定义。

2. 整体设计思路：避开三大典型架构陷阱

很多开发者一上来就直奔“调用SDK发短信”这个动作，结果越写越重，最后变成一个独立微服务。这不是集成，是造轮子。真正的轻量级集成，核心在于分层解耦+职责收敛+失败兜底。我见过太多项目把短信逻辑散落在Controller、Service、甚至DTO里，导致改个签名模板都要全局搜索，加个限流策略得动七八个类。下面这三种常见设计，看似省事，实则埋雷最深：

2.1 陷阱一：Controller层硬编码调用（最危险）

@RestController public class AuthController { @PostMapping("/send-code") public Result sendCode(@RequestParam String phone) { // ❌ 直接new SDK客户端，没走Spring容器管理 SmsClient client = new SmsClient("ak", "sk"); // ❌ 硬编码模板ID、签名，无法配置化 client.send("SMS_12345678", "阿里云", phone, Map.of("code", "123456")); return Result.success(); } }

为什么危险？

• 客户端未复用连接池，高并发下创建大量HTTP连接，耗尽系统资源；
• AK/SK明文写死，代码提交即泄露密钥；
• 模板ID和签名写死，换服务商要改代码，违反开闭原则；
• 完全没考虑网络超时、重试、降级，一次运营商抖动就导致整个接口雪崩。

提示：SpringBoot的@ConfigurationProperties不是摆设，所有外部依赖参数必须通过配置中心或yml注入，这是安全底线。

2.2 陷阱二：Service层大杂烩（最难维护）

@Service public class SmsService { // ❌ 把缓存、风控、日志、调用全塞在一个类里 public void sendCode(String phone) { // 1. 校验手机号格式 // 2. 查询Redis看是否已发送（没加分布式锁！） // 3. 调用短信SDK // 4. 写入Redis（没设过期时间！） // 5. 记录操作日志（没异步！） // 6. 发送企业微信告警（没熔断！） } }

为什么难维护？

• 单个方法承担6种职责，修改任一逻辑都需回归测试全部路径；
• Redis操作没加锁，高并发下同一号码可能被多次发送；
• 缓存没设TTL，用户换号后旧验证码长期残留；
• 日志同步写入，高峰期拖慢主流程；
• 告警无熔断，短信失败时疯狂刷告警消息。

注意：一个合格的SmsService，只该做一件事——协调下游组件完成“发送”动作。校验归Validator，缓存归CacheManager，风控归RateLimiter，日志归AOP切面。

2.3 陷阱三：过度抽象成通用平台（最不划算）

有些团队会建一个“短信中台”，提供REST API供所有业务方调用，还搞了模板管理后台、发送记录查询、失败重试队列……结果投入3人月开发，上线后发现90%的业务只需要发6种固定模板（登录、注册、修改密码、绑定手机、支付确认、找回账号），其余功能纯属闲置。

为什么不划算？

• 中台需要独立部署、监控、扩缩容，运维成本远超业务价值；
• 模板审核流程长，业务方提个新模板要等2天；
• 所有调用走HTTP，比直连SDK多一层网络开销和故障点；
• 权限管控复杂，一个业务方出问题可能影响全局。

我的方案：用“三层洋葱模型”替代上述陷阱

• 最外层（接入层）：SmsController，只做参数校验、请求限流、响应包装，不碰业务逻辑；
• 中间层（协调层）：SmsCoordinator，聚合SmsSender、CodeCache、RateLimiter三个组件，定义“发送验证码”的完整工作流；
• 最内层（能力层）：三个独立Bean，各司其职，可单独替换、压测、Mock。

这种结构下，更换短信服务商只需重写SmsSender实现类；调整缓存策略只需改CodeCache；增加风控规则只需增强RateLimiter。所有变更互不影响，这才是真正的“超简单”——简单在可维护性，不在代码行数。

3. 核心细节解析：从5个关键决策点讲透“轻量级”

“超简单”的本质，是把复杂问题拆解为有限个可决策、可验证、可替换的原子点。我在实际项目中反复验证，只要把以下5个点做对，90%的短信集成需求都能在2小时内完成基础版。

3.1 决策点一：服务商选型——不是越便宜越好，而是越“省心”越好

市面上主流短信服务商有三类：

• 云厂商原生服务（如阿里云短信、腾讯云短信）：优势是控制台完善、文档齐全、与自家云产品深度集成；劣势是价格偏高，小企业套餐起步价高；
• 聚合通道商（如容联云、亿美软通）：优势是价格低、支持多通道自动切换、提供语音验证码；劣势是二次封装导致问题定位难，部分通道质量不稳定；
• 自建通道（对接三大运营商网关）：优势是成本最低、完全可控；劣势是需申请SP资质、技术门槛高、运维复杂，个人或小团队基本不现实。

我的实测结论（基于近2年12个项目数据）：

关键建议：

• 初期选阿里云或腾讯云，省去资质审核和通道调试时间；
• 当月发送量稳定超50万条时，再评估聚合商；
• 绝对不要选“免审模板”的小厂商——它们往往用黑产号码池，首次发送可能成功，但后续会被运营商拉黑，导致整批用户收不到。

实操心得：在阿里云控制台创建模板时，务必勾选“仅用于登录/注册场景”，否则审核周期从1小时拉长到3个工作日。我曾因漏勾这一项，让一个紧急上线项目卡在最后一步。

3.2 决策点二：验证码缓存——Redis不是万能解药，结构设计决定成败

很多人以为“验证码存Redis就完事了”，结果线上出问题才发现：

• 用手机号作key，没加前缀，导致不同业务的验证码互相覆盖；
• 没设过期时间，Redis内存爆满；
• 用String类型存纯数字验证码，没加业务标识，无法区分是登录码还是支付码；
• 没做空值缓存，攻击者用不存在号码暴力探测，打穿数据库。

我采用的缓存结构（经压测验证）：

KEY: sms:login:{phone} # 业务类型+手机号，避免冲突 VALUE: {"code":"837291","ts":1712345678,"biz":"login"} # JSON字符串，含时间戳和业务标识 EXPIRE: 5 minutes # 固定5分钟，不随业务变

为什么这样设计？

• sms:login:{phone}前缀明确隔离业务域，后续加“支付验证码”只需改前缀为sms:pay:{phone}；
• JSON结构存储，方便扩展字段（如后续加“发送渠道”“IP地址”）；
• 时间戳ts存毫秒值，校验时可精确到秒级，避免时钟漂移导致误判；
• 固定5分钟TTL，比业务要求的“5分钟有效”多留30秒缓冲，防止Redis时钟误差。

避坑技巧：

• 不要用SETNX+EXPIRE两步命令，存在竞态条件；必须用SET key value EX 300 NX原子操作；
• 对于高频请求，加一层本地缓存（Caffeine），拦截95%的重复查询，减轻Redis压力；
• 生产环境Redis必须开启maxmemory-policy volatile-lru，防止OOM。

3.3 决策点三：防刷策略——限流不是目的，精准识别才是核心

单纯用@RateLimiter注解限制“每分钟最多5次”，会误伤正常用户：比如用户输错手机号，连续点5次“重新获取”，第6次就卡住。真正的防刷，要分三层：

我的轻量级实现（仅需20行代码）：

@Component public class SmsRateLimiter { private final RedisTemplate<String, Object> redisTemplate; public boolean tryAcquire(String phone) { String key = "sms:cnt:" + phone; // 用INCR命令原子计数，1分钟窗口 Long count = redisTemplate.opsForValue().increment(key, 1); if (count == 1) { redisTemplate.expire(key, Duration.ofMinutes(1)); } return count <= 3; // 同一号码1分钟最多3次 } }

为什么是3次不是5次？

• 用户正常场景：输错1次→重试1次→成功，共2次；
• 留1次余量应对网络抖动；
• 超过3次即触发“图形验证码+短信双因素”，体验损失最小。

注意：Redis计数器必须配合expire使用，否则key永久存在。我曾在线上环境发现一个未设过期的计数器，累积了27万次调用，导致Redis内存告警。

3.4 决策点四：异步化设计——不是所有操作都该异步，但发送必须异步

同步调用短信API的最大风险：主线程阻塞。一次网络超时（默认3秒）会让整个HTTP请求挂起，用户看到白屏。而短信发送本身是“尽力而为”操作，失败不影响核心业务（如用户注册流程可先存库，再异步补发验证码）。

我的异步方案（零依赖、零配置）：

@Service public class AsyncSmsSender { // 使用Spring内置线程池，不额外引入MQ @Async public void sendAsync(String phone, String code) { try { smsProvider.send(phone, code); // 真实SDK调用 } catch (Exception e) { log.error("短信发送失败，phone={}", phone, e); // 失败时写入本地失败队列，由定时任务重试 failedQueue.offer(new FailedSms(phone, code, LocalDateTime.now())); } } }

关键配置（application.yml）：

spring: task: execution: pool: core-size: 5 # 核心线程数 max-size: 20 # 最大线程数 queue-capacity: 100 # 队列容量，超限直接拒绝

为什么不用RabbitMQ/Kafka？

• 小项目引入MQ增加部署复杂度，运维成本远超收益；
• 短信失败率通常<0.5%，用内存队列+定时重试足够可靠；
• Spring@Async线程池可监控（通过Actuator端点），比MQ更轻量。

3.5 决策点五：错误处理与降级——预案比代码更重要

短信服务不可用时，系统不能直接报错。必须有明确的降级路径：

• 一级降级：返回“短信发送中，请稍候”，前端启动倒计时，不提示失败；
• 二级降级：连续3次发送失败，自动切换至图形验证码；
• 三级降级：所有通道不可用时，启用离线模式——生成6位随机码，通过邮件发送（需提前配置SMTP）。

我的降级开关设计（YAML配置驱动）：

sms: enabled: true # 总开关 fallback: captcha-enabled: true # 是否启用图形验证码降级 email-enabled: false # 是否启用邮件降级 timeout-millis: 2000 # SDK超时时间

实操验证：
我故意将阿里云AK写错，触发降级逻辑，实测：

• 前端无感知，倒计时正常启动；
• 日志清晰记录“短信服务不可用，启用图形验证码”；
• 用户输入图形码后，系统自动跳过短信校验，进入下一步。

提示：降级开关必须可动态刷新（用@RefreshScope或Nacos配置中心），不能重启生效。线上出问题时，运维同学30秒内就能切回备用通道。

4. 实操过程：手把手实现一个可运行的Demo

现在我们把前面所有决策点落地为可运行代码。整个实现控制在3个Java类+1份配置，符合“超简单”定义。项目基于SpringBoot 2.7.18（兼容JDK8），无需额外依赖，仅需添加spring-boot-starter-data-redis和短信SDK。

4.1 步骤一：添加必要依赖（pom.xml）

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-aop</artifactId> </dependency> <!-- 阿里云短信SDK --> <dependency> <groupId>com.aliyun</groupId> <artifactId>aliyun-java-sdk-dysmsapi</artifactId> <version>2.1.0</version> </dependency> <dependency> <groupId>com.aliyun</groupId> <artifactId>aliyun-java-sdk-core</artifactId> <version>4.5.0</version> </dependency> </dependencies>

为什么选这个版本？

• aliyun-java-sdk-dysmsapi 2.1.0是最后一个支持JDK8的稳定版；
• aliyun-java-sdk-core 4.5.0与前者完全兼容，避免ClassNotFound；
• 不引入spring-boot-starter-validation等非必要依赖，保持轻量。

4.2 步骤二：配置文件（application.yml）

spring: redis: host: 127.0.0.1 port: 6379 database: 0 lettuce: pool: max-active: 20 max-idle: 10 min-idle: 0 task: execution: pool: core-size: 3 max-size: 10 queue-capacity: 50 # 短信服务配置 sms: enabled: true provider: aliyun aliyun: access-key-id: ${ALIYUN_ACCESS_KEY_ID:your_ak} access-key-secret: ${ALIYUN_ACCESS_KEY_SECRET:your_sk} region-id: cn-hangzhou sign-name: "测试签名" template-code: "SMS_123456789" fallback: captcha-enabled: true email-enabled: false timeout-millis: 1500

安全实践：

• AK/SK通过环境变量注入（${ALIYUN_ACCESS_KEY_ID:your_ak}），本地开发用默认值，生产环境强制覆盖；
• sign-name和template-code必须与阿里云控制台完全一致，大小写敏感；
• timeout-millis设为1500ms，比默认3000ms更激进，避免线程长时间阻塞。

4.3 步骤三：核心代码实现（3个类）

4.3.1 短信发送器接口与实现

// SmsSender.java public interface SmsSender { boolean send(String phone, String code); } // AliyunSmsSender.java @Component @ConditionalOnProperty(name = "sms.provider", havingValue = "aliyun") @Slf4j public class AliyunSmsSender implements SmsSender { @Value("${sms.aliyun.access-key-id}") private String accessKeyId; @Value("${sms.aliyun.access-key-secret}") private String accessKeySecret; @Value("${sms.aliyun.region-id}") private String regionId; @Value("${sms.aliyun.sign-name}") private String signName; @Value("${sms.aliyun.template-code}") private String templateCode; private final DefaultProfile profile; private final IAcsClient client; public AliyunSmsSender() { this.profile = DefaultProfile.getProfile(regionId, accessKeyId, accessKeySecret); this.client = new DefaultAcsClient(profile); } @Override public boolean send(String phone, String code) { SendSmsRequest request = new SendSmsRequest(); request.setSysRegionId(regionId); request.setPhoneNumbers(phone); request.setSignName(signName); request.setTemplateCode(templateCode); request.setTemplateParam("{\"code\":\"" + code + "\"}"); try { SendSmsResponse response = client.getAcsResponse(request); if ("OK".equals(response.getCode())) { log.info("短信发送成功，phone={}", phone); return true; } else { log.warn("短信发送失败，phone={}, code={}, message={}", phone, response.getCode(), response.getMessage()); return false; } } catch (ServerException | ClientException e) { log.error("短信发送异常，phone={}", phone, e); return false; } } }

关键细节说明：

• @ConditionalOnProperty确保只有配置sms.provider=aliyun时才加载此Bean，方便后续扩展腾讯云、容联云实现；
• DefaultProfile和IAcsClient是阿里云SDK标准初始化方式，无需额外封装；
• 模板参数用{\"code\":\"" + code + "\"}拼接，不推荐用JSON库序列化——验证码是纯数字，无特殊字符，字符串拼接最高效；
• 成功时只打INFO日志，失败时打WARN，异常打ERROR，便于ELK日志分析。

4.3.2 验证码协调器（核心工作流）

// SmsCoordinator.java @Component @Slf4j public class SmsCoordinator { private final SmsSender smsSender; private final CodeCache codeCache; private final SmsRateLimiter rateLimiter; private final AsyncSmsSender asyncSmsSender; public SmsCoordinator(SmsSender smsSender, CodeCache codeCache, SmsRateLimiter rateLimiter, AsyncSmsSender asyncSmsSender) { this.smsSender = smsSender; this.codeCache = codeCache; this.rateLimiter = rateLimiter; this.asyncSmsSender = asyncSmsSender; } /** * 发送验证码主流程 * @return true表示已发起发送（无论成功与否），false表示被拦截 */ @Transactional(rollbackFor = Exception.class) public boolean sendCode(String phone) { // 1. 手机号格式校验（正则） if (!phone.matches("^1[3-9]\\d{9}$")) { log.warn("手机号格式不合法，phone={}", phone); return false; } // 2. 防刷校验 if (!rateLimiter.tryAcquire(phone)) { log.warn("触发防刷限制，phone={}", phone); return false; } // 3. 生成6位随机验证码 String code = RandomStringUtils.randomNumeric(6); // 4. 写入缓存（原子操作） boolean cacheSuccess = codeCache.set(phone, code); if (!cacheSuccess) { log.error("验证码缓存失败，phone={}", phone); return false; } // 5. 异步发送 asyncSmsSender.sendAsync(phone, code); log.info("验证码已异步发送，phone={}", phone); return true; } }

为什么用@Transactional？

• 缓存写入和数据库记录（如发送日志）需强一致性；
• 此处虽未操作DB，但预留扩展点，后续加日志表时无需改逻辑；
• rollbackFor = Exception.class确保所有异常都回滚，避免脏数据。

4.3.3 控制器与响应封装

// SmsController.java @RestController @RequestMapping("/api/sms") @Slf4j public class SmsController { private final SmsCoordinator smsCoordinator; public SmsController(SmsCoordinator smsCoordinator) { this.smsCoordinator = smsCoordinator; } @PostMapping("/send-code") public Result<?> sendCode(@RequestParam String phone) { long start = System.currentTimeMillis(); boolean success = smsCoordinator.sendCode(phone); long cost = System.currentTimeMillis() - start; if (success) { log.info("验证码发送请求处理成功，phone={}, cost={}ms", phone, cost); return Result.success(Map.of("countdown", 60)); // 前端倒计时60秒 } else { log.warn("验证码发送请求被拦截，phone={}, cost={}ms", phone, cost); return Result.fail("请求过于频繁，请稍后再试"); } } } // Result.java（统一响应体） public class Result<T> { private int code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.code = 200; result.message = "success"; result.data = data; return result; } public static <T> Result<T> fail(String message) { Result<T> result = new Result<>(); result.code = 400; result.message = message; return result; } }

前端友好设计：

• 响应体包含countdown字段，前端可直接启动倒计时，无需额外请求；
• 成功时返回200，失败时返回400，符合REST规范；
• Result类泛型化，后续扩展其他接口可复用。

4.4 步骤四：本地测试与验证

启动项目后，执行以下curl命令测试：

# 发送验证码 curl -X POST "http://localhost:8080/api/sms/send-code?phone=13800138000" # 预期响应 {"code":200,"message":"success","data":{"countdown":60}} # 查看Redis缓存（用redis-cli） 127.0.0.1:6379> GET sms:login:13800138000 "{\"code\":\"284739\",\"ts\":1712345678,\"biz\":\"login\"}"

测试要点检查清单：

• [ ] 连续请求同一号码3次，第4次返回400；
• [ ] 修改sms.fallback.captcha-enabled=true，手动触发短信失败，验证是否返回图形验证码；
• [ ] 将Redis停掉，观察日志是否报错，系统是否仍能返回“请求过于频繁”而非500；
• [ ] 用非法手机号（如123）测试，是否返回400且不写缓存。

5. 常见问题与排查技巧实录：来自12个项目的血泪总结

在交付这12个短信集成项目过程中，我整理出一份高频问题速查表。这些问题90%以上都源于配置疏忽或理解偏差，而非代码缺陷。下面按发生频率排序，附真实排查过程。

5.1 问题一：验证码发送成功，但用户收不到（发生率42%）

现象：
日志显示短信发送成功，phone=138****，但用户手机无任何短信。

排查路径：

1. 查阿里云控制台“发送记录”：发现状态为“发送成功”，但“运营商返回码”为空；
2. 查“短信签名”状态：显示“审核中”，但实际已过期（签名有效期3个月）；
3. 查“模板”状态：模板审核通过，但sign-name配置值与控制台不一致（控制台是“XX科技”，配置写成“XX科技有限公司”）。

根因：
阿里云对签名和模板的匹配极其严格，必须完全一致，包括空格、标点、括号。我曾因模板里写了“（测试）”，而配置里是“（测试）”，后者用了全角括号，导致全部失败。

解决方案：

• 在控制台复制签名和模板ID，粘贴后用Notepad++查看不可见字符；
• 在AliyunSmsSender构造函数中加校验：

  @PostConstruct public void validateConfig() { Assert.hasText(signName, "短信签名不能为空"); Assert.hasText(templateCode, "模板CODE不能为空"); log.info("短信配置校验通过，signName={}, templateCode={}", signName, templateCode); }

5.2 问题二：Redis缓存写入失败，但日志无报错（发生率28%）

现象：
codeCache.set()返回false，但控制台无任何ERROR日志。

排查路径：

1. 查Redis连接：redis-cli -h 127.0.0.1 -p 6379 ping返回PONG，连接正常；
2. 查Redis内存：redis-cli info memory | grep used_memory_human显示used_memory_human:1.2G，而maxmemory为1G；
3. 查淘汰策略：redis-cli config get maxmemory-policy返回noeviction。

根因：
Redis内存满且淘汰策略为noeviction，所有写入命令返回(error) OOM command not allowed when used memory > 'maxmemory'，但Spring Data Redis默认吞掉这个异常，只返回false。

解决方案：

• 修改Redis配置：maxmemory-policy allkeys-lru；
• 在CodeCache实现中捕获异常并打日志：

  try { redisTemplate.opsForValue().set(key, value, Duration.ofMinutes(5)); } catch (Exception e) { log.error("Redis写入失败，key={}", key, e); throw e; // 不吞异常 }

5.3 问题三：异步线程池耗尽，请求堆积（发生率15%）

现象：
压测时QPS到50，/send-code接口响应时间从200ms飙升到5s，且持续恶化。

排查路径：

1. 查线程池状态：通过Actuator端点/actuator/metrics/spring.task.execution.pool.active，发现active值恒为10（max-size）；
2. 查队列长度：/actuator/metrics/spring.task.execution.pool.queue显示queue值>1000；
3. 查日志：大量TaskExecutor rejected警告。

根因：
queue-capacity设为50，但压测QPS 50持续10秒，产生500个任务，全部积压在队列，新任务被拒绝。

解决方案：

• 调优参数：core-size=5,max-size=10,queue-capacity=20，宁可拒绝也不堆积；
• 加拒绝策略：自定义RejectedExecutionHandler，触发告警：

  @Bean public TaskExecutor taskExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setMaxPoolSize(10); executor.setQueueCapacity(20); executor.setRejectedExecutionHandler((r, e) -> { log.error("短信异步任务被拒绝，当前队列长度={}", e.getQueue().size()); // 发送企业微信告警 }); return executor; }

5.4 问题四：本地测试OK，上线后发送延迟高（发生率10%）

现象：
本地IDEA运行，发送延迟<200ms；部署到阿里云ECS后，延迟>2s。

排查路径：

1. 查网络：telnet dysmsapi.aliyuncs.com 443通，但curl -v https://dysmsapi.aliyuncs.com耗时1.8s；
2. 查DNS：nslookup dysmsapi.aliyuncs.com返回多个IP，其中一个是北京节点，ECS在杭州；
3. 查SDK日志：开启debug日志，发现每次请求都重定向到dysmsapi.cn-shanghai.aliyuncs.com。

根因：
阿里云SDK默认使用cn-hangzhou区域，但dysmsapi.aliyuncs.com是全局域名，DNS解析可能返回非最优节点。必须显式指定Endpoint。

解决方案：
在AliyunSmsSender中，不使用DefaultProfile.getProfile(regionId,...)，而用：

this.profile = DefaultProfile.getProfile( "cn-shanghai", // 必须与ECS同地域 accessKeyId, accessKeySecret ); DefaultProfile.addEndpoint("https://dysmsapi.cn-shanghai.aliyuncs.com", "cn-shanghai", "Dysmsapi", "dysmsapi.cn-shanghai.aliyuncs.com");

5.5 问题五：验证码校验时区不一致（发生率5%）

现象：
用户收到验证码后立即输入，提示“验证码已过期”。

排查路径：

1. 查缓存数据：GET sms:login:138****返回{"code":"123456","ts":1712345678}；
2. 查服务器时间：date显示`2024-04-05 10