Redis 7 通过 TTL 控制 Session 有效期，Cookie 仅存 session_id；采用 SETEX 写入+滑动续期（剩余≤300秒才刷新），并支持 Redis 故障时签名 Token 降级校验。
Redis 7 存储和管理 Session 的 Cookie 有效期，核心不是直接“存 Cookie”，而是通过 Redis 管理 Session 数据本身，并协同 Cookie 中的 Session ID 实现会话生命周期控制。Cookie 自身只负责携带轻量、安全的标识（如 session_id），真正有效期逻辑由 Redis 的键过期（TTL）与服务端主动刷新策略共同决定。
Session 数据写入 Redis 并设置基础 TTL
用户登录成功后，服务端生成唯一 session_id（如 UUID 或加密随机串），将用户身份信息（如 userId、登录时间、客户端指纹等）序列化为字符串或哈希结构，存入 Redis，并立即设置固定基础过期时间：
- 推荐用 SETEX 命令一次性写入+设过期，例如：
SETEX sess:abc123 1800 "uid:1001|ts:1726041600|ua:chrome"（30 分钟） - 或使用 SET + EX 选项：
SET sess:abc123 "uid:1001|ts:1726041600" EX 1800 - Redis 7 对 EXPIRE/SETEX 的毫秒级精度支持更稳定，但 Session 场景通常用秒级已足够
Cookie 中只存 session_id，不存业务数据
服务端在响应头中通过 Set-Cookie 下发一个仅含 session_id 的 Cookie，关键配置必须包含：
- HttpOnly=true：防止 XSS 窃取 session_id
- Secure=true（HTTPS 环境下强制启用）
- SameSite=Lax 或 Strict：防御 CSRF
- Max-Age 或 Expires 可设为与 Redis TTL 一致（如 1800 秒），但非必需——因为 Cookie 过期只是“不再自动发送”，真正失效由 Redis 键是否存在决定
实现滑动过期（自动续期）而非简单重置
每次合法请求到来时，不能无脑调 EXPIRE sess:xxx 1800，否则高频访问会放大 Redis 压力。应采用“滑动窗口 + 阈值刷新”策略：
- 读取 Redis 中该 session 的 value，解析内嵌时间戳（如
ts:1726041600） - 计算剩余 TTL：
1726041600 + 1800 - 当前时间 - 仅当剩余时间 ≤ 5 分钟（即 300 秒）时，才执行
EXPIRE sess:xxx 1800 - 若剩余时间 > 5 分钟，跳过续期，降低 Redis 写压力
故障兜底：Redis 不可用时 Cookie 降级校验
生产环境必须避免 Redis 挂掉导致全站登出。可行做法是：
- 登录成功后，除写 Redis 外，还生成一个短期有效的、签名的 Token（如 HMAC-SHA256(userId + timestamp + secret)），加密后写入 Cookie（如
sess_sig=xxx） - Redis 不可用时，服务端转而校验该签名 Token 是否未过期、未篡改，从中安全提取 userId
- 注意：Token 中不包含权限列表、角色等敏感字段，仅用于身份轻量确认
- Redis 恢复后，需比对 Cookie Token 与 Redis 中 session 的时间戳/随机因子，防止重放；必要时主动删除旧 session key
