轻量级Java权限认证框架实战：JWT+Redis+RBAC从零手写

做后端开发这几年，权限认证几乎是每个项目都绕不开的坎。登录、鉴权、Token 过期、接口防刷、角色权限……这些事看着简单，真做起来全是细节。Spring Security 功能全但配置复杂，Shiro 轻一些但文档老旧，很多中小型项目其实只需要把登录和权限控制做好，完全用不上那么重的体系。所以我整理了一套轻量级 Java 权限认证框架的完整源码，核心就三件事：登录发令牌、接口验令牌、注解控权限。这篇文章不是框架说明书，而是把我从零设计、手写、测试、踩坑的全过程都拆开讲一遍，想把权限这块搞清楚的朋友，不管你是刚转 Java 的新人，还是做了两三年的后端，大概率都能从中拿走一些能直接用的东西。

1. 为什么做这个轻量级 Java 权限认证框架

1.1 中小企业项目的真实痛点

先说需求来源。我接触过的很多项目，尤其是企业内部管理系统、外包交付项目、创业公司 MVP，它们对权限认证的要求其实非常朴素：用户登录后能拿到身份凭证，访问接口时能校验身份，部分敏感接口需要管理员或其他指定角色才能调。就这三板斧，撑起了 90% 的业务场景。

但真去落地的时候问题就来了。Spring Security 作为行业标配，功能确实强大，可它的过滤器链机制、SecurityContext 传递、多种认证提供者的抽象层次，对普通团队来说学习成本相当高。我见过一个团队引入 Spring Security 后，光是配置 SecurityFilterChain 就花了两天，最后因为没法从数据库动态加载权限，还是改回了代码里写死配置。项目周期短、人员流动快、业务变化频繁，这是中小企业项目的常态，重框架带来的复杂度往往比它解决的问题还多。

另一个选择是 Apache Shiro，它的侵入性比 Spring Security 小很多，Session 机制也直观，但 Shiro 主动维护的频率一般，跟 Spring Boot 新版本的集成时不常会遇到兼容问题。而且 Shiro 的注解权限校验默认走的是 AOP 代理，在自调用场景下容易失效，这个坑我后面会细讲。

我并不是说这些框架不好，而是想说明一个道理：技术选型要匹配业务规模和团队能力。当一个轻量级自研方案能把登录、鉴权、授权三件事控制在几百行代码内，而且源码完全掌握在自己手里时，对于大量 CRUD 型业务系统来说，这是比引入全家桶更务实的解法。

1.2 自研不是重复造轮子：轻量级方案的核心优势

有人可能会质疑，权限认证这种安全敏感的功能，自己写是不是容易写出漏洞？这个担心是合理的，但要看你怎么定义“自己写”。一个合格的轻量级方案不是把 AES、RSA、数字签名全玩一遍，那确实容易出事；而是站在成熟的加密库、成熟的协议规范之上，只做业务层的编排。

我这套框架依赖的核心组件就三个：JWT 做令牌载体，Redis 做会话存储，BCrypt 做密码散列。JWT 是一种开放标准，BCrypt 是公认安全的哈希算法，它们本身都是工业级产物，我要写的只是怎么把这三个东西串起来满足业务需求。这样一来，安全底子是由成熟方案保证的，框架层只处理“谁登录、持什么证、有什么权”这三个业务问题，复杂度自然降下来了。

轻量级的优势在真实项目里非常明显。首先是排障快，代码就那么多，出问题打开源码直接定位，不用在框架源码里翻来翻去；其次是改造灵活，比如要实现多端登录互踢、单设备登录、临时权限提升，在自定义框架里都是加几段逻辑的事，而在重框架里可能要研究半天扩展点；最后是启动优越，没有大量自动配置，Spring Boot 应用启动速度明显提升，这在微服务拆分的场景下很受用。

做一个轻量级框架最大的价值还不是省事，而是让你真正理解权限认证的底层原理。自己写过一遍拦截器、解析过一次 Token、设计过一回 RBAC 表结构，再去面试聊权限设计，“Java 八股文”里常考的单点登录、会话管理、无状态认证这些概念才能真正落地成自己的知识。

2. 框架的核心设计思路

2.1 模块划分：认证、会话、授权三件事分开

