Spring Boot 登录实战：BCrypt加密 + JWT鉴权 + 拦截器设计

做后端开发这些年，登录功能几乎成了每个Java项目绕不开的标配，但每次写都会有人踩坑。最近我在一个新的Spring Boot项目里又完整撸了一遍login流程，从密码加密、登录校验、Token生成到拦截器权限控制，再配合前后端联调，踩了好几个之前没遇到过的问题。索性把这套过程完整记录下来，从设计思路到具体代码，再到常见的失败场景排查，一次讲透。这篇内容适合刚上手Spring Boot的开发者，也适合写过登录但没有系统整理过的朋友。我用的版本是Spring Boot 2.7.18 + JDK 1.8，这个组合目前在生产环境里还是相当稳的，尤其很多公司还在JDK 8部署，照着做完全没问题。

1. 登录功能整体设计：核心思路与方案选型

1.1 需求拆解：登录不只是“验个密码”

登录功能乍一看很简单，无非是拿到用户名和密码，匹配上就通过，匹配不上就拒绝。但真到了实际项目里，要承接的问题远不止这些。第一个是登录入口，后台管理系统、手机App、小程序可能都要登录；第二个是会话保持，登录成功后用户再访问其他接口，系统得知道“你是谁”；第三个是接口管控，有的接口登录后才能调，有的接口必须匿名开放，比如登录接口本身、刷新Token的接口、注册接口；第四个是密码安全，数据库里不能存明文，传输过程中也不能裸奔。

这几条需求如果不在一开始想清楚，后面返工是必然的。之前我就见过一个项目，为了省事直接用HttpSession存用户信息，再用Filter做拦截。这种方案放在单体应用里确实跑得动，但一旦要适配移动端、小程序，或者走向前后端分离，Session那套就非常别扭。跨域环境下Cookie携带麻烦，分布式部署时Session共享又是一堆事，前端还得处理各种兼容。所以这次我干脆选择用JWT（JSON Web Token）做身份凭证，配合自定义拦截器做登录控制，从单体到微服务都能平滑过渡。

还有一个容易被忽略的点是权限扩展。登录做完之后，紧接着就是角色权限、按钮权限。如果一开始就把登录设计成可扩展的，后续加权限功能就很轻松；如果登录模块跟业务代码揉成一团，后面再想拆就难了。这也是我在设计方案时把用户身份、Token凭证、访问控制分开考虑的原因。

1.2 技术选型：Spring Boot + JWT + BCrypt，为什么不引全家桶

这次的技术栈整体是Spring Boot 2.7.18 + MyBatis-Plus 3.5.x + JJWT + Spring Security Crypto里的BCryptPasswordEncoder。先说BCrypt加密。很多初学者喜欢用MD5加盐，但MD5的运算速度太快了，GPU一秒钟能跑几亿次，加了固定盐也防不住撞库，一旦盐泄露就是全军覆没。BCrypt的底层是Blowfish算法，它刻意把加密过程设计得很慢，一次加密大概要几十毫秒，攻击者想靠穷举破解，成本会高很多。同时BCrypt会把随机生成的盐直接混进最终结果串里，我们不需要额外建一个字段存盐，这一点非常省事。

Spring Security Crypto这个库把BCrypt封装得相当好用，单独引进来用就行，没必要把整个Spring Security框架引入。因为Spring Security自带的那套登录过滤链其实很重，如果你只想用它的加密工具，却把整套安全管理引入，反而会干扰自己实现的登录逻辑，配置上也容易眼花缭乱。只加一个依赖，声明一个Bean就可以。

JWT这边我选了io.jsonwebtoken的jjwt 0.9.1版本。0.9.1是经典稳定版，资料多、问题好查，配合JDK 1.8没有任何兼容压力。JWT的核心思路就是服务端把用户身份信息、过期时间、签名一起打包成一个字符串，服务端不保存会话状态，客户端拿到之后每次请求带回来，服务端验签通过就信任它。这个无状态特性对水平扩容特别友好，不需要在多个节点之间同步Session。

