登录注册大概是 Spring Boot 项目里被写烂、但也最容易写翻车的模块。常有人觉得，注册就是往用户表插一条记录，登录就是查一条记录再比对密码，听起来完全没有技术含量。可你真去做一个能上线的登录注册，会发现要处理的东西远不止这些：密码怎么存、用户名重复了怎么办、登录态怎么保持、退出登录之后 Session 要不要销毁、接口被脚本狂刷怎么办。这些边界问题，才是线上真正会出事故的地方。

这篇是 Spring Boot 实战系列的第四篇，我把用户登录与注册从需求拆解、表结构设计，到接口实现、测试和安全自查完整走一遍，最后再聊聊 Session 与 JWT 的取舍。方案上用手动管理 Session 的方式，而不是一上来就上 Spring Security 全家桶，目的是先把认证原理讲透。你后面再切到安全框架或者 JWT，至少清楚每一步在干什么。适合刚入门 Spring Boot、想认真把注册登录做成型的开发者，也适合已经能跑通简单 Demo、但不知道为什么线上会出各种奇怪问题的人。

1. 先别急着写接口：登录注册的需求拆解与安全底线

1.1 登录注册不只是“插一条、查一条”，还有这些隐性需求

从功能上看，登录注册确实不复杂。注册接口接收用户名和密码，往用户表里插一行；登录接口拿用户名密码查询，查到了就返回成功。但如果你照着这个思路直接开发，第一版大概率能跑，等上了线就开始到处漏风。

我把实际项目里会涉及的清单展开一下：

• 注册接口：用户名、密码、邮箱/手机号等资料的录入与校验
• 登录接口：身份确认与登录态建立
• 退出接口：登录态销毁
• 受保护接口：未登录的请求要被拦下来
• 账号状态：正常、禁用如何影响登录
• 唯一性：用户名、邮箱、手机号在系统内不能重复
• 密码策略：长度、复杂度，以及加密存储的方式
• 异常响应：参数非法、账号不存在、密码错误、账号禁用，分别返回什么
• 日志审计：注册时间、最近登录时间、被拦截的请求要不要记录

这里面，唯一性、密码策略、异常响应三块最容易糊弄。我评审过不少练习项目的代码，表面上功能都有，密码明文躺在数据库里、用户名没有唯一约束导致同名账号能注册成功、登录接口直接把参数拼进 SQL 的也不少见。这些问题本地自测不一定暴露，但每一个都是线上事故的种子。所以我不建议只按“插一条、查一条”来做，需求阶段就把这些隐性要求写清楚，编码时就按业务规则来落。

1.2 密码存储的底线：BCrypt 而不是 MD5

密码怎么存，是登录注册第一个要拍板的技术决策。最离谱的是明文存储，数据库一旦被拖走，所有账号等于集体脱库。稍微好一点的做法是用 MD5 或 SHA-256 做哈希，但这些算法的设计目标就是快，现代 GPU 每秒能算几亿次哈希，配合彩虹表，弱密码很快就能还原。

正确方向是使用慢哈希算法，比如 BCrypt。它的优势有三个：第一，每次计算会生成随机盐，同一个密码在不同用户身上得到的哈希值都不同，彩虹表基本失效；第二，计算速度刻意调慢，攻击者暴力破解的成本被大幅抬高；第三，成本因子可以随硬件升级调整，未来想加强不需要改存储格式。

Spring Security 的 spring-security-crypto 只提供了密码编码器，不需要拉进整套 Spring Security：

<dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-crypto</artifactId> </dependency>

配置一个 Bean 就行：

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

注册时 encode，登录时 matches。这里有个经验：不要在业务代码里到处 new BCryptPasswordEncoder，而是注入统一的 Bean。这样将来要换算法（比如升级到更高成本因子或者换 Argon2），只改一处配置就行。我在练习项目里一开始就到处 new，后来换参数时改了一堆文件，才体会到依赖注入的意义。