我设计这个框架时定了一个基本原则：认证、会话、授权三个职责必须拆开，不能揉成一坨。认证负责“你是谁”，会话负责“你这次登录持续多久”，授权负责“你能干什么”。这三个环节各自独立，才能保证框架的扩展性。

模块结构上分了四层。最底层是用户模型层，包含用户实体、角色、权限的数据结构，这一层对应数据库表设计；往上是认证服务层，负责处理登录请求、校验账号密码、生成令牌，这是登录入口的核心逻辑；再往上是访问控制层，由拦截器结合自定义注解完成接口的鉴权和授权；最外层是上下文层，通过 ThreadLocal 保存当前登录用户信息，方便业务代码随时取用。

这里有一个关键设计决定：授权信息不足时，框架是直接拒绝，还是交给业务方自己判断？我的方案是框架只做粗粒度的接口权限控制，也就是判断当前用户是否拥有访问某个接口所需的角色或权限码，而细粒度的数据权限（比如“只能查看自己创建的订单”）由业务代码通过 UserContext 获取当前用户 ID 后自行判断。这样既保证了通用性，又不会把框架做得太复杂。

2.2 Token 会话机制：JWT + Redis 双通道

会话管理是权限认证框架的核心，也是方案取舍最多的地方。常见的做法有两种：一种是无状态纯 JWT，服务端不保存会话，令牌自包含用户信息，校验时验签即可；另一种是全有状态 Session + Redis，用户信息存在服务端，客户端只拿一个随机 ID。

这两种方案各有硬伤。纯 JWT 的最大问题是无法主动失效。用户退出登录、修改密码、管理员封禁账号后，只要 JWT 没过期，理论上依然可以调用接口，这在安全要求稍微高一点的系统里是不能接受的。而纯 Session + Redis 的问题在于每次请求都要查一次 Redis，虽然加了连接池后性能损耗不大，但每次都把完整用户信息查出来放进内存，在权限列表很长的场景下是额外开销。

我的设计是两者结合：JWT 负责携带用户唯一标识和基础身份信息，Redis 负责存储会话动态状态。具体流程是这样：登录成功后生成两个东西，一个是 JWT 令牌（有效期设置为相对较短，比如 2 小时），一个是 Redis 中的会话记录（key 为 userId，value 为会话状态，比如是否被踢下线、退出标记）。每次请求校验时，拦截器先验 JWT 签名和有效期，然后再查 Redis 确认会话状态是否有效。

这个方案的好处在于，JWT 让鉴权过程无需访问数据库，性能损耗接近零；Redis 让会话不过期、强制下线、多端控制这类强需求变成可能；两者互补，各取所长。实际项目中我把 Redis 过期时间设置成比 JWT 有效期略长，比如 JWT 2 小时、Redis 7 天，配合双 Token 刷新机制就能实现长期免登录。

2.3 RBAC 权限模型与注解驱动机制

权限模型我直接用经典的 RBAC（基于角色的访问控制），用户关联角色、角色关联权限，三层结构。为什么不用更简单的用户直接关联权限？因为现实业务里权限的分配通常是按角色批量操作的，新来一个运营专员，应该一键继承“运营”角色下的全部权限，而不是一个个勾选接口权限。RBAC 真正解决的是一对多的授权管理效率问题。

权限的最小粒度我定义为权限码（Permission Code），比如“user:create”“order:delete”，一个接口对应一个权限码。角色持有权限码集合，用户通过角色间接获得权限。在数据库层面就是五张表：用户表、角色表、权限表、用户角色关联表、角色权限关联表。

框架对外暴露的编程接口是三个自定义注解。第一个是 @RequireLogin，标注这个接口需要登录才能访问；第二个是 @RequirePermission，标注这个接口需要指定权限码；第三个是 @IgnoreAuth，标注这个接口完全公开，比如登录接口、验证码接口。三个注解的设计逻辑很直接：代码里声明式地描述访问控制规则，框架底层统一执行。

有意思的是这三个注解放到方法上和放到类上含义不同。放在方法上只对该方法生效，放在类上则对类内所有方法默认生效，方法上的注解优先级高于类上的。这种“类级默认 + 方法级覆盖”的设计，可以很方便地给某类接口统一加一道鉴权，又不妨碍个别接口单独放开。

3. 从零手写核心代码

3.1 工程结构与依赖准备

