remember me 失效主因是密钥不一致：spring security 必须显式配置 .key("xxx")，否则每次重启生成随机 uuid 导致签名不匹配；密钥需固定、持久化、长度合规（建议≥32位随机字符串），且在自定义 authenticationfilter 和 httpsecurity 配置中保持一致。
Remember Me 失效，八成不是 Cookie 过期或浏览器清缓存，而是密钥没对上。
密钥必须固定且重启不丢失
Shiro 和 Spring Security 的 Remember Me 都依赖服务端密钥完成加解密或签名。如果每次应用启动都生成新密钥（比如靠 SecureRandom 临时生成、或未显式配置），那之前加密的 Cookie 就再也无法解开了——不是“失效”，是“认不出来”。
- Shiro 默认使用硬编码密钥（如
kPH+bIxk5D2deZiIxcaaaA==），但该密钥公开、极不安全，仅用于测试 - Spring Security 必须显式调用
.key("xxx")，否则会自动生成一个随机密钥，每次重启都变 - 密钥应作为配置项写入
application.yml或外部配置中心，禁止写死在代码里又不持久化
密钥长度与格式要合规
不同框架对密钥有明确要求：长度不够、含非法字符、Base64 解码失败，都会导致解密流程中途崩溃。
- Shiro AES 加密推荐使用 128 位（16 字节）或 256 位（32 字节）密钥；若用 Base64 表示，对应长度为 24 或 44 字符（含 = 填充）
- Spring Security 的
key()参数本质是签名盐值，无严格长度限制，但建议 ≥32 位高强度随机字符串（如用openssl rand -base64 32生成） - 避免使用中文、空格、制表符等不可见字符；配置文件中注意引号包裹，防止 YAML 解析截断
别混淆“加密密钥”和“签名密钥”
Shiro 和 Spring Security 名义上都叫 “key”，但底层用途不同，混用会导致行为异常。
- Shiro 的
encryptionCipherKey用于 AES 对称加解密，直接影响序列化数据能否还原 - Spring Security 的
key仅参与 HMAC 签名计算（如 SHA-256 + key + username + expiry），不涉及加解密，只防篡改 - 两者不可互换；升级或迁移时务必核对文档，例如从 Shiro 切到 Spring Security，不能直接复用原 AES 密钥
验证密钥是否生效的简单方法
不靠日志猜，直接看运行时行为。
- Spring Security：启动后检查控制台是否打印类似
Using generated key for remember-me: xxx—— 出现这句说明你没配.key() - Shiro：调试进入
JcaCipherService.decrypt()，观察传入的cipherKey字节数组是否与你配置的一致 - 最直白方式：停掉服务 → 修改密钥配置 → 重启 → 用旧 Cookie 访问 → 若仍能自动登录，说明密钥根本没生效（可能配错位置或被覆盖）