1.3 技术选型：为什么这次先手写 Session，不上 Spring Security

聊到登录认证，总会有人问：为什么不直接用 Spring Security，或者直接上 JWT？我的回答是：能用，但第一版不建议这么搞。

Spring Security 是个很优秀的框架，但学习曲线集中在过滤器链、认证管理器、用户详情服务那一整套抽象上。新手用它写登录注册，最常见的状态是：照着网上的配置抄一遍，能跑；一旦登录不进去，就搞不清是过滤器链顺序问题、密码编码器没对上，还是 CSRF 没关。排查过程相当劝退。

手动管理 Session 则完全不同。登录成功往 HttpSession 里写一个标记，拦截器在每次请求进来时检查这个标记，整条链路是可见的，你看到的每一步都是真实执行过程。把这一套基础弄明白，再去看 Spring Security 的过滤器链，或者转 JWT，会顺很多。这一篇的主线就定成 Session 方案，最后一节我会专门聊 Session 和 JWT 怎么取舍，以及切换时要动哪些代码。

2. 用户表设计与注册接口：从建表到第一个能用的接口

2.1 用户表设计：唯一约束和状态字段不能省

登录注册的核心表只有一张用户表。字段设计我倾向够用原则，别一上来堆十几个业务扩展字段，但下面这些必须有：