先看工程结构。我用的是 Spring Boot 2.7 + Maven 多模块设计，但为了演示方便，这里展示的是单模块精简版，实际目录结构如下：

text复制com.tech.auth
├── annotation               // 自定义注解
│   ├── IgnoreAuth.java
│   ├── RequireLogin.java
│   └── RequirePermission.java
├── config                   // 配置类
│   └── WebMvcConfig.java
├── core                     // 核心逻辑
│   ├── JwtUtil.java
│   ├── LoginUser.java
│   ├── UserContext.java
│   └── BizException.java
├── interceptor              // 拦截器
│   └── AuthInterceptor.java
├── controller               // 登录入口
│   └── AuthController.java
└── mapper                   // 数据层
    ├── UserMapper.java
    └── PermissionMapper.java

Maven 依赖非常克制，核心就这几个：

xml复制<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-validation</artifactId>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-api</artifactId>
    <version>0.11.5</version>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-impl</artifactId>
    <version>0.11.5</version>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-jackson</artifactId>
    <version>0.11.5</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>  <!-- 仅用BCrypt，不用Security过滤链 -->
</dependency>

最后一个依赖容易引起误解，我说明一下。我引入 spring-boot-starter-security 只是为了使用它的 BCryptPasswordEncoder 类做密码散列，实际并不启动 Security 的过滤链，通过排除自动配置类避免干扰：

java复制@SpringBootApplication(exclude = {SecurityAutoConfiguration.class})
public class AuthApplication {
    public static void main(String[] args) {
        SpringApplication.run(AuthApplication.class, args);
    }
}

3.2 登录认证流程：从参数到令牌

登录流程是整个框架的入口，也是逻辑最集中、最容易出问题的地方。我按步骤把核心代码拆开讲。

第一步是接收参数并校验。用 Validation 注解做基础校验，防止空指针和恶意请求：

java复制public class LoginRequest {
    @NotBlank(message = "用户名不能为空")
    private String username;
    @NotBlank(message = "密码不能为空")
    private String password;
    // getter/setter 省略
}

第二步是查询用户并校验密码。这里两个细节要特别说明：一是用户不存在和密码错误的提示必须统一返回“用户名或密码错误”，防止通过接口爆破用户名；二是密码校验必须用 BCrypt 的 checkpw 方法，不能用简单的 equals 比较，因为库里存的是加盐哈希后的密文。

java复制public String login(LoginRequest req) {
    User user = userMapper.selectByUsername(req.getUsername());
    if (user == null || !BCryptPasswordEncoder.matches(req.getPassword(), user.getPassword())) {
        throw new BizException("用户名或密码错误");
    }
    if (user.getStatus() != 1) {
        throw new BizException("账号已被禁用");
    }
    // 生成JWT
    String token = JwtUtil.generateToken(user.getId(), user.getUsername());
    // 记录会话状态到Redis，用于控制强制下线等场景
    redisTemplate.opsForValue().set(
        "auth:session:" + user.getId(),
        "active",
        Duration.ofDays(7)
    );
    return token;
}

第三步是 JWT 的生成和解析。ttl 设置为 2 小时，密钥从配置中心读取，绝对不写死在代码里：

java复制public class JwtUtil {
    private static final SecretKey KEY = Keys.hmacShaKeyFor(
        "my-secret-key-must-be-at-least-256-bits-long".getBytes()
    );

    public static String generateToken(Long userId, String username) {
        long now = System.currentTimeMillis();
        return Jwts.builder()
                .setSubject(String.valueOf(userId))
                .claim("username", username)
                .setIssuedAt(new Date(now))
                .setExpiration(new Date(now + 2 * 60 * 60 * 1000))
                .signWith(KEY, SignatureAlgorithm.HS256)
                .compact();
    }

    public static Claims parseToken(String token) {
        return Jwts.parserBuilder()
                .setSigningKey(KEY)
                .build()
                .parseClaimsJws(token)
                .getBody();
    }
}

这里有个实战心得：JWT 的 secret key 必须足够长，HS256 算法要求至少 256 位，也就是 32 个字节。很多人直接在代码里写一串短字符串，启动时启动会报错，但即便不报错也要小心，短密钥很容易被暴力破解。

3.3 拦截器与注解权限校验：守护每个接口的门卫

