Firebase手机认证中点击重发按钮后如何确保生成新验证码？

1. 修正OTP生成的核心逻辑 #

• 每次重发时必须基于当前精确时间戳+用户唯一标识+随机盐值生成新的OTP种子，绝对不能复用固定时间窗口（比如15分钟）作为生成依据。例如用手机号+当前毫秒时间戳+随机6位字符串作为原始输入，再通过HMAC-SHA1等算法生成OTP，确保每次请求的种子完全唯一。
• 彻底移除任何会让同一用户在一段时间内复用种子的逻辑，哪怕是同一用户连续重发，也强制生成全新种子。

2. 强制失效并清理旧验证码 #

• 每次触发「重发」操作时，后端立即将该用户名下所有未过期的旧OTP标记为失效，直接删除或更新存储中的旧记录。比如用Redis存储时，以用户手机号为key，重发时先执行DEL 手机号，再将新OTP存入并设置1分钟过期时间。
• 确保存储中永远只保留用户当前最新的OTP，不允许同时存在多个有效OTP条目。

3. 重发请求的唯一性校验 #

• 给每个重发请求生成唯一请求ID（如UUID），后端记录已处理过的请求ID，遇到重复ID直接拒绝，避免因网络重试、重复提交等情况触发重复生成逻辑。
• 所有OTP有效性判断以后端存储的最新状态为准，不依赖客户端传递的任何状态参数。

4. 排查缓存与存储异常 #

• 检查缓存（如Redis）的过期配置：如果误设置了15分钟的全局过期时间，会导致旧OTP未被及时清理，重发时被错误读取。确保每个OTP的过期时间严格设为1分钟，且重发时强制覆盖旧缓存。
• 验证存储操作的顺序：必须是「先删除旧记录，再存入新OTP」，避免短时间内旧OTP还能被读取到。

5. 日志回溯与场景模拟 #

• 在OTP生成、存储、重发的每个环节添加脱敏日志，记录用户手机号、生成时间、种子参数、OTP过期时间、请求ID等信息，出现重复问题时直接回溯定位是生成逻辑重复还是读取了旧存储值。
• 手动模拟15分钟后的重发场景，对比两次请求的种子参数是否完全不同，验证生成逻辑的唯一性。

内容的提问来源于stack exchange，提问作者Pusoy