CREATE TABLE `user` ( `id` bigint NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录用户名', `password` varchar(100) NOT NULL COMMENT 'BCrypt哈希后的密码', `nickname` varchar(50) DEFAULT NULL COMMENT '昵称', `email` varchar(100) DEFAULT NULL COMMENT '邮箱', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `status` tinyint NOT NULL DEFAULT '1' COMMENT '账号状态 1正常 0禁用', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`), UNIQUE KEY `uk_email` (`email`), UNIQUE KEY `uk_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

我把关键字段的选型原因放张表里：

这里有几个细节值得单独说。第一，唯一约束必须做到数据库层，不能只在应用层判断。并发场景下，两个请求同时通过 existsByUsername 检查，然后同时 insert，没有数据库唯一索引兜底就会写入两条同名数据。第二，email 和 phone 的唯一索引，在 MySQL 里多个 NULL 是允许共存于普通唯一索引的，所以“可选但唯一”这个规则可以放心交给数据库。第三，password 列给到 100，BCrypt 当前产出的哈希是 60 个字符左右，未来成本因子调整可能变长，留足余量避免将来改表。

2.2 注册接口的完整实现：从实体到 Controller

持久层用 Spring Data JPA 做示例，用 MyBatis 的同学照着同样的 Service 逻辑写就可以了。实体类：

@Entity @Table(name = "user") public class User { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(nullable = false, unique = true, length = 50) private String username; @Column(nullable = false, length = 100) @JsonIgnore private String password; private String nickname; private String email; private String phone; private Integer status = 1; private LocalDateTime createdAt; private LocalDateTime updatedAt; // getter / setter 省略，实际开发用 Lombok 的 @Data 即可 }

User 实体有两个点容易踩坑。一是 password 字段必须加 @JsonIgnore，否则用户对象一旦被序列化返回前端，BCrypt 哈希也跟着泄漏，攻击者可以拿它离线跑字典。二是不要把 User 直接返回给前端，先转成 UserVO，只保留前端需要的 id、username、nickname 这类字段。

Repository 很薄：

public interface UserRepository extends JpaRepository<User, Long> { Optional<User> findByUsername(String username); boolean existsByUsername(String username); }

注册请求体用一个 DTO，加上校验注解：

public class RegisterRequest { @NotBlank(message = "用户名不能为空") @Size(min = 3, max = 20, message = "用户名长度需要在3到20个字符之间") private String username; @NotBlank(message = "密码不能为空") @Size(min = 6, max = 32, message = "密码长度需要在6到32个字符之间") private String password; @Email(message = "邮箱格式不正确") private String email; // getter / setter 省略 }

Service 是注册逻辑真正所在的地方：

@Service public class AuthService { private final UserRepository userRepository; private final PasswordEncoder passwordEncoder; public AuthService(UserRepository userRepository, PasswordEncoder passwordEncoder) { this.userRepository = userRepository; this.passwordEncoder = passwordEncoder; } public User register(RegisterRequest request) { String username = request.getUsername().trim(); if (userRepository.existsByUsername(username)) { throw new BusinessException("用户名已被注册"); } User user = new User(); user.setUsername(username); user.setPassword(passwordEncoder.encode(request.getPassword())); user.setEmail(request.getEmail()); user.setStatus(1); return userRepository.save(user); } }

Controller 只做接收和返回：

@RestController @RequestMapping("/api/auth") public class AuthController { private final AuthService authService; public AuthController(AuthService authService) { this.authService = authService; } @PostMapping("/register") public Result<UserVO> register(@RequestBody @Valid RegisterRequest request) { User user = authService.register(request); return Result.success(toVO(user)); } private UserVO toVO(User user) { UserVO vo = new UserVO(); vo.setId(user.getId()); vo.setUsername(user.getUsername()); vo.setNickname(user.getNickname()); return vo; } }

统一返回结构 Result 我建议每个项目都准备一份，别把裸对象直接丢出去：

public class Result<T> { private int code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.code = 200; result.message = "success"; result.data = data; return result; } public static <T> Result<T> failure(int code, String message) { Result<T> result = new Result<>(); result.code = code; result.message = message; return result; } // getter / setter 省略 }

到这里，最小可用的注册接口已经能跑通，接下来要处理的是校验和异常。

2.3 参数校验：脏数据比功能 bug 更隐蔽

加了校验注解之后，还得配一个全局异常处理，否则 Spring 会返回默认的 400 错误体，前端拿到一堆英文描述，很难看：

@RestControllerAdvice public class GlobalExceptionHandler { @ExceptionHandler(BusinessException.class) public Result<Void> handleBusinessException(BusinessException e) { return Result.failure(400, e.getMessage()); } @ExceptionHandler(MethodArgumentNotValidException.class) public Result<Void> handleValidationException(MethodArgumentNotValidException e) { String message = e.getBindingResult().getFieldErrors().stream() .map(FieldError::getDefaultMessage) .findFirst() .orElse("请求参数格式不正确"); return Result.failure(400, message); } }

BusinessException 就是普通运行时异常，靠 @RestControllerAdvice 统一捕获，Service 里不用到处 try-catch。

注解校验解决的是“格式对不对”，但有种脏数据是格式对、内容脏。比如用户名前后带着空格，前端看着两个名字差不多，注册出来却是两个账号；又或者用户复制粘贴时混进了不可见字符，第二次注册永远提示已存在，肉眼完全看不出原因。所以我在 Service 层总会先 trim 一次，把值规范化之后再做业务判断。这个习惯很小，但对线上数据的干净程度影响很大。

3. 登录认证：Session 的工作链路与退出登录的坑

3.1 登录接口：比对密码只是第一步

登录的 Service 逻辑看起来简单，但有三个判断不能少：

public User login(String username, String rawPassword) { User user = userRepository.findByUsername(username.trim()) .orElseThrow(() -> new BusinessException("用户名或密码错误")); if (user.getStatus() != 1) { throw new BusinessException("账号已被禁用"); } if (!passwordEncoder.matches(rawPassword, user.getPassword())) { throw new BusinessException("用户名或密码错误"); } return user; }

第一个细节：用户不存在和密码错误，返回同一个提示“用户名或密码错误”。如果提示“用户名不存在”，攻击者可以在你的登录接口上批量探测哪些用户名注册过，完成账号枚举。统一提示虽然没有彻底解决问题，但至少不会配合攻击者把信息喂到嘴边。

第二个细节：账号状态判断放在密码比对之前。禁用账号应该直接拒绝登录，而不是等密码比对过了再判断，不然逻辑顺序混乱，后面排查维护都麻烦。

第三个细节：密码比对用 matches 而不是把数据库里的哈希拿出来重新 encode 一次比较。BCrypt 每次 encode 生成的盐都不同，直接比较 encode 结果永远不会相等，这是一个很容易犯的错误。

登录的 Controller 要把用户写入 Session：

@PostMapping("/login") public Result<UserVO> login(@RequestBody @Valid LoginRequest request, HttpSession session) { User user = authService.login(request.getUsername(), request.getPassword()); session.setAttribute(AuthConstants.SESSION_USER_KEY, user.getId()); return Result.success(toVO(user)); }

我存的是 userId 而不是整个 User 对象，一方面是减少 Session 里的数据量，另一方面是业务上每次请求如果需要完整的用户信息，再按 id 查一次实时数据，避免拿到旧对象。极简单的系统也可以存 userId 加 username，够用就行。

3.2 登录态保持：Cookie、Session 与拦截器如何串起来

新手往往对“登录态”没有直观概念。实际上过程是这样的：浏览器第一次请求登录接口成功后，Servlet 容器会在服务端创建一个 HttpSession，并通过 Set-Cookie 把 JSESSIONID 种到浏览器；后续浏览器访问同一站点时，会自动带上这个 Cookie，服务器根据 session id 找到对应的 Session 对象，Session 里有没有登录标记，就决定了这次请求算不算已登录。

所以登录态本质上是客户端保存了一个 id，服务端保存了对应的状态数据。理解了这一点，拦截器就顺理成章：

@Component public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(false); if (session == null || session.getAttribute(AuthConstants.SESSION_USER_KEY) == null) { response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"message\":\"未登录或登录已过期\"}"); return false; } return true; } }