框架的控制层入口是拦截器 AuthInterceptor，它实现了 Spring MVC 的 HandlerInterceptor 接口，在请求进入 Controller 之前做鉴权。核心逻辑是三层判断：先看接口是否标注了 @IgnoreAuth，如果是就直接放行；再看接口是否要求登录；最后检查是否需要特定权限码。

java复制public class AuthInterceptor implements HandlerInterceptor {
    @Resource
    private StringRedisTemplate stringRedisTemplate;
    @Resource
    private PermissionMapper permissionMapper;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        if (!(handler instanceof HandlerMethod handlerMethod)) {
            return true;  // 静态资源直接放行
        }
        // 1. 忽略认证的接口直接放行
        if (hasAnnotation(handlerMethod, IgnoreAuth.class)) {
            return true;
        }
        // 2. 提取并校验Token
        String token = resolveToken(request);
        if (token == null) {
            throw new BizException(401, "未登录或登录已过期");
        }
        Claims claims = JwtUtil.parseToken(token);
        Long userId = Long.valueOf(claims.getSubject());
        // 3. 校验Redis会话状态（支持强制下线）
        String sessionStatus = stringRedisTemplate.opsForValue().get("auth:session:" + userId);
        if (sessionStatus == null || "logout".equals(sessionStatus)) {
            throw new BizException(401, "会话已失效，请重新登录");
        }
        // 4. 构造登录用户上下文
        LoginUser loginUser = new LoginUser();
        loginUser.setUserId(userId);
        loginUser.setUsername(claims.get("username", String.class));
        UserContext.set(loginUser);
        // 5. 权限码校验
        if (hasAnnotation(handlerMethod, RequireLogin.class) || hasAnnotation(handlerMethod, RequirePermission.class)) {
            String permCode = getPermissionCode(handlerMethod);
            if (permCode != null) {
                List<String> perms = permissionMapper.selectPermsByUserId(userId);
                if (!perms.contains(permCode)) {
                    throw new BizException(403, "无权限访问");
                }
            }
        }
        return true;
    }
}

从代码里可以看到几个精心设计的地方。第一是 HandlerMethod 的判断，Spring Boot 里静态资源请求也可能进入拦截器，但它不是 HandlerMethod 类型，必须要放行，否则静态资源全会被拦截。第二是自定义异常处理，BizException 配合全局异常处理器可以优雅地返回 401 和 403 两种状态码，而不是直接抛一堆堆栈信息给前端。第三是 UserContext 的清理时机。

UserContext 的实现用的是 ThreadLocal，注意在请求结束后必须清理，不然线程池复用会导致用户数据串到别的请求里：

java复制public class UserContext {
    private static final ThreadLocal<LoginUser> HOLDER = new ThreadLocal<>();

    public static void set(LoginUser user) {
        HOLDER.set(user);
    }
    public static LoginUser get() {
        return HOLDER.get();
    }
    public static void clear() {
        HOLDER.remove();
    }
}

3.4 requirePermission 注解本体的实现

自定义注解这一节单独拿出来说，是因为它决定开发者的使用体验。三个注解用相同的套路实现，核心是 @Target 和 @Retention 两个元注解。

java复制@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface RequirePermission {
    String value();
}

@Target 设置注解可以用在方法上和类上，@Retention 设置为 RUNTIME 表示运行期可以通过反射读取。拦截器里通过 handlerMethod.getMethodAnnotation(RequirePermission.class) 读取方法级注解，找不到时再看 getBeanType().getAnnotation(RequirePermission.class) 去读类级注解。

这里有一个我在实际项目里踩过的坑：一些朋友会考虑用 Spring AOP 来做权限注解切面，而不是用拦截器。这种做法在控制器方法上工作正常，但如果同一个类里的 A 方法调用 B 方法（B 上有权限注解），AOP 代理默认不生效，注解直接被忽略，这是一个经典的自调用陷阱。而拦截器的执行点在 Spring MVC 分发链路的最前端，不涉及代理问题，所以这个框架选择拦截器作为切入点，这也是更稳妥的技术选型。

3.5 数据库表设计与初始化

RBAC 模型的表结构非常固定，这里贴出最核心的五张表。为了节省篇幅，字段做了精简，真实项目中可以增加创建时间、更新时间、逻辑删除标记等常规字段：

