在做社区旧物互换平台时用户注册和登录都需要验证码。最开始我也考虑过几种常见方案把验证码存进数据库表、引入 Redis或者直接调用第三方验证码服务。但这个项目目前主要是本地开发和小范围演示如果为了验证码专门引入 Redis会增加部署复杂度如果建一张verification_code表又会产生大量短生命周期数据。于是最终我选择了一个更轻量的方案在code_service.py中用一个进程内存字典_STORE来存储验证码。为什么不用 RedisRedis 确实很适合做验证码缓存支持过期时间、分布式共享、高并发访问。但对于当前阶段的项目来说它有几个成本需要额外安装和运行 Redis 服务本地开发环境配置会变复杂如果只是单实例、小规模使用收益并不明显。所以我的思路是先把核心业务跑通用进程内存字典降低开发成本。如果后续项目部署到多实例服务器再考虑切换到 Redis。为什么不用数据库表验证码本身有这几个特点有效期很短通常 5 分钟左右校验通过后就应该失效写入和读取都非常频繁不需要长期保存。如果把这些数据都写入数据库会增加不必要的 IO 开销。而且验证码校验通过后还要删除或标记失效表结构也会变得比较臃肿。所以最后我决定验证码只存在于内存中不依赖 Redis也不落库。最终方案code_service.py中的_STORE我在code_service.py里定义了一个字典_STORE用来保存验证码和发送时间。当前平台的验证码规则是验证码有效期5 分钟发送间隔限制60 秒内不能重复发送校验成功后立即删除存储方式进程内存字典_STORE核心代码大致是这样的这里没有用第三方缓存库而是直接在字典里存验证码和过期时间。每次校验时先判断是否存在再判断是否超过 5 分钟最后比较验证码是否正确。在 FastAPI 中怎么接入在 FastAPI 路由里可以把验证码发送和校验逻辑封装成工具函数这样前端只需要传入邮箱或手机号后端负责生成验证码、写入 _STORE、校验和删除。这个方案的优点轻量不需要安装 Redis也不需要建表。开发快本地启动 FastAPI 就能直接测试。适合短生命周期数据验证码本来就不需要持久化。结构简单一个字典就能完成存储、校验和清理。需要注意的限制这个方案也有明显边界重启服务后验证码会丢失因为数据只存在进程内存里多实例部署时无法共享每个进程有独立_STORE需要手动清理过期数据字典不会自动删除过期项生产环境建议加监控避免内存字典异常导致用户无法登录。所以它更适合开发、测试、演示或单实例部署场景。如果项目后续用户量变大或者需要多节点部署我会考虑把验证码迁移到 Redis。后续改进方向目前这个验证码模块已经接入了平台的邮箱和手机号验证流程。后续可以继续完善接入真实 SMTP 邮箱服务接入短信服务商增加图形验证码防止机器批量请求把验证码发送次数写入日志方便排查异常在多实例部署时替换为 Redis 后端。小结这个验证码方案并不复杂但它解决了一个很实际的问题在没有 Redis、不想建表的情况下如何快速实现一个可用的验证码系统。对于学生项目、个人项目或早期原型来说轻量方案往往更合适。先把核心流程跑通再根据实际部署需求逐步升级会比一开始追求“完美架构”更高效。如果你也在做类似的全栈项目欢迎交流你的验证码方案。下一篇我会继续分享这个平台的物品管理与数据库设计。