注意这里用的是 request.getSession(false)，传 false 表示如果没有 Session 就不要顺手创建一个。如果不加参数，每次未登录请求都会被迫新建一个 Session 对象，白占内存，这个细节对高并发下的稳定性有实际影响。

注册拦截器时，要把登录和注册接口排除掉：

@Configuration public class WebConfig implements WebMvcConfigurer { private final LoginInterceptor loginInterceptor; public WebConfig(LoginInterceptor loginInterceptor) { this.loginInterceptor = loginInterceptor; } @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor) .addPathPatterns("/api/**") .excludePathPatterns("/api/auth/login", "/api/auth/register"); } }

Session 超时时间可以单独配置，比如在 application.yml 里写 server.servlet.session.timeout=30m，默认是 30 分钟，按业务需要调整。登录接口写的属性存进去之后，到时间 Session 会自动失效，下一次请求就会被拦截器拦住，这个机制是容器帮我们做的，不用自己定时去清理。

3.3 退出登录的两种写法，差别很大

我看到过一种退出登录的写法：接口里什么都不做，直接返回“退出成功”，让前端跳回首页。问题在于服务端的 Session 还活着，登录标记还在，如果前端没有完成 Cookie 清理，或者请求是自动带 Cookie 的，用户实际上还处于登录态，只是页面看着像退出而已。

正确做法是销毁 Session：

@PostMapping("/logout") public Result<Void> logout(HttpSession session) { session.invalidate(); return Result.success(null); }

session.invalidate() 会把服务端的 Session 对象标记为失效，之后即使客户端继续带同一个 JSESSIONID，服务端也找不到对应的有效 Session，拦截器会把它当成未登录。从设计上说，退出登录不是让客户端“假性跳转”，而是真正废除服务端的认证状态。

这里还有一个建议：退出接口应该用 POST，而不是 GET。GET 请求可能被预取、被缓存、被第三方页面以图片形式触发，容易产生未预期的副作用，登录、退出这类会改变服务端状态的操作用 POST 更稳。