sql复制CREATE TABLE sys_user (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  username VARCHAR(64) NOT NULL UNIQUE,
  password VARCHAR(128) NOT NULL,
  status TINYINT DEFAULT 1 COMMENT '1正常 0禁用'
);

CREATE TABLE sys_role (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  role_code VARCHAR(64) NOT NULL UNIQUE
);

CREATE TABLE sys_permission (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  perm_code VARCHAR(128) NOT NULL UNIQUE
);

CREATE TABLE sys_user_role (
  user_id BIGINT NOT NULL,
  role_id BIGINT NOT NULL,
  PRIMARY KEY (user_id, role_id)
);

CREATE TABLE sys_role_permission (
  role_id BIGINT NOT NULL,
  permission_id BIGINT NOT NULL,
  PRIMARY KEY (role_id, permission_id)
);

权限检测的 SQL 是三层 join，业务不复杂，但要注意对 user_id 加索引，否则用户量大以后这条查询会成为瓶颈：

sql复制SELECT DISTINCT p.perm_code
FROM sys_permission p
JOIN sys_role_permission rp ON p.id = rp.permission_id
JOIN sys_user_role ur ON rp.role_id = ur.role_id
WHERE ur.user_id = #{userId}

我在压测时发现，这个 SQL 在百万级关联数据、user_id 有索引的前提下，单次查询耗时稳定在 5ms 以内。为了避免每次请求都查一次数据库，我在框架里加了一层本地缓存，用户权限列表缓存 60 秒，权限变更后主动清除缓存，这个优化建议读者根据自己的业务量来评估。

4. 接入项目与性能实测

4.1 三步完成框架接入

框架写好了，最终是要给业务方用的。我梳理了接入三步曲，保证任何新项目可以在 10 分钟内完成集成。

第一步是引入依赖并把上述代码复制到工程，或者把框架打成 starter 依赖统一管理。第二步是写一个 WebMvcConfigurer 注册拦截器，并配置放行路径：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Resource
    private AuthInterceptor authInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(authInterceptor)
                .addPathPatterns("/**")
                .excludePathPatterns("/api/auth/login", "/error");
    }
}

这里有一个关键点：我把放行资源放在拦截器层面做，而不是全部依赖 @IgnoreAuth 注解。像 /error、静态资源这两个路径，天然就不是业务接口，没必要进拦截器逻辑，提前排除可以减少无意义的 Token 解析。而业务上真正公开的接口，比如用户注册、获取公钥，则用 @IgnoreAuth 注解放在 Controller 方法上。两种方式分工明确，拦截错了也不至于混乱。

第三步就是往业务接口上加注解。需要登录就加 @RequireLogin，需要特定权限就加 @RequirePermission("user:create")，完全公开就加 @IgnoreAuth。三步之后，项目的接口访问控制就全部生效了。

4.2 压测数据与资源占用

光能跑通还不够，我得知道这套框架在压力下表现如何。用 JMeter 做了一组简单压测，环境是本机 MacBook Pro（8 核 i7，16G 内存），单实例 Spring Boot 服务，连接了本地 Redis，测试结果如下：

这组数据说明几个问题。BCrypt 的设计目标之一就是慢，每次校验约 100ms，所以登录接口的耗时明显高于普通接口，这是安全性和性能的权衡，不是代码有 bug。Token 校验因为只做了 JWT 签名解析和 Redis 查询，开销非常小，在 200 并发下都没成为瓶颈。最惊喜的是加了权限码本地缓存后，整体 QPS 反而比不查数据库的裸鉴权还高，说明权限查询对性能的影响基本可控。

资源占用方面，测试过程中 JVM 堆内存稳定在 400M 左右，GC 频率很低，Redis 的每秒请求数不超过 200，对于一个中小型项目来说完全是轻量级水平，部署一台 2C4G 的云服务器绰绰有余。

4.3 与其他框架的选型对照：适合自己的才是最好的

写到这里，有必要把各方案放在一起做一个横向对比，方便读者在技术选型时做判断。这张表我做了很多次内部方案评审，去掉了一家之言的偏好，尽量客观：

我的态度很鲜明：如果你的项目是金融、政企这种安全合规要求极高的系统，直接上 Spring Security 没问题，它有专门的社区和文档支撑；但如果只是内部管理系统、中小业务后端，轻量级自研方案完全够用，而且维护成本更低。技术选型没有绝对的对错，只有匹配不匹配。

