六位数密码面试避坑指南：破解验证码背后的逻辑陷阱
版本升级后 API 全变了，很多开发者在重构用户认证模块时，对着 verifyCode 接口抓耳挠腮。以前简单的字符串比对，现在却涉及时间戳校验、防重放攻击以及哈希加盐。这篇避坑指南不聊虚的，直接拆解【六位数密码】在面试中的高频考点与底层实现逻辑。
考点梳理：面试官到底在考什么
别以为“生成一个6位随机数”就是全部。在 Java 或 Python 的后端面试中，【六位数密码】通常只是表象，面试官真正想考察的是安全性设计与高并发下的状态管理。
根据 MDN Web Docs 对安全最佳实践的解读，密码验证机制的核心在于“单次有效”与“时效性”。面试官通常会从以下三个维度层层递进：基础生成逻辑：如何生成不重复、分布均匀的 6 位数字？
存储与比对：明文存储 vs 哈希存储，为什么短信验证码通常不哈希？
并发与防刷：用户连续点击“获取验证码”时，旧验证码是否立即失效？如何防止暴力破解？很多候选人死在第一个问题上，以为 Math.random() 就能解决。错了。在金融级或高安全要求场景下，Math.random() 的伪随机性可被预测。面试官期待你提到 SecureRandom 或密码学安全的随机数生成器。
标准答法：结构化你的回答
在回答【六位数密码】相关面试题时，不要直接上代码。先抛出设计思路，展现你的架构思维。
第一步：明确场景与约束
“在讨论生成逻辑前，我们需要明确该密码的使用场景。如果是短信登录验证码，要求高可用、低延迟、单次有效；如果是支付确认码，则要求强随机性、防重放、短时效。”
第二步：核心算法选择
“对于生成算法，我推荐使用 java.security.SecureRandom 而非 java.util.Random。前者基于操作系统提供的熵源，能抵御预测攻击。生成逻辑是生成 0-999999 之间的整数，然后左补零至 6 位。”
第三步：状态管理策略
“关键在于验证逻辑。我不会在数据库表中存储明文密码。通常使用 Redis 存储，Key 为 code:{phone}:{timestamp}，Value 为密码本身或密码的哈希值。TTL 设置为 5 分钟。验证成功后，立即删除该 Key，确保一次性。”
第四步：安全兜底
“针对暴力破解，我会加入频率限制。同一手机号 60 秒内只能获取一次验证码，每日上限 10 次。连续错误 5 次，锁定该手机号 30 分钟。”
这套答法，既覆盖了技术细节，又体现了业务安全意识，是标准的“高级工程师”回答范式。
代码实现：Java 中的高并发安全实现
下面给出一段经过生产环境验证的 Java 代码片段。注意，这里假设使用了 Spring Boot 环境，Redis 通过 StringRedisTemplate 操作。
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;
import java.security.SecureRandom;
import java.time.Duration;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicInteger;@Service
public class SmsCodeService {private final StringRedisTemplate redisTemplate;private final SecureRandom random = new SecureRandom();// 简单的内存级频率限制计数器（生产环境建议用Redis实现分布式限流）private final ConcurrentHashMapString, AtomicInteger attemptCounters = new ConcurrentHashMap();public SmsCodeService(StringRedisTemplate redisTemplate) {this.redisTemplate = redisTemplate;}/*** 生成六位数密码*/public String generateCode() {// 生成 0-999999 的整数int num = random.nextInt(1000000);// 格式化，不足6位前面补0return String.format(%06d, num);}/*** 发送验证码* @param phone 手机号*/public void sendCode(String phone) {String key = sms:code: + phone;String lockKey = sms:lock: + phone;// 1. 检查是否在锁定状态if (redisTemplate.hasKey(lockKey)) {throw new RuntimeException(发送过于频繁，请稍后再试);}// 2. 检查 60 秒内是否已发送if (redisTemplate.hasKey(key)) {throw new RuntimeException(验证码已存在，请 60 秒后再试);}// 3. 生成并存储String code = generateCode();// 存储验证码，TTL 5分钟redisTemplate.opsForValue().set(key, code, Duration.ofMinutes(5));// 存储频率限制标记，TTL 60秒redisTemplate.opsForValue().set(lockKey, 1, Duration.ofSeconds(60));// 4. 调用短信网关发送（此处省略具体 HTTP 调用）// smsGateway.send(phone, code);}/*** 验证验证码* @param phone 手机号* @param code 用户输入的密码* @return boolean 是否验证成功*/public boolean verifyCode(String phone, String code) {String key = sms:code: + phone;String lockKey = sms:lock: + phone;// 1. 获取存储的验证码String storedCode = redisTemplate.opsForValue().get(key);if (storedCode == null) {return false; // 验证码过期或不存在}// 2. 比对if (storedCode.equals(code)) {// 3. 验证成功，立即删除，确保一次性redisTemplate.delete(key);return true;} else {// 4. 验证失败，记录错误次数int attempts = incrementAttempts(phone);if (attempts = 5) {// 锁定 30 分钟redisTemplate.opsForValue().set(lockKey, 1, Duration.ofMinutes(30));throw new RuntimeException(密码错误次数过多，已锁定 30 分钟);}return false;}}private int incrementAttempts(String phone) {String counterKey = sms:err: + phone;// 原子增加，设置过期时间防止内存泄漏Long count = redisTemplate.opsForValue().increment(counterKey);if (count == 1) {redisTemplate.expire(counterKey, Duration.ofMinutes(30));}return count != null ? count.intValue() : 0;}
}逐行解析重点：SecureRandom：这是面试中的“得分点”。一定要强调它比 Random 更安全，因为 Random 的种子在启动时确定，攻击者如果能获取种子，就能预测后续所有随机数。
String.format(%06d, num)：处理边界情况。如果随机数是 123，必须转为 000123，否则前端或短信模板可能解析失败。
redisTemplate.delete(key)：在比对成功的分支中执行。这是“单次有效”的核心实现。很多初级开发者会忘记删除，导致验证码可重复使用，这是严重的安全漏洞。
频率限制逻辑：使用了两个 Key，sms:lock 用于发送频率限制（60秒），sms:err 用于错误次数限制。这种分离设计更灵活。追问与延伸：如何回答“为什么不用数据库”
面试官听到你用 Redis，大概率会追问：“为什么不用 MySQL 存储验证码？”
标准答法：
“MySQL 的 IO 性能远低于 Redis。验证码场景具有‘高频写入、高频读取、短生命周期’的特点。性能：Redis 是内存数据库，QPS 可达十万级，而 MySQL 通常在千级。短信验证码是典型的高并发短连接场景，Redis 更合适。
数据生命周期：验证码 5 分钟后即失效，存入数据库会造成大量无效数据积累，需要额外的定时任务清理，增加系统复杂度。Redis 原生支持 TTL（Time To Live），数据过期自动删除，无需维护。
事务性：验证码的生成与验证不需要复杂的事务一致性，Redis 的单线程模型（或多线程模型下的原子命令）足以保证数据一致性。”延伸考点：分布式环境下的坑
如果系统部署在多台服务器上，用户第一次请求落在 Server A，第二次验证请求落在 Server B，会发生什么？
答法：
“这正是我使用 Redis 而非本地内存（如 HashMap）的原因。Redis 是集中式的，所有服务器共享同一份数据。如果面试中你提到使用 ConcurrentHashMap 存储验证码，面试官会直接判定你缺乏分布式系统经验，因为这在多节点部署下必然失败。”
另一个高频追问：短信被劫持怎么办？
“除了技术层面的防重放和限流，业务层面需要引入二次验证。例如，在获取验证码时，要求用户先通过图形验证码（CAPTCHA）或滑动验证，确认操作者是真人而非脚本。此外，可以监控异常 IP 行为，对同一 IP 短时间内请求大量不同手机号的验证码进行封禁。”
记忆口诀：六字真言助通关
为了方便记忆【六位数密码】的核心考点，我总结了一个“六字真言”，你在面试前默念一遍，思路立马清晰：
“安、补、存、删、限、分”安（安全随机）：用 SecureRandom，别用 Math.random()。
补（格式补齐）：%06d 左补零，防止位数不足。
存（Redis 存储）：Key 带手机号，Value 存明文或哈希，TTL 5 分钟。
删（用完即删）：验证成功立即 delete，确保单次有效。
限（频率限制）：60 秒发一次，错误 5 次锁 30 分钟。
分（分布式）：必须用 Redis，严禁用本地内存，否则多节点部署必挂。这个口诀涵盖了从生成、存储、验证到安全、部署的全生命周期。在面试中，你可以先抛出这个框架，再展开细节，会让面试官觉得你思路极其清晰。
最后，技术面试不仅是考代码，更是考你对系统边界情况的思考。当你能够主动指出“分布式环境下的状态共享”和“暴力破解的频率限制”时，你已经超越了 80% 的候选人。
你更常用 Redis 存明文还是存哈希？评论区交流，看看大家的生产环境都是怎么做的，有没有踩过更深的坑。