3.4 进阶小点：登录成功后最好更换 SessionID

如果你的系统会直面上公网，我建议了解一个叫“会话固定攻击”的概念。攻击者可以先自己跟服务器建立会话，拿到一个 JSESSIONID，然后诱导目标用户带着这个 id 去登录。如果服务端登录成功后不更换 session id，攻击者手里那个旧 id 就能复用来冒充已登录用户。

对策很简单：登录成功后调用 request.changeSessionId()，把会话 id 换成一个新的。这个操作不会丢 Session 里的数据，只是把钥匙换了，攻击者手上的旧钥匙就废了。Spring Security 默认就会在登录成功后执行类似操作，手写 Session 方案时容易漏，所以我把这个小点单拎出来。一行代码能挡掉一类攻击，性价比非常高。

4. 接口测试与安全自查：本地跑通只是开始

4.1 完整测试流程：注册、登录、访问受控接口、退出

代码写完之后，我习惯在接口测试工具里把完整流程跑一遍，而不是只测单个接口。下面这套用例基本是每个登录注册模块的标配：

1. POST /api/auth/register，提交一组合法数据，期望返回注册成功
2. 用同一个用户名再次注册，期望返回“用户名已被注册”
3. 不携带 Cookie 访问受保护接口，期望返回 401
4. POST /api/auth/login，提交正确密码，期望登录成功
5. 携带登录后返回的 Cookie 访问受保护接口，期望正常返回
6. POST /api/auth/logout，之后再用旧 Cookie 访问受保护接口，期望返回 401

整个过程里，最值得看的是第 5 步之前响应头里的 Set-Cookie。浏览器把 JSESSIONID 当成一个普通 Cookie 处理，所以在接口测试工具里要手动管理 Cookie，而浏览器开发者工具的 Network 面板可以直观看到请求自动带上的 Cookie，对理解登录态很有帮助。

如果有条件，再补一组边界用例：密码错误的登录、禁用账号的登录、非法参数注册。这些用例应该全部有对应断言，而不只是“能返回 JSON 就行”。

4.2 对线上有杀伤力的安全问题逐条过一遍

登录注册是攻击者重点关照的入口，本地跑通不代表安全，我习惯把下面这些问题整体过一遍：

SQL 注入这条，用 Spring Data JPA 时基本是安全的，因为方法名派生查询和 @Query 都走预编译参数；如果是 MyBatis，记得动态 SQL 里拼接字段排序这种场景也要避免直接使用 ${}。

CSRF 在接口测试工具里经常测不出来，因为工具不会像浏览器那样自动带 Cookie 去执行跨站请求。真正上线时，如果前端是服务端渲染的老项目，建议开启 CSRF Token 校验；如果是前后端分离且接口只服务自己的前端，至少要在网关或过滤器里校验 Origin/Referer，并把 Cookie 的 SameSite 属性设置好。

暴力破解这个点最容易在自测阶段被忽略。我见过只做了登录逻辑的项目，接口裸奔在公网上，密码没有失败次数限制。这种接口被脚本扫是迟早的事，哪怕密码是 BCrypt，弱口令依然会被试出来。所以从第一版就加一个简单的失败计数：同一个用户名或同一个 IP 连续失败五次，锁定五分钟，能挡掉大量脚本。

4.3 并发注册与重复提交：数据库约束比代码判断更可靠

我前面提过 existsByUsername 和 insert 之间存在竞态窗口。实际测试中，用两三个线程同时对一个未注册用户名发起注册请求，就有概率出现两条记录都通过检查、然后其中一条被数据库的唯一索引拦下，抛 DuplicateKeyException 的情况。

代码层面能做的防御是先查再插，但真正兜底的一定是数据库唯一索引。所以在代码里要把唯一索引冲突当成业务异常处理：

try { return userRepository.save(user); } catch (DataIntegrityViolationException e) { throw new BusinessException("用户名已被注册"); }

