Sa-Token 中实现单次请求跳过自动续期的技术方案

背景与需求分析

在用户会话管理系统中，自动续期机制是保持用户活跃状态的重要功能。Sa-Token 作为一款轻量级 Java 权限认证框架，默认会在每次调用 StpUtil.getLoginId() 时自动更新用户的活跃时间戳，以防止会话因超时而被踢出。

然而在实际业务场景中，存在一些特殊情况：

1. 系统定时轮询任务（如通知公告查询）
2. 后台自动执行的业务逻辑
3. 非用户主动触发的API调用

这些场景下的请求不应被视为用户活跃行为，如果仍然触发自动续期，会导致以下问题：

• 用户实际已离线，但因系统轮询保持会话活跃
• 统计报表中的用户活跃数据失真
• 资源浪费（维持不必要活跃会话）

技术实现方案

方案一：直接使用Token解析（基础方案）

Sa-Token 提供了直接通过Token获取登录ID的方法：

String token = StpUtil.getTokenValue();
StpUtil.getLoginIdByToken(token);

优点：

• 简单直接
• 无需框架修改

缺点：

• 需要开发人员严格区分使用场景
• 无法在拦截器层面统一控制
• 容易因误用导致安全问题

方案二：策略模式扩展（推荐方案）

通过在框架中增加策略扩展点，实现更灵活的控制：

1. 新增策略接口：

public interface SaAutoRenewFunction {
    boolean apply(SaRequest request);
}

2. 在核心逻辑中集成策略判断：

public Object getLoginId() {
    // 原有逻辑...
    if(SaStrategy.autoRenew.apply(request)) {
        updateLastActiveToNow();
    }
    // ...
}

3. 默认实现（保持向后兼容）：

public class DefaultSaAutoRenewFunction implements SaAutoRenewFunction {
    @Override
    public boolean apply(SaRequest request) {
        return true; // 默认全部续期
    }
}

最佳实践建议

场景化配置示例

针对通知轮询场景的典型配置：

public class NoticeAutoRenewStrategy implements SaAutoRenewFunction {
    private static final String NOTICE_POLLING_PATH = "/api/notice/polling";
    
    @Override
    public boolean apply(SaRequest request) {
        // 轮询接口不续期
        if(request.getPath().equals(NOTICE_POLLING_PATH)) {
            return false;
        }
        return true;
    }
}

安全注意事项

1. 关键操作必须续期：如支付、密码修改等敏感操作应强制续期
2. 白名单机制：明确哪些接口允许跳过续期
3. 日志记录：对跳过续期的请求进行审计记录
4. 超时时间分级：可设置不同的超时策略（如普通操作30分钟，轮询接口2小时）

技术原理深入

Sa-Token 的会话续期机制基于以下核心设计：

1. LastActiveTime 记录：在Token对应的存储中维护最后活跃时间
2. 双重检查机制：
   • 每次请求检查是否超时
   • 每次请求可能更新最后活跃时间
3. 可扩展点设计：
   • 通过策略模式实现业务逻辑解耦
   • 支持运行时动态调整策略

这种设计既保证了默认情况下的用户体验（自动保持会话），又为特殊场景提供了灵活控制的能力。

性能考量

引入续期策略判断对性能的影响可以忽略不计，因为：

1. 策略接口通常只做简单路径匹配
2. 相比网络IO和业务处理，策略判断耗时极短
3. 可以通过缓存策略结果进一步优化

总结

Sa-Token 通过策略扩展的方式实现了请求级别的续期控制，这种设计：

1. 保持了框架的简洁性
2. 提供了足够的灵活性
3. 不破坏现有功能
4. 易于理解和维护

开发团队可以根据实际业务需求，选择简单直接的Token解析方案，或者采用更系统化的策略扩展方案，在保证安全性的前提下，精确控制会话生命周期管理。