安全存会话的核心是不让redis看到明文：只存必要字段、用哈希代替敏感信息、强制设置ttl、选用volatile-lru淘汰策略，并避免应用层手动清理过期数据。
Redis 本身不提供原生的字段级加密能力，所有数据以明文形式存于内存，直接用 SET 存 session 就等于把敏感信息裸奔在服务端。安全存会话的核心不是“加密 Redis”，而是“不让 Redis 看到明文”。
session 数据不该由 Redis 加密，而该在写入前脱敏
你无法靠配置让 Redis 自动加密 session_id 或用户手机号——它压根没这个模块。强行在应用层用 AES 加密整个 session 字符串再塞进 Redis，反而带来三重风险：密钥管理难、解密失败导致 session 丢失、加解密拖慢高并发读取。
- 真正该加密的是传输过程（HTTPS）和落库环节（如 MySQL 的
AES_ENCRYPT），不是中间缓存 - Redis 中只存必要字段：比如
user_id、role、last_active_ts，去掉身份证、token 原文、密码哈希等高危字段 - 若必须存 token，用单向哈希（如
SHA256(token + salt)）代替明文，验证时比对哈希值即可
过期时间必须用 EXPIRE 或 SETEX，不能依赖应用层定时任务
很多人在代码里起个后台线程，每分钟扫一遍 session 表删过期记录——这既无法保证原子性，又和 Redis 的惰性+定期删除机制冲突，极易造成内存泄漏或重复清理。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 创建 session 时务必用
SETEX session:abc123 1800 "{...}"（1800 秒 = 30 分钟），让过期逻辑下沉到 Redis 内核 - 避免先
SET再EXPIRE：网络中断可能导致 key 写入成功但过期没设上，变成永不过期的脏数据 - 如果 session 需要续期（如用户持续操作），用
EXPIRE覆盖原 TTL 即可，不要DEL+SETEX，前者是 O(1)，后者是两次网络往返+两次内存分配
淘汰策略选 volatile-lru，别碰 allkeys-lru
session key 全部带 TTL，属于“明确会过期”的数据。一旦配成 allkeys-lru，Redis 在内存吃紧时可能把还没过期的 session 给踢掉——用户正在操作突然登出，就是这么来的。
- 检查当前策略：
CONFIG GET maxmemory-policy，确认返回值是volatile-lru或volatile-ttl -
volatile-ttl更激进：优先踢掉“马上就要过期”的 session，适合短时效场景（如短信验证码）；volatile-lru更稳：踢“最久没访问”的，适合登录态维持 - 严禁设为
noeviction：内存满时写入失败会直接抛异常，API 返回 500，而不是优雅降级
最易被忽略的一点：Redis 的惰性删除只在 key 被访问时触发。如果某个 session 过期了但没人再请求它，它就一直占着内存，直到下一次定期扫描（默认每 100ms 抽样）或内存不足触发淘汰。所以过期时间不能设得过大，30 分钟比 24 小时更可控——不是为了省那点内存，而是降低过期 key 滞留窗口带来的排查难度。