这样即便并发窗口没躲开，用户拿到的也是友好提示，而不是一整段堆栈。

重复提交是另一个常见问题。用户快速点了两次注册按钮，或者前端提交后没有及时禁用按钮，就会产生两个一样的请求。对注册这种幂等性要求不高、但重复会造成脏数据的接口，除了数据库约束，前端还可以做按钮防连点，后端也可以用一次性请求令牌来拦截重复提交。这个组合在多数场景下够用，不需要引入分布式锁。

5. Session 与 JWT 的取舍：什么时候该切换

5.1 JWT 解决的核心问题与它付出的代价

Session 方案在单体应用里很简单，但一旦系统变成前后端分离、多端接入、接口被多个第三方系统调用，Session 的短板就出来了：服务端必须保存会话状态，分布式部署后还得用 Redis 等中间件做 Session 共享，管理成本明显上升。

JWT 的选择是反过来：把认证信息本身交给客户端保存，服务端不存状态。一个 JWT 由 Header、Payload、Signature 三段组成，服务端只负责验签，签名通过且有效期内的 Token 就认定为合法用户。这个模型对横向扩展非常友好，新加一台服务节点不需要共享任何会话数据。

但 JWT 不是没有代价。最明显的三个问题：一是服务端无法主动让 Token 失效，退出登录只能靠客户端丢弃，Token 泄露后的有效期内会一直有效；二是 Token 体积通常比 Session id 大，每次请求都要带在 Header 里，请求头会变大；三是绑定黑名单、刷新策略这些逻辑都需要自己设计，不是开箱即用。所以我的态度一直是：JWT 是个好方案，但它解决的是 Session 在多端、多服务节点下的问题，而不是“更安全”的代名词。安全取决于签名算法、密钥管理和使用规范。

5.2 从 Session 切换到 JWT，需要动哪些代码

真要从 Session 切到 JWT，改动其实很集中。密码存储和比对逻辑完全不用动，因为用户认证的核心还是 BCrypt 那一套。

登录接口从“写 Session”改成“生成 Token 返回”：

// 示意写法，具体 API 以当前使用的 jjwt 版本文档为准 String token = Jwts.builder() .setSubject(String.valueOf(user.getId())) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 24 * 3600 * 1000)) .signWith(secretKey) .compact();

拦截器从“查 Session”改成“解析 Authorization 头里的 Token”。解析时先验签名、再查有效期，从 Payload 里取出 userId，再按业务需要去加载用户。这个逻辑在 HandlerInterceptor 的 preHandle 里实现，结构和 Session 版几乎一致。

退出接口变化最大。Session 版调 session.invalidate() 就行，JWT 版服务端没有 Session 可删，常规做法是客户端删除本地 Token。如果业务上要求“立刻失效”，就得维护一个 Token 黑名单，或者把 Token 的 jti、userId 存在 Redis 里做集中校验，这就等于把无状态方案又拉回有状态了，需要权衡。

5.3 我实际项目里的选择顺序

我个人对登录认证方案的排序大概是这样的：如果是初学阶段，先用 Session 把原理跑通，这个阶段比方案多，比效率重要；如果是单体应用、服务端渲染或者只有少量前端页面，Session 加拦截器已经足够，何必引入 Token 解析和密钥管理；如果是前后端分离、有移动端和第三方接入，再考虑 JWT；如果还有“管理员能踢人下线”“所有会话可集中查看”这类需求，Session 加 Redis 或者直接引入成熟安全框架更合适。

我也见过不少项目为了“技术栈好看”强行上 JWT，结果 Token 刷新、黑名单、密钥轮换全要自己维护，团队又不熟悉，出了问题排查更困难。认证方案的选择不是越新越好，而是看你的部署形态和运维能力能不能接住它的复杂度。先把 Session 这套吃透了，切换其他方案时你会非常清楚每个决策背后的代价。