验证码场景应直接用SETEX，因其是原子操作，避免SET+EXPIRE分步导致的永不过期脏数据；SETEX仅支持秒级，毫秒级需用SET+PX；校验须用GETDEL或Lua保证一次性。
Redis中EXPIRE和SETEX哪个更适合验证码场景
直接用 SETEX，别先 SET 再 EXPIRE。两者看似等价，但验证码写入必须原子性：如果网络中断或服务崩溃发生在 SET 成功、EXPIRE 失败之间，就会留下永不过期的脏数据，后续可能被恶意复用。
而 SETEX key seconds value 是单命令原子操作，Redis 保证写入和过期时间绑定生效。验证码这种短生命周期、高安全敏感的数据，必须一步到位。
-
SETEX支持秒级过期，适合 5 分钟类验证码（SETEX verify:138****1234 300 "a7b9"） - 若需毫秒级（如 2.5 分钟），改用
SET key value EX 150000 PX 150000（注意PX是毫秒） - 避免在客户端生成过期时间戳再用
EXPIREAT，时钟不同步会导致误差
校验时为什么GET后不能手动判断过期
Redis 的过期是惰性+定期删除混合机制，GET 返回非空不等于“一定没过期”——它只是说明该 key 当前未被清理，但可能刚过期几毫秒还没触发清理逻辑；反之，GET 返回 null 也不绝对代表“已过期”，可能是被误删或压根没存。
真正可靠的校验方式只有一种：GET 后立即 DEL，靠返回值判断：
-
GETDEL key（Redis 6.2+）最简洁：一次获取并删除，返回值即验证码，且确保只能用一次 - 低版本用事务：
WATCH key; MULTI; GET key; DEL key; EXEC，但要注意EXEC可能返回空数组（key 被其他客户端修改过） - 千万别
GET→ 判断字符串 → 再DEL，中间存在竞态窗口，两个请求可能同时读到同一验证码
验证码被频繁重发时如何防止 Redis 写放大
用户点“重新发送”时，如果直接 SETEX 覆盖旧 key，会触发旧 key 的过期事件（如果开启 notify-keyspace-events），还可能让客户端误以为上一个验证码仍有效。更糟的是，高频重发会让 Redis 频繁分配/释放内存。
推荐做法是显式清理 + 限频：
- 重发前先
DEL verify:138****1234，确保无残留 - 用
INCR+EXPIRE组合做发送频率控制（例如INCR sms:limit:138****1234，再EXPIRE60 秒），超过阈值直接拒绝 - 验证码 key 命名建议带业务前缀和哈希（如
verify:sms:sha256(138****1234)），避免手机号明文被扫描或泄露
PHP/Python 客户端调用SETEX的典型坑
很多客户端库对命令封装不一致，容易踩隐式类型转换的坑：
- PHP Redis 扩展：
$redis->setex('key', 300, 'abc')第二个参数是整数秒，传浮点数（如300.5）会被截断为300，别信文档里“支持毫秒”的说法 - Python redis-py：
r.setex('key', 300, 'abc')同样只接受整数秒；要毫秒得用r.set('key', 'abc', ex=300)或px=300000 - Node.js ioredis：
client.setex('key', 300, 'abc')正常，但若用client.set('key', 'abc', 'EX', 300)，注意参数顺序不能错，否则静默失败 - 所有语言下，value 传
null、undefined或空字符串，Redis 都会存成实际字符串，不是“空值”，校验时得按字符串比对
过期逻辑本身很简单，但验证码的安全部署藏在细节里：原子写入、一次性读取、防重放、限频、命名隔离——漏掉任意一环，都可能让“5分钟过期”变成形同虚设。
