去年给一个内部运营平台做登录模块安全加固时，我发现原本的“RememberMe”实现几乎等于裸奔：Token有效期写死30天，存在数据库里的last_used字段从不更新，用户哪怕天天活跃，到期照样被踢下线；更要命的是注销登录后Token依旧有效，攻击者只要拿到旧Cookie就能随时“复活”账号。那次改造让我把PersistentRememberMeToken的时效管理彻底梳理了一遍，最后总结出5种不同的实现策略。
这篇文章不聊泛泛的安全理论，直接用Spring Security的持久化Token机制做载体，把这5种时效管理方式讲透：固定过期、滑动过期、双阈值组合、序列号轮换、风险自适应。每一种我都会讲清楚它的实现思路、核心代码、适用场景和坑点，最后再把常见问题和排查经验一并整理出来。如果你是做Java Web安全、想要把登录态管得更细的开发者，这篇能帮你少踩不少坑。
1. 先搞清楚：RememberMe持久化Token究竟在管什么
1.1 两种典型的RememberMe形态：本地散列Token与持久化Token
很多人对RememberMe的理解就是“勾选记住我，下次免登录”。在Spring Security里，这背后有两套完全不同的实现逻辑。
第一套是TokenBasedRememberMeServices，它的做法是把用户名、过期时间戳、MD5签名拼成一个字符串，经Base64编码后写进Cookie。下次用户访问时，服务端拿到Cookie里的token，验签通过就恢复登录态。这套方案有个明显特点：服务端无状态，靠密钥兜底。但问题也很突出，密钥一旦泄露，所有用户的token都能被伪造；同时由于token里只包含用户名和过期时间，想实现“踢人下线”“单端登录”这类精细化控制非常困难。
第二套就是PersistentTokenBasedRememberMeServices，也就是持久化Token。它不在Cookie里塞用户信息，而是生成两个核心字段：
series：系列标识，相当于某一个“登录会话”的IDtoken：随机令牌，相当于该会话当前有效的“钥匙”
服务端把这两者连同用户名、last_used时间一起存进数据库。Cookie里只放series:token，下次登录时用series去查库，比对token是否匹配。这套方案最大的优势在于：服务端可以随时让某个token失效，也能感知到token被异常使用。
1.2 为什么“时效管理”是持久化Token的安全命门
持久化Token虽然比本地散列Token安全，但它引入了一个新问题：数据库里那条记录理论上可以永远有效。如果攻击者通过XSS、中间人攻击、日志泄露等途径拿到Cookie，那他就能在无限长的时间内持续伪装成受害者。
我见过一个典型案例：某系统上线时图省事，persistent_logins表建成后没加任何有效期字段，登录一次之后，Cookie随便多少天都能用。后来做安全审计，发现测试账号的token已经存在了三个月，日志里还出现了异常的异地登录记录，但由于token“看似正常”，运维人员根本没注意到。这就是时效管理缺失的直接后果。
时效管理的本质是限定“一个脱离实时交互的凭证能存活多久”。它跟Session会话超时不是一个东西：Session由服务端内存或分布式缓存管理，通常跟着浏览器会话走；而RememberMe Cookie是“跨会话”的，浏览器关了再开还在。所以必须有一套独立的生命周期规则来约束它，这就是我们接下来要讲的5种方式。
2. 五种时效管理方式一一拆解
2.1 方式一：固定过期时间（Absolute Expiration）
这是最直观的思路：在创建token时指定一个生命周期，比如7天、30天。无论用户是否活跃，到达截止时间就强制失效。
用SQL来表达就是查询时增加一个时间判断：
SELECT * FROM persistent_logins WHERE series = ? AND last_used + INTERVAL '30 days' > NOW();在Java侧，可以给PersistentRememberMeToken增加一个expiresAt字段，判断逻辑类似：
public boolean isAbsolutelyExpired(PersistentRememberMeToken token) { long expiresAt = token.getLastUsed().getTime() + ABSOLUTE_LIFETIME_MS; return System.currentTimeMillis() > expiresAt; }固定过期时间的优点不用多说：实现简单、预期明确、合规审计容易解释。但它有一个明显的体验缺陷——用户明明每天都登录，满30天照样要重新输一次账号密码。对于需要长期在线的业务系统，这很容易招致用户抱怨。
所以固定有效期比较适合两类场景：一是安全合规要求硬性规定会话最大存活时间的系统；二是用户授权级别较高、宁可牺牲体验也要控制暴露面的场景。
注意：有的团队把
last_used当成创建时间来用，这是不对的。固定过期时间应当基于“创建时间”或“最近一次登录时间”？严格来说应该是“创建时间+绝对生命周期”。如果基于last_used算，那就变成了滑动过期，这是两种完全不同的语义。
2.2 方式二：滑动过期时间（Sliding Expiration）
滑动过期的核心思想是：只要用户在持续使用，token就始终有效；一旦超过设定的空闲时间没有动作，token立即作废。用一句话概括就是“活跃用户永不失联，沉默用户自动清理”。
实现上需要做两件事。第一，每次请求携带RememberMe Cookie通过校验后，更新last_used为当前时间；第二，校验时比较“当前时间 - last_used”是否超过空闲阈值：
long idleMillis = System.currentTimeMillis() - token.getLastUsed().getTime(); if (idleMillis > IDLE_TIMEOUT_MS) { // 空闲超时，删除该series并拒绝自动登录 tokenRepository.removeUserTokens(token.getUsername()); return null; } // 通过校验，刷新 last_used token.setLastUsed(new Date()); tokenRepository.updateToken(token.getSeries(), token.getTokenValue(), new Date());滑动过期对用户非常友好，尤其适合那种“每次进系统都要在多个页面之间连续操作”的办公场景。但它有个潜在风险：如果一个用户保持着自动刷新页面的习惯，理论上可以让token无限期存活下去，这其实和“永不过期”没有本质区别。
另外，实现时要注意性能问题：每次请求都更新一次last_used，会让数据库写入变得非常频繁。我的做法是引入一个节流器，比如距离上次更新时间超过5分钟才执行DB更新：
if (now.getTime() - token.getLastUsed().getTime() > REFRESH_THRESHOLD_MS) { tokenRepository.updateToken(...); }2.3 方式三：固定+滑动双阈值（Two-Policy Combination）
如果你既想要滑动过期的体验，又不希望token无限期存活，那就把固定过期和滑动过期组合起来：取两者的交集，任意一个条件触发就判定失效。也就是说：
- 从创建时刻开始，最多存活
ABS_LIFETIME（绝对上限） - 从最近一次活跃开始，最多空闲
IDLE_TIMEOUT（空闲上限） - 两者先到先失效
代码上一段就能覆盖：
public boolean isTokenExpired(PersistentRememberMeToken token) { long now = System.currentTimeMillis(); boolean absoluteExpired = (now - token.getSince().getTime()) > ABSOLUTE_LIFETIME_MS; boolean idleExpired = (now - token.getLastUsed().getTime()) > IDLE_TIMEOUT_MS; return absoluteExpired || idleExpired; }这里有个容易被忽略的细节：既然要计算绝对生命周期，就必须在表里额外记录一个since或created_at字段，不能复用last_used。因为last_used会被滑动刷新，一旦复用它，绝对生命周期实质上就变成了“永远从最后一次活跃开始算”，双阈值的意义就没了。
双阈值组合是目前企业级应用里最常用的一套方案。举个例子：某支付类管理后台设置了“绝对生命周期30天 + 空闲超时7天”，普通员工在30天内只要时不时有操作就一直能自动登录；一旦出差七天没开系统，回来就得重新登录；超过30天无论多活跃都会被强制要求重新认证。这套规则兼顾了体验与安全。
2.4 方式四：版本轮换与序列号机制（Token Rotation & Series）
前三种方式都在解决“token能活多久”，方式四直接换了个思路：让token在用一次之后就失效。这就是Spring Security的PersistentTokenBasedRememberMeServices默认行为——每次自动登录成功后，服务端生成一个新的token值并更新数据库，旧的token作废。
它的底层逻辑是：
浏览器 Cookie: series=abc, token=xyz 服务端 DB: series=abc, token=xyz 请求1 -> 校验通过 -> 生成新 token=uvw -> 更新DB 浏览器 Cookie: series=abc, token=xyz （浏览器侧的token直到下次请求才会更新） 请求2 -> 拿旧token xyz 去校验 -> 发现不匹配 -> 判定“疑似盗用”看到这里你可能会问：用户只是同时在两个浏览器标签页里操作，不也会触发这种误判吗？没错。所以Spring Security的做法是：如果series存在但token不匹配，先删除该用户的所有持久化token，然后抛出RememberMeAuthenticationException，强制用户重新登录。这是最安全的处置方式，但实现时要注意并发场景的容错。
“版本轮换+序列号机制”本质上是一种“可吊销”的时效管理方式。它不依赖时间判断，而是让每个token都变成一次性凭证，只有series代表长会话。这带来一个直接收益：哪怕攻击者偷到了Cookie，只要受害者还在正常使用，攻击者手里的token就会在第一次使用时被识别为“已过期/被轮换”，从而触发全量失效，把受害者的会话也一并封禁。这在安全领域叫“token重用检测”，是检测Cookie盗用的有效手段。
要实现完整的序列号时效策略，我一般还会加一个token_version字段，每次轮换时做乐观锁更新：
int rows = jdbcTemplate.update( "UPDATE persistent_logins SET token=?, last_used=? WHERE series=? AND token=?", newToken, now, series, oldToken); if (rows == 0) { // 说明旧token已经不存在，可能被轮换或删除 // 按策略：强制清除该用户所有token }经验之谈：序列号轮换不要跟“纯固定过期”混在一起用，否则用户在临近过期前每次刷新都触发DB写操作，导致无谓的压力。我通常把它跟双阈值配合：
series有绝对生命周期，token则每次使用都轮换。
2.5 方式五：风险自适应的动态时效（Risk-based Expiration）
最后一种方式步子迈得最大：不同用户、不同设备、不同风险等级下的token有效期完全动态计算。核心思想是“安全上下文不同，生命周期就应该不同”。
判定维度可以包括：
- 用户角色：管理员token给24小时，普通员工给7天
- 登录设备：新设备首次登录给1天，常用设备给7天
- 登录IP可信度：内网IP、白名单IP给长时效，公网且非常用IP给短时效
- 用户行为评分：风控系统输出低风险时拉长有效期，高风险时缩短甚至立刻失效
在Spring Security中，自定义入口在RememberMeServices的实现类里。我惯用的做法是定义一个策略接口：
public interface RememberMeExpirationPolicy { long resolveAbsoluteLifetime(Authentication authentication, HttpServletRequest request); long resolveIdleTimeout(Authentication authentication, HttpServletRequest request); }然后在processAutoLoginCookie校验通过后，调用策略接口计算该请求对应的有效期，并将计算结果写入token记录的expires_at字段：
long maxAge = expirationPolicy.resolveAbsoluteLifetime(authentication, request); long idleTimeout = expirationPolicy.resolveIdleTimeout(authentication, request); tokenRecord.setExpiresAt(new Date(now.getTime() + maxAge)); tokenRecord.setIdleTimeout(idleTimeout);风险自适应的实现成本最高，因为它往往需要跟风控系统、设备指纹模块、用户画像联动。但它的收益也最明显：把“一刀切”的时效策略变成了“千人千面”的安全保障。如果你所在的系统已经建设了风控基础设施，把它接入RememberMe时效管理，是性价比极高的加固手段。
3. 实操落地：在Spring Security里把这套机制串起来
3.1 表结构设计：从默认三字段扩展为完整时效管理
Spring Security默认提供的JdbcTokenRepositoryImpl对应的表结构很简单：
CREATE TABLE persistent_logins ( username VARCHAR(64) NOT NULL, series VARCHAR(64) PRIMARY KEY, token VARCHAR(64) NOT NULL, last_used TIMESTAMP NOT NULL );只有四个字段，显然承载不了我们前面说的双阈值、版本号、风险策略。我通常会把它扩展成下面这样：
CREATE TABLE persistent_logins ( id BIGSERIAL PRIMARY KEY, username VARCHAR(128) NOT NULL, series VARCHAR(64) NOT NULL, token VARCHAR(256) NOT NULL, last_used TIMESTAMP NOT NULL, created_at TIMESTAMP NOT NULL, expires_at TIMESTAMP NOT NULL, idle_timeout_minutes INTEGER NOT NULL, token_version INTEGER NOT NULL DEFAULT 0, device_info VARCHAR(256), login_ip VARCHAR(64) ); CREATE UNIQUE INDEX idx_persistent_logins_series ON persistent_logins(series);这里所有非空字段都建议加上默认值，防止历史数据或极端情况下出现NULL导致NPE。created_at记录token创建时间，是绝对生命周期的起点；expires_at记录动态算出的截止时间；idle_timeout_minutes记录空闲阈值；token_version用于乐观锁并发控制。
3.2 自定义Repository实现时效判断
有了表结构，就需要自定义PersistentTokenRepository实现类，把时效判断内聚到数据访问层里。下面这个实现类是核心骨架：
public class ExpiringPersistentTokenRepository implements PersistentTokenRepository { private final JdbcTemplate jdbcTemplate; public ExpiringPersistentTokenRepository(JdbcTemplate jdbcTemplate) { this.jdbcTemplate = jdbcTemplate; } @Override public void createNewToken(PersistentRememberMeToken token) { jdbcTemplate.update( "INSERT INTO persistent_logins " + "(username, series, token, last_used, created_at, expires_at, idle_timeout_minutes, token_version) " + "VALUES (?, ?, ?, ?, ?, ?, ?, ?)", token.getUsername(), token.getSeries(), token.getTokenValue(), token.getDate(), token.getDate(), new Date(token.getDate().getTime() + ABSOLUTE_LIFETIME_MS), IDLE_TIMEOUT_MINUTES, 0); } @Override public void updateToken(String series, String tokenValue, Date lastUsed) { // 乐观锁：只有token匹配时才更新 int rows = jdbcTemplate.update( "UPDATE persistent_logins SET token=?, last_used=?, token_version=token_version+1 " + "WHERE series=? AND token=?", tokenValue, lastUsed, series, tokenValue); if (rows == 0) { // token已被轮换或删除，说明存在并发或疑似盗用 // 这里按策略抛出异常，由上层处理 throw new RememberMeAuthenticationException("Token was already rotated"); } } @Override public PersistentRememberMeToken getTokenForSeries(String seriesId) { return jdbcTemplate.query( "SELECT username, series, token, last_used, expires_at, idle_timeout_minutes " + "FROM persistent_logins WHERE series=?", rs -> { if (!rs.next()) { return null; } Date expiresAt = rs.getTimestamp("expires_at"); if (expiresAt != null && expiresAt.getTime() < System.currentTimeMillis()) { // 绝对过期，返回null并在上层删除记录 return null; } return new PersistentRememberMeToken( rs.getString("username"), rs.getString("series"), rs.getString("token"), rs.getTimestamp("last_used")); }, seriesId); } @Override public void removeUserTokens(String username) { jdbcTemplate.update("DELETE FROM persistent_logins WHERE username=?", username); } public void removeSeries(String series) { jdbcTemplate.update("DELETE FROM persistent_logins WHERE series=?", series); } }这里有几个实现要点：
getTokenForSeries里同时做了绝对过期判断，一旦发现expires_at已经过去，直接返回null，让上层走“重新登录”流程。updateToken必须用WHERE series=? AND token=?作为乐观锁条件，否则并发两个请求同时轮换token，会导致后一个请求把已经轮换过的token再次更新，破坏安全性。- 返回
PersistentRememberMeToken时，只映射需要的四字段即可，因为Spring Security的标准接口就是这四个字段，额外的字段由我们内部用。
3.3 RememberMeServices与过滤器配置
核心Repository完成后，定义一个带策略支持的RememberMeServices实现类：
public class PolicyRememberMeServices extends PersistentTokenBasedRememberMeServices { private final ExpiringPersistentTokenRepository tokenRepository; public PolicyRememberMeServices(String key, ExpiringPersistentTokenRepository tokenRepository) { super(key, tokenRepository); this.tokenRepository = tokenRepository; } @Override protected PersistentRememberMeToken processAutoLoginCookie( String[] cookieTokens, HttpServletRequest request, HttpServletResponse response) { if (cookieTokens.length != 2) { throw new InvalidCookieException("RememberMe cookie must have 2 tokens"); } final String presentedSeries = cookieTokens[0]; final String presentedToken = cookieTokens[1]; PersistentRememberMeToken token = tokenRepository.getTokenForSeries(presentedSeries); if (token == null) { throw new RememberMeAuthenticationException("No persistent token found"); } // 校验当前token是否匹配 if (!presentedToken.equals(token.getTokenValue())) { // 疑似盗用：清除该用户所有token tokenRepository.removeUserTokens(token.getUsername()); throw new CookieTheftException("Invalid remember-me token"); } // 检查空闲超时 long idleMs = System.currentTimeMillis() - token.getLastUsed().getTime(); if (idleMs > IDLE_TIMEOUT_MS) { tokenRepository.removeSeries(presentedSeries); throw new RememberMeAuthenticationException("Remember-me token idle expired"); } // 通过校验，轮换token String newToken = generateToken(); tokenRepository.updateToken(presentedSeries, newToken, new Date()); // 刷新Cookie（重要：把新token写回浏览器） addCookie(new TokenBasedRememberMeServiceToken(presentedSeries, newToken), request, response); return new PersistentRememberMeToken(token.getUsername(), presentedSeries, newToken, new Date()); } private String generateToken() { byte[] random = new byte[32]; new SecureRandom().nextBytes(random); return new String(Base64.getEncoder().encode(random)); } }这里有个实际开发中很容易踩的坑：processAutoLoginCookie里轮换完token后，必须同步把新token写回浏览器的Cookie。如果你只更新了数据库，没更新Cookie，用户下一次请求就会拿旧token来校验，触发“不匹配”逻辑，把自己误判成盗用者。Spring Security原生的实现里，onLoginSuccess和processAutoLoginCookie都会调addCookie，但自定义时很容易漏掉这一步。
在Security配置里把所有东西接起来：
@Bean public SecurityFilterChain filterChain(HttpSecurity http, RememberMeServices rememberMeServices) throws Exception { http .authorizeHttpRequests(auth -> auth .requestMatchers("/login", "/static/**").permitAll() .anyRequest().authenticated()) .formLogin(form -> form .loginPage("/login") .defaultSuccessUrl("/dashboard", true)) .rememberMe(remember -> remember .rememberMeServices(rememberMeServices) .key("unique-secret-key-for-signing")); return http.build(); } @Bean public RememberMeServices rememberMeServices(DataSource dataSource) { JdbcTemplate jdbcTemplate = new JdbcTemplate(dataSource); ExpiringPersistentTokenRepository repo = new ExpiringPersistentTokenRepository(jdbcTemplate); PolicyRememberMeServices services = new PolicyRememberMeServices("unique-secret-key-for-signing", repo); DefaultCookieSerializer cookieSerializer = new DefaultCookieSerializer(); cookieSerializer.setCookieName("REMEMBER_ME"); cookieSerializer.setUseSecureCookie(true); cookieSerializer.setUseHttpOnlyCookie(true); cookieSerializer.setSameSite("Lax"); services.setCookieSerializer(cookieSerializer); services.setParameter("remember-me"); services.setAlwaysRemember(false); return services; }需要提醒一句：如果你用的是Spring Security 6.x，配置写成上面的lambda风格就可以；如果是5.x，把rememberMe(remember -> ...)换成rememberMe().rememberMeServices(...).key(...)效果一样，API形式略有差异，核心接口没变。
3.4 过期Token的主动清扫
时效管理的最后一步是物理清理。即使Redis或数据库里的记录逻辑上已经过期，如果不删，垃圾数据会越积越多。我是通过@Scheduled定时任务做的：
@Scheduled(cron = "0 0 3 * * *") // 每天凌晨3点 public void cleanExpiredTokens() { int deleted = jdbcTemplate.update( "DELETE FROM persistent_logins WHERE expires_at < ? OR " + "(idle_timeout_minutes > 0 AND last_used + idle_timeout_minutes * INTERVAL '1 minute' < NOW())", new Date()); log.info("cleaned expired remember-me tokens: {}", deleted); }注意这个定时任务在高并发环境下，扫表操作可能跟用户擦肩而过——用户刚续期完就被扫掉。所以删除条件里last_used + idle_timeout的判断最好留出几分钟的缓冲，或者干脆只删绝对过期的记录，空闲过期的记录在autoLogin时处理。我的习惯是：定时任务只清理expires_at明确的过期数据，空闲超时判断放在请求链路里实时触发，两者各司其职，避免边界问题。
4. 五种方式怎么选：特性对比与场景建议
4.1 五种时效管理方式的直观对比
| 方式 | 生命周期定义 | 用户体验 | 安全强度 | 实现复杂度 | 典型场景 |
|---|---|---|---|---|---|
| 固定过期 | 创建后到期即死 | 较差，活跃用户也要重登 | 中 | 低 | 合规硬性要求、低风险内部工具 |
| 滑动过期 | 活跃即续期，空闲即失效 | 很好 | 中低，活跃用户永不失效 | 低 | 办公OA、非敏感后台 |
| 双阈值组合 | 绝对上限+空闲上限，先到先失效 | 较好 | 较高 | 中 | 大多数企业应用 |
| 序列号轮换 | token一次一换，series有绝对上限 | 较好 | 高，可检测盗用 | 中高 | 高安全要求、多设备场景 |
| 风险自适应 | 动态计算有效期 | 最好 | 最高 | 高 | 金融、风控、高敏系统 |
4.2 我的选型原则
如果你不知道怎么选，我给你一个非常实用的决策路径：
先问自己三个问题。第一，系统里是否存在合规要求必须定义“最大会话存活时间”？如果有，固定过期或双阈值就躲不掉。第二，用户对“重新登录”的容忍度有多高？如果这是一个每天都要打开的内部系统，纯固定过期会制造大量抱怨，必须引入滑动续期。第三，账号被窃取的后果有多严重？一旦后果严重，序列号轮换几乎是必选项。
我的默认组合是“双阈值+序列号轮换”：绝对生命周期给30天，空闲超时给7天，每次自动登录都轮换token。这套组合在绝大多数中大型业务系统里足够稳健，既不折腾用户，也能在Cookie被盗时及时发现。如果你的系统有条件接入设备指纹和风控评分，再叠加风险自适应，那就是完整版的安全架构了。
5. 实战中的坑：常见问题与排查实录
5.1 用户一直活跃却被“假过期”踢下线
现象：用户明明每天在用系统，但每隔几天就莫名其妙被要求重新登录。
排查思路：先看数据库中该用户token的last_used字段。如果last_used停留在几天前，说明token虽然在每次请求时都能通过校验，但updateToken并没有被触发。常见原因有两个：一是Cookie里没有正确写回轮换后的新token，导致每次校验虽然通过，但数据库里的token始终是旧值；二是某些页面没有携带RememberMe Cookie，比如静态资源请求、Ajax请求走的是另一套过滤器链，压根没进RememberMeFilter。
解决方案：在自定义RememberMeServices中确认每次轮换后都调用addCookie，同时检查过滤器链配置，确保rememberMe()过滤器在AuthorizationFilter之前被执行。
5.2 Token注销后仍然有效
现象：用户点击“退出登录”，但关闭浏览器再打开，居然还是登录状态。
这个坑多半不是RememberMe本身的锅，而是注销处理器没有调用removeUserTokens。Spring Security的LogoutFilter默认会处理RememberMe，但如果你自定义了RememberMeServices，一定要在注销时显式清理：
http.logout(logout -> logout .logoutSuccessUrl("/login?logout") .deleteCookies("REMEMBER_ME") .addLogoutHandler((request, response, authentication) -> { rememberMeServices.logout(request, response, authentication); }));RememberMeServices.logout()默认会调用tokenRepository.removeUserTokens(username)，所以只要别把这一步省掉，注销后token就会彻底失效。
5.3 Cookie被篡改或丢失后的应急处理
现象：用户反馈无法自动登录，日志里出现CookieTheftException。
CookieTheftException是Spring Security故意抛出的“疑似盗用”信号，它意味着有人拿着一个不存在的或已过期的token来尝试自动登录。默认处理是直接把这个用户的所有持久化token删掉，防止攻击者持续尝试。
但这里有两面性：如果用户自己有多个浏览器或多个设备，其中一个设备触发了token轮换，另一个设备拿着旧token再来访问，也会被判定为“盗用”。所以我在生产环境里，会记录异常触发的IP和UserAgent到独立日志表，而不是第一时间全量删除，给运维留出判断空间。当然，如果你对安全要求极高，就维持默认的严格模式，但要做好用户被误伤的预案。
5.4 多节点部署下的Token一致性
如果你的服务是多个节点部署，且没有做Session共享，那么RememberMeToken的存储也必须集中。我遇到过最典型的错误是：有人把persistent_logins表搭在了本地数据库，用户在A节点登录生成的token，下一次请求被负载均衡到B节点，B节点查不到记录，自动登录直接失败。
这种问题没有太多技巧，核心就是要保证数据库或Redis是共享的。同时要注意：updateToken的乐观锁依赖数据库行锁机制，在高并发、多节点环境下尤为重要。否则两个节点同时更新同一个series，可能出现竞态条件。
5.5 新版本Spring Security API适配
从Spring Security 5.x切到6.x，最明显的变化是HttpSecurity的配置风格统一为lambda DSL，rememberMe()的链式调用多了些约束。此外，PersistentTokenRepository接口本身没有变化，PersistentRememberMeToken的字段依然照旧。所以如果你之前基于5.x写的自定义Repository，迁移到6.x基本可以直接平移，只需要把WebSecurityConfigurerAdapter换成SecurityFilterChain风格。
如果你使用的是Spring Boot 3.x，还要注意一点：默认的SecurityAutoConfiguration会注册一套默认的RememberMe配置，如果你自己也定义了rememberMeServices，一定要在http.rememberMe()里显式指定自己的Bean，否则容易因为Bean冲突导致配置不生效。
6. 一点补充：时效管理之外的RememberMe安全基线
上文聊完了5种时效管理方式，但真正到了生产环境，光管好有效期还不够。还有几条安全基线，我每次做登录模块加固时都会一并检查。
第一，RememberMe Cookie必须设置HttpOnly和Secure。HttpOnly可以拦截绝大部分XSS窃取Cookie的攻击，Secure确保Cookie只在HTTPS连接下传输。
第二，设置合适的SameSite属性。Lax模式是兼顾体验与安全的默认选择，如果业务不需要跨站携带Cookie，直接上Strict。
第三，RememberMe密钥要独立管理，不要跟其他签名密钥复用。密钥一旦泄露，攻击者可以直接构造合法的RememberMe Cookie，绕过数据库里的token记录，这种风险是任何时效策略都拦不住的。
第四，登录成功后应当“重置”RememberMe令牌。很多站点只在登录时勾选了“Remember Me”才签发token，这是对的；但有些实现里，即使用户这次没有勾选，也会因为历史Cookie而被自动持久化登录，这相当于裸奔。
我在实际项目中通常会把这几条写进安全开发规范，配合上文五种时效策略，形成一套完整的RememberMe治理方案。你如果正在做登录模块的重构，建议先把手头的token生命周期理清楚，再逐步叠加序列号轮换和动态策略。安全这件事，核心从来不是某一个单点措施，而是层层递进的纵深防御。