但也要清楚，JWT本质上是签名而不是加密，它保证的是内容不被篡改，不是内容不可见。所以不要把密码、手机号、身份证这类敏感信息直接塞进Token里，Token中放userId、username这些非敏感标识就够了。我在设计的时候就牢记了这一点。

依赖配置如下：

xml复制<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt</artifactId>
    <version>0.9.1</version>
</dependency>
<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-crypto</artifactId>
</dependency>

第二个依赖我故意没写版本号，让Spring Boot的dependencyManagement帮我们管理版本，这样能避免和Boot的版本打架。

2. 数据库设计与密码加密落地

2.1 用户表设计：密码字段和状态字段不能少

登录功能涉及用户信息，表结构设计看着简单，但有几个字段不能省。先看一个可用的基础DDL：

sql复制CREATE TABLE `sys_user` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `username` varchar(64) NOT NULL COMMENT '用户名',
  `password` varchar(100) NOT NULL COMMENT 'BCrypt加密后的密码',
  `nickname` varchar(64) DEFAULT NULL COMMENT '昵称',
  `phone` varchar(20) DEFAULT NULL COMMENT '手机号',
  `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态：1启用 0禁用',
  `last_login_time` datetime DEFAULT NULL COMMENT '最后登录时间',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有个设计细节：password字段的长度设置成100而不是传统的64或32，是因为BCrypt加密后的字符串通常是60个字符左右，但考虑到未来算法升级可能生成的哈希更长，留够余量是稳妥的。username加上唯一索引，防止重复注册。

status字段很多人容易忽视，但它做账号禁用、停用非常有用。登录校验时判断一下status就能轻松实现“封号”操作，不用把用户记录删掉，这样也保留审计痕迹。last_login_time虽然看起来不过是一个时间字段，但运维排查用户活跃度时非常有用，登录成功后顺手更新一下。

2.2 BCrypt加密原理与配置

在Spring Boot里，先用一个配置类把PasswordEncoder声明成Bean：

java复制@Configuration
public class SecurityConfig {

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
}

这个默认的strength值是10，代表加密迭代次数是2的10次方，也就是1024次。这个值不是随便定的，它是安全性和性能之间的平衡点。如果你要处理的并发登录量非常大，每次加密都耗几十毫秒，对CPU也是一种压力，可以适当调成8；如果系统安全等级要求很高，也可以调成12，但登录耗时大概也会翻倍。我的建议是先从默认值开始，压测后根据实际数据再调整。

注册用户时加密密码很简单：

java复制String rawPassword = user.getPassword();
String encodedPassword = passwordEncoder.encode(rawPassword);
user.setPassword(encodedPassword);

这里必须提醒一个我踩过的坑：BCryptPasswordEncoder每次encode同一个明文，结果都是不一样的，因为它每次都会生成新的随机盐。如果你对同一个明文比较两次字符串是否相等，会发现它们完全不同，这是正常行为。校验的时候要用matches(rawPassword, encodedPassword)，这个方法会从存储的哈希串中解析出盐值，再用这个盐对明文重新计算哈希去比较。所以不需要保存固定的盐，也不需要纠结两次加密结果为什么不一样。

有些同学会把PasswordEncoder用new到处创建，这倒不是错误，但为了代码统一和方便测试，建议还是注入同一个Bean。真正致命的问题是有人在校验时拿存储的密文去encode，然后再和另一个密文compare，那永远匹配不上。

2.3 登录接口的逻辑实现

登录接口的Service实现是整个登录链路的核心，逻辑上分几步走。下面是去掉业务细节后的骨架代码：

java复制@Override
public LoginResponse login(LoginRequest request) {
    // 1. 根据用户名查询用户
    SysUser user = userMapper.selectOne(new LambdaQueryWrapper<SysUser>()
            .eq(SysUser::getUsername, request.getUsername()));
    if (user == null) {
        throw new BizException("用户名或密码错误");
    }

    // 2. 判断账号状态
    if (user.getStatus() == null || user.getStatus() != 1) {
        throw new BizException("账号已被禁用，请联系管理员");
    }

    // 3. 校验密码
    if (!passwordEncoder.matches(request.getPassword(), user.getPassword())) {
        throw new BizException("用户名或密码错误");
    }

    // 4. 生成JWT Token
    String token = jwtUtil.createToken(user.getId(), user.getUsername());

    // 5. 更新最后登录时间
    SysUser updateUser = new SysUser();
    updateUser.setId(user.getId());
    updateUser.setLastLoginTime(new Date());
    userMapper.updateById(updateUser);

    // 6. 返回结果
    return LoginResponse.builder()
            .token(token)
            .username(user.getUsername())
            .nickname(user.getNickname())
            .build();
}

这里有一个非常关键的安全设计：当用户不存在和密码错误时，我返回的都是“用户名或密码错误”，而不是分别提示“用户不存在”或“密码错误”。原因是避免恶意用户通过登录接口批量探测哪些用户名在系统里注册过。这个道理就像门锁不会告诉你“用户名错”还是“密码错”，只告诉你“身份验证失败”。虽然统一提示会让用户感受稍微差一点，但从安全角度完全值得。如果想排查，可以在后端日志里记录更详细的失败原因。

Controller部分也要注意，请求参数一定要用DTO接收，别直接用Map。用DTO可以配合javax.validation做参数校验，比如@NotBlank、@Length这些注解，参数不合法时直接抛异常，交给全局异常处理器统一返回，Service里就不用堆一堆if了。登录请求DTO大概是这样的：

java复制@Data
public class LoginRequest {

    @NotBlank(message = "用户名不能为空")
    private String username;

    @NotBlank(message = "密码不能为空")
    @Length(min = 6, max = 32, message = "密码长度必须在6到32位之间")
    private String password;
}

前端传过来的密码是明文，但这个明文指的是“传输到后端后”的明文，并不是说前端可以不加密直接传。在没有HTTPS的环境下，密码一旦在网络上被截获就泄露了，所以传输层上的安全是另一个必须考虑的点，后面我会专门展开讲。

3. 密码传输与JWT登录凭证的生成

3.1 传输层加密：HTTPS是底线，RSA是临时方案

很多项目做完BCrypt存储加密就觉得安全了，其实还有一个大漏洞：密码从浏览器传到后端的过程中是明文。如果走的是HTTP，中间人随便抓个包就能看到密码。BCrypt只保护了数据库里的密文，传输过程的裸奔它管不了。

最稳妥的解决方案就是上HTTPS，让整个通信链路走TLS加密，密码在传输过程中是密文，后端拿到之后再对BCrypt密文做校验。现在的云厂商申请免费SSL证书都很方便，这已经属于成本很低的安全投入了。

如果某些内网项目实在上不了HTTPS，临时方案是前端用RSA公钥对密码加密，后端用私钥解密后再进行BCrypt校验。但要注意，这种方案有两个坑：一个是RSA公钥是公开的，攻击者拿到公钥后可以伪装成前端，所以它只防被动窃听，防不了主动攻击；另一个是必须考虑重放攻击，同样的密文被截获后，攻击者直接原样重放也能登录成功。因此RSA方案还需要配合时间戳、随机数、一次性令牌才能做得比较安全。所以我的建议是：能用HTTPS就别绕弯子，直接上HTTPS，简单有效。

3.2 JWT结构解析与创建Token

JWT长成什么样呢？它是一串形如aaaa.bbbb.cccc的字符串，三个部分分别是Header、Payload、Signature。Header里记录算法和Token类型，Payload里存放用户相关数据，Signature是服务端用密钥对前两部分生成的签名。任何人对Payload内容做了改动，签名校验就会失败，这就是防篡改的机制。

创建Token的工具类可以这样写：

java复制@Component
public class JwtUtil {

    @Value("${jwt.secret}")
    private String secret;

    @Value("${jwt.expire}")
    private Long expire;

    public String createToken(Long userId, String username) {
        return Jwts.builder()
                .setSubject(username)
                .claim("userId", userId)
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + expire))
                .signWith(SignatureAlgorithm.HS256, secret)
                .compact();
    }

    public Claims parseToken(String token) {
        return Jwts.parser()
                .setSigningKey(secret)
                .parseClaimsJws(token)
                .getBody();
    }
}

配置文件里需要两个自定义属性：

properties复制jwt.secret=请改成至少32位的随机字符串
jwt.expire=7200000

jwt.secret千万别用默认的简单字符串。HS256是对称签名算法，密钥一旦泄露，任何人都能自己伪造合法Token。我建议在生成密钥时用随机字符，至少32位。生产环境里最好通过环境变量或配置中心注入，不要把真实密钥提交到代码仓库。jwt.expire我这里是2小时，也就是7200000毫秒，具体按业务场景调整。

Token过期时间是个需要权衡的参数。后台管理系统通常希望登录态别太频繁失效，我见过设1小时、2小时、4小时的，都有。移动端可能希望7天甚至更长。但过期时间越长，Token被盗后的风险窗口就越大。所以更稳健的做法是引入refreshToken机制，让accessToken短一点，比如30分钟，refreshToken长一点，比如7天，accessToken失效后前端用refreshToken换新的accessToken。refreshToken本身请求频率低，且可以通过服务端吊销来控制风险。这次项目业务相对简单，我先用了单Token，但把过期时间抽成了配置项，后面接refreshToken也不费劲。

3.3 Token中不放敏感信息，防止解析滥用

在使用JWT的时候，一定要克制往Token里塞数据的冲动。有人为了方便，把手机号、邮箱、昵称、头像地址全放进去，这是很危险的。因为JWT的Payload只是Base64Url编码，并没有加密，只要拿Token去解码，所有内容一目了然。一旦Token被截获，这些个人信息就全泄露了。Token里我建议只放userId和username这种必要身份标识，其他用户详情都通过userId再去数据库或缓存查即可。虽然多了一次查询，但数据安全性高很多。

4. 登录拦截器的设计与实现

4.1 拦截器核心逻辑：从请求头取Token并校验

登录状态判断需要放在进入Controller之前。很多人会纠结用Filter还是HandlerInterceptor，我的选择是HandlerInterceptor，因为它能拿到HandlerMethod，方便我们按方法注解做精细化控制，而且它本身也是Spring MVC的机制，和Controller配合更自然。

先定义一个登录拦截器核心逻辑：

java复制@Component
public class LoginInterceptor implements HandlerInterceptor {

    @Resource
    private JwtUtil jwtUtil;

    @Resource
    private ObjectMapper objectMapper;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 非HandlerMethod，比如静态资源，直接放行
        if (!(handler instanceof HandlerMethod)) {
            return true;
        }

        // 跨域预检请求直接放行
        if ("OPTIONS".equalsIgnoreCase(request.getMethod())) {
            return true;
        }

        HandlerMethod handlerMethod = (HandlerMethod) handler;

        // 判断是否标记为公开接口
        PublicApi publicApi = handlerMethod.getMethodAnnotation(PublicApi.class);
        if (publicApi == null) {
            publicApi = handlerMethod.getBeanType().getAnnotation(PublicApi.class);
        }
        if (publicApi != null) {
            return true;
        }

        // 获取Token
        String token = request.getHeader("Authorization");
        if (StringUtils.hasText(token) && token.startsWith("Bearer ")) {
            token = token.substring(7);
        }

        if (!StringUtils.hasText(token)) {
            return jsonResponse(response, 401, "未登录或登录已过期");
        }

        try {
            Claims claims = jwtUtil.parseToken(token);
            Long userId = claims.get("userId", Long.class);
            request.setAttribute("userId", userId);
            return true;
        } catch (JwtException | IllegalArgumentException e) {
            return jsonResponse(response, 401, "未登录或登录已过期");
        }
    }

    private boolean jsonResponse(HttpServletResponse response, int code, String message) throws Exception {
        response.setStatus(code);
        response.setContentType("application/json;charset=UTF-8");
        response.getWriter().write(objectMapper.writeValueAsString(
                Result.error(code, message)
        ));
        return false;
    }
}

这里有几个关键点。第一个是跨域预检请求。只要前端发的是带自定义请求头的POST请求，浏览器就会先发一个OPTIONS请求来探测服务端允不允许跨域。如果拦截器把OPTIONS请求拦了，前端会以为服务端不支持跨域，真正的登录请求根本发不出去。放行OPTIONS是最简单的处理方式，我每次写拦截器都会加上。

第二个是Token前缀兼容。很多前端习惯在Authorization里写Bearer xxxxx，这是标准做法，但也有一些前端直接写xxxxx。我在拦截器里做了兼容，如果发现Bearer前缀就去掉，这样前端不管怎么写都能正常工作。联调时不用为了这个前缀来回拉扯。

第三个是request.setAttribute传递用户信息。这一步很关键，后面Controller里通过request.getAttribute("userId")就能拿到当前登录用户，不需要再解析一次Token。

还需要创建@PublicApi注解：

java复制@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface PublicApi {
}

我用的是“默认拦截，标注放行”的策略。也就是说，Controller里所有接口默认都要登录才能访问，只有加了@PublicApi的接口才匿名开放。这比“默认放行，加@RequireLogin拦截”更安全，可以避免新同事忘写注解导致接口裸奔。一个登录系统最怕的就是漏了一个接口没做登录校验，默认拦截策略直接把这种风险压到最低。

4.2 控制器中获取当前登录用户

拦截器把userId塞进request之后，Controller里怎么取呢？最直接的方式是注入HttpServletRequest，然后调用getAttribute。但这个方法在代码里大量出现时，重复代码有点多。我更喜欢写一个UserContext工具类，利用ThreadLocal在登录时保存当前用户信息，请求结束时清理掉。不过ThreadLocal在使用中要注意清理，否则线程池复用线程时会串数据。因为后续请求都要经过拦截器，所以在afterCompletion方法里统一清除比较合适。

java复制public class UserContext {

    private static final ThreadLocal<Long> USER_ID_HOLDER = new ThreadLocal<>();

    public static void setUserId(Long userId) {
        USER_ID_HOLDER.set(userId);
    }

    public static Long getUserId() {
        return USER_ID_HOLDER.get();
    }

    public static void clear() {
        USER_ID_HOLDER.remove();
    }
}

在拦截器里设置：

java复制UserContext.setUserId(userId);

在afterCompletion方法里清除：

java复制@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
    UserContext.clear();
}

使用的时候就很方便了：

java复制Long currentUserId = UserContext.getUserId();

我个人更倾向用ThreadLocal这种传递方式，因为它不依赖方法签名，业务代码里拿当前用户非常顺手。但有一点必须注意：ThreadLocal一定要在请求结束时清理，否则Tomcat的线程池会复用线程，下一次请求很可能读到上一次登录用户的数据，这是一个非常隐蔽的bug。afterCompletion就是做清理工作的正确位置。

4.3 拦截器注册与路径排除

拦截器写好后，必须注册到Spring MVC中，否则不生效。注册配置类如下：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {

    @Resource
    private LoginInterceptor loginInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(loginInterceptor)
                .addPathPatterns("/**")
                .excludePathPatterns(
                        "/login",
                        "/register",
                        "/refreshToken",
                        "/doc.html",
                        "/webjars/**",
                        "/v2/api-docs",
                        "/swagger-resources/**"
                );
    }
}

既然拦截器里已经通过@PublicApi判断是否放行，这里的excludePathPatterns其实算是第二层保险。对于登录、注册这类肯定公开的接口，我习惯在注册时直接排除掉，这样即使注解漏写了也不会导致登录接口被拦截。两层都处理，稳一点。

配置类还有一个常见问题：如果WebMvcConfig所在的包不在Spring Boot主启动类的子包下，Spring扫描不到这个配置类，拦截器永远是失效状态。如果发现拦截器不生效，第一步就去检查包的扫描范围。

静态资源也要考虑到。如果项目里有上传图片、静态文件，通常要排除静态资源路径，或者依靠HandlerMethod判断直接放行。虽然静态资源请求不是HandlerMethod，我的拦截器已经放行了，但还是在excludePathPatterns里一并排除更清爽，也减少无谓的请求解析。

5. 登录过程常见问题与排查实录

5.1 启动失败：端口权限与套接字访问错误

这次开发中我们有个同事遇到一个特别迷惑的报错，日志里写着：

code复制failed to start login server: 以一种访问权限不允许的方式做了一个访问套接字

看到“failed to start login server”很多人第一时间以为是自己的登录接口写错了，其实完全不是。这个报错本质上是Spring Boot启动内嵌Tomcat时，端口绑定失败。通常发生在尝试监听特权端口（比如80端口）的时候，或者系统防火墙对端口访问做了限制。Windows下这个现象尤其明显，普通用户默认没有权限绑定某些端口。

解决办法也很简单：

• 换一个非特权端口启动，比如8080、8081、9090；
• 检查端口是否被其他进程占用，使用netstat -ano | findstr 端口号查看；
• 检查防火墙是否对外开放了该端口。

如果是部署到Linux服务器上，还需要确认当前用户是否有权限绑定该端口，以及SELinux是否限制了端口访问。这个问题跟登录业务逻辑一点关系没有，但很多人容易在这里卡住。

5.2 联调必踩的坑：Header名不一致与OPTIONS预检

前后端联调登录接口时，最常出现的问题就是Header名不一致。接口文档里写的是Authorization，前端代码里却写成了token；或者前端加了Bearer前缀，后端没兼容。这种问题几乎每个项目都会碰到，我的解决方式是后端尽量兼容多种写法，但前端也要统一封装。如果在请求工具里统一拦截，给每个请求自动附上Authorization头，就不会出现漏传Token的情况了。

还有一个很典型的现象是：登录接口等后端接口明明没问题，但前端浏览器一调用就报CORS错误，而且Network面板里能看到一个OPTIONS请求的状态是401。这就是浏览器在正式POST之前发送的预检请求被拦截器拦住了。因为预检请求不会携带自定义业务Header，Token当然也没有，拦截器一看没有Token直接返回401，浏览器认为服务端不允许跨域访问，于是后续真实请求被浏览器直接终止。我在拦截器里放行OPTIONS请求之后，这个问题立刻消失了。

5.3 密码校验失败与签名过期常见问题速查

我把登录模块常见的异常整理成一张速查表，排查时可以直接对照：

这里特别说一下时间问题。JWT的过期校验依赖服务器时间，我自己碰到过测试环境服务器时间错了几个小时，导致Token一生成就“已过期”，排查到最后才发现是系统时间被改错了。所以遇到签名或过期问题，先看一眼服务器时间准不准，往往能省很多事。

5.4 关于日志与敏感信息脱敏

登录模块一定要管住日志。我见过有同事为了排查问题，直接在log里打印整个请求对象，如果这个对象里包含密码字段，密码就跟着进日志系统了。日志系统如果被拖库，密码就泄露了。

在代码评审时，我定了一条硬性规则：任何日志都不允许打印password、secret、token这些敏感字段。如果确实需要排查，只记录用户名、用户ID、IP、失败原因这类信息。对于登录异常，可以记录详细的错误原因到日志里，方便运维定位，但返回给前端的提示要模糊统一。

另外，前端返回信息也不能把异常栈直接暴露出去。全局异常处理器应该对BizException返回友好提示，对其他未知异常返回“系统繁忙”，并记录完整异常堆栈到日志。这是登录接口的基本安全底线。

6. 可扩展方向与个人经验总结

6.1 登录模块还能怎么扩展

登录功能做成上面的形态，已经能支撑绝大多数业务系统了。但如果项目规模再大一点，有几点扩展方向值得提前留好接口。

第一是验证码。现在公网环境下的系统几乎都要接验证码，图形验证码、滑块验证码、短信验证码都行。可以在登录逻辑里插入一个验证码校验步骤，前端先请求验证码接口获取一个标识和图片，提交登录时把标识和用户输入的内容一起传过来，后端校验通过再继续走密码校验。

第二是登录失败次数限制。接口如果完全放开，攻击者可以无限尝试密码。最简单的方案是用Redis记录每个用户名或IP的失败次数，超过5次锁定一段时间。这比直接封IP要细粒度得多，也更容易落地。

第三是并发登录控制。有些系统要求一个账号只能在一个地方登录，或者限制同时在线设备数量。可以在Redis里存一份userId到Token的映射，登录时校验当前用户已有的Token数量，超过限制就把最早的Token拉黑。JWT本身是无状态的，拉黑操作需要借助Redis在拦截器里额外校验。虽然这会让登录有一点状态，但对业务来说往往是有必要的。

第四是RefreshToken机制。前面提过，单Token过期时间设长了怕泄露，设短了又频繁登录。搞一个刷新Token链路，accessToken短一点，refreshToken长一点，前端在收到401时主动走刷新流程。这个方案在前后端分离的项目里非常常见，也是登录模块从可用走向好用的重要一步。

6.2 团队协作中的规范建议

登录功能通常不是一个人开发完就结束了，后续会有人不断修改。我在团队里会做几件事来减少协作摩擦。

第一，把登录相关的接口文档写清楚，特别是请求头字段名的约定。前后端应该统一使用Authorization: Bearer 这种标准格式，避免各写各的。

第二，把密钥和配置信息从代码里剥离。本地开发可以用默认配置，但生产环境一定通过环境变量注入。很多安全隐患不是代码写得多复杂，而是配置管理太随意。数据库密码、JWT密钥、第三方接口key都属于敏感配置，不要直接写进application.properties后提交到仓库。

第三，制定接口安全清单。每次新增接口时，检查这个接口要不要登录，要不要做权限控制，参数校验是否完整，日志是否有敏感信息。这套清单在代码评审时非常管用，能挡住不少低级问题。

6.3 我最后的实操体会

把springboot-login这整套流程写下来，也算是给自己的一次总结。登录功能虽然每个项目都在做，但每次写都能带来一些新认识。比如BCrypt和MD5的区别，以前只是听过理论，真正把两者对比测试后才能直观感受到计算耗时的差距；比如OPTIONS预检拦截，只有踩过跨域的坑才知道提前放行有多重要。

我最想强调的一点是：登录拦截逻辑一定要简单清晰，让别人一看就懂。登录属于基础安全模块，如果代码写得绕来绕去，后面接手的人稍有不慎就会留下安全隐患。哪怕多写几行代码，也要把“默认拦截、显式放行”这个原则贯彻到底。

如果你也正在开发Spring Boot登录功能，希望这篇完整的全过程记录能帮你少踩几个坑。我在实际项目里用到的方案不一定是最新最炫的，但绝对是最稳、最容易上手的。等后面项目升级，我大概率会再加一层Redis来强化会话控制，到时候再分享新的经验。