5. 实战排查：常见问题与避坑清单

5.1 上线后最常见的五个问题

框架跑起来之后，应用方反馈的问题五花八门，但其实高度集中在几个典型场景。我把最常遇到的五个问题连同排查思路整理成了一张速查表：

其中 ThreadLocal 串号这个问题最隐蔽，也最危险。因为 Web 容器用的是线程池，一个线程处理完请求后会被归还池中，如果不清理，下一个请求复用时还能取到上一个用户的登录信息，轻则数据越权，重则用户间数据交叉污染。排查这类问题有一个经验：线上偶发、必现概率低、跟用户无关。一旦出现这种特征，优先怀疑 ThreadLocal 没清理。

5.2 几个从项目里带出来的安全细节

除了排查问题，还有一些安全上的细节，是常规文档不会写、但真实项目里必须要注意的。

第一是 JWT 密钥的存放位置。密钥一定要通过环境变量或配置中心注入，不能提交到 Git 仓库。我见过有人把密钥放在 application.yml 里随代码库一起提交，一旦仓库泄露，攻击者就可以自己伪造任何用户的 Token，整个认证体系形同虚设。密钥的定期轮换也值得纳入计划，虽然轮换会导致所有存量 Token 失效，但在安全敏感的场景下这个代价是值得的。

第二是登录接口要加防暴力破解措施。BCrypt 虽然慢，但攻击者如果无限次重放登录接口，单机也能打出每秒几十次的尝试量。我的方案是登录失败五次后，锁定该用户名对应的登录入口 15 分钟，并配合验证码机制，极大增加自动化攻击的成本。

第三是密码明文加密这个基本操作不该成为争议。用户注册时不存明文、登录时不比明文，全程用 BCrypt 的 encode 和 matches。有些朋友图省事用 MD5 或 SHA 做哈希，但这类摘要算法是快速计算的，攻击者可以用彩虹表快速撞库，安全性远不如自带 salt 的 BCrypt。

第四是 401 和 403 要严格区分。401 是未认证，说明用户没登录或登录已过期，前端收到后应该跳转登录页；403 是已认证但无权限，说明用户在系统里但没资格干这件事，前端应该提示“无权限访问”。这两个状态码一旦被混淆，整个前端交互就会变成一团乱麻。

5.3 我建议的源码扩展方向

如果你把这套框架的源码完全吃透了，我会建议你沿着下面几个方向做扩展，每一个都是真实业务的高频场景。

第一个是双 Token 刷新机制。目前 JWT 有效期只有 2 小时，到期后用户要重新登录，体验很差。可以引入 Refresh Token，把短效 Token 的过期时间缩到 30 分钟，长效 Refresh Token 存 Redis 有效期 7 天。当短效 Token 过期时，前端用 Refresh Token 换新 Token，用户全程无感知。

第二个是多端登录控制。通过在 Redis 会话里增加设备标识字段，可以实现单端登录互踢、两端同时在线、多端强制下线等策略。这个功能在 Spring Security 里配置相对复杂，但在我们自研的框架里就是在会话管理上多加一个版本号或设备码判断的事。

第三个是权限变更实时生效。目前权限列表有 60 秒本地缓存，如果权限管理后台修改了某个用户的角色，理论上要等缓存过期才生效。想要即时生效，可以让权限管理后台在修改后调用一个主动清缓存的接口，或者引入消息通知机制来广播缓存失效。

第四个是接口级限流。权限认证框架既然已经在拦截器层面承接了所有请求，顺手做接口限流非常自然，基于 Redis 的滑动窗口或者令牌桶算法都能实现。这算是这个框架的一个隐藏价值：认证不是目的，保护资源才是。

我个人最大的体会是，权限认证这种横切关注点，越早建立起完整认知，后面做任何业务系统都会顺手得多。写这套框架的过程，本质上就是把“登录、会话、授权”这三个抽象概念重新理解了一遍。你不需要每次都白手起家，但至少要有白手起家的能力，这样当项目需要轻量化交付时，你手里永远有一张可以打的牌。如果你的项目也经常被登录和权限折腾得焦头烂额，我建议花一个晚上把这套源码跑起来，改一改、拆一拆，一定会比直接复制粘贴一段登录代码收获大得多。