首先得先量化一下这个概率有多低：假设你用的是Base64字符集（64种字符），50位的验证码就有64^50种可能——这个数字大到什么程度？比可观测宇宙中的原子总数还要多好几个数量级。100位的话更是天文数字，重复的概率低到在人类文明存续期内都几乎不可能发生。

接下来回到你的问题，分两种场景说业内的常规做法：

普通业务系统（如登录/找回密码验证码） #

大部分情况下完全不需要存储历史验证码来防范重复，原因有两个：

• 概率极低，几乎是“理论上存在但实际不可能发生”的事件，为这种情况增加DB存储和查询的开销完全得不偿失；
• 验证码的使用逻辑本身就天然规避了重复风险：生成验证码时，我们会把它和用户的唯一标识（手机号、邮箱、用户ID）绑定，验证时也是用户标识+验证码一起校验。就算极端到真出现重复，A用户的验证码只能验证A的身份，B用户的只能验证B的，不会出现身份混淆的问题。

高安全等级系统（如大额转账令牌、API密钥、身份认证凭证） #

这类系统对风险零容忍，会做额外的唯一性保障，但通常也不是存储所有历史记录，而是用更高效的方式：

• 生成时校验当前有效凭证：因为验证码/令牌都是短期有效（比如5分钟到1小时），有效时间内的凭证数量非常有限，生成新凭证时只需要查询DB中当前有效的凭证是否重复，开销极小；
• 引入唯一标识前缀：在随机字符串前加入全局唯一的标识（比如时间戳的哈希、用户ID的哈希、自增序列），从生成逻辑上保证绝对唯一，根本不需要事后校验；
• 使用带唯一性的生成算法：比如UUID v1（基于时间戳和MAC地址）、UUID v7（基于时间戳的现代版本），或者自定义的“时间戳+随机字符串”组合，既保留随机性，又确保全局唯一。

额外提醒：核心风险不在重复本身 #

其实你更应该关注的是验证码的验证逻辑正确性：比如是否限制了验证码的使用次数（只能用一次）、是否设置了合理的过期时间、是否防止暴力破解（比如限制每分钟验证次数）。这些才是实际业务中可能遇到的安全风险，而验证码重复的概率实在太低，优先级远低于这些问题。

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