Spring Security上手踩坑实录：一个准后端新人的血泪总结

老板说加个AI

2026-01-03 16:42

阅读 4627

上周五晚上十点半，我瘫在工位上盯着IDEA里那堆红彤彤的报错，心里默念“再改不好就删库跑路”。这已经是这周第三次被Spring Security搞到怀疑人生了。作为一个普通一本CS专业的大四狗，虽然已经拿到了北京某中厂的offer，但入职前还得帮学校实验室维护一个内部管理系统——结果产品经理临时加了个需求：“要不加个登录功能吧？下周就要用。”

得，我寻思着，这不就是个简单的认证系统嘛？我平时写Python Flask项目时，用flask-login十分钟就能搞定。结果换成Java Spring Boot，光是看官方文档就头晕眼花。更别提面试官还总爱问：“说说Spring Security的核心原理？”——每次我都支支吾吾，只能背几句“过滤器链、AuthenticationManager”糊弄过去。

痛定思痛，我决定把这次折腾的过程写下来，既是给自己留个备忘，也给和我一样被Spring Security劝退的萌新兄弟们指条明路。

为啥不用Python？聊聊技术选型的现实考量

先说句题外话：我其实是个Python重度爱好者。日常刷LeetCode、写爬虫、搭小工具，基本都用Python。简洁、优雅、开发快，谁不爱？但这次为啥非得用Spring Boot？

原因很现实：公司技术栈锁定。
我们实验室这个系统，未来是要对接公司现有Java微服务生态的，数据库用的是Oracle（没错，就是那个让人又爱又恨的），中间件全是Spring Cloud全家桶。领导一句话：“统一技术栈，减少维护成本。” 得，Python再香也只能放一边。

但这也引出了一个经典的面试题：“在已有Java后端体系下，为什么还要引入Spring Security而不是自己实现一套认证逻辑？”

我一开始也觉得，不就是存个用户名密码，校验一下token嘛？自己写一个多干净！但真上手才发现，安全这东西，自己造轮子=埋雷。

自己写容易漏掉CSRF防护
密码加密方式可能不标准（比如直接MD5）
权限粒度控制写起来又臭又长
万一哪天要接入OAuth2，重构成本爆炸

而Spring Security虽然学习曲线陡峭，但人家是经过生产环境千锤百炼的，开箱即用的安全策略比我自己写的靠谱一万倍。

快速搭建：从“Hello World”到能跑通

废话不多说，直接上干货。我的目标很简单：实现一个基于JWT的无状态认证系统，支持用户名密码登录，返回token，后续请求带token鉴权。

第一步：依赖别乱加

很多教程一上来就让你加一堆starter，结果项目启动慢得像蜗牛。根据我的实践，最小必要依赖如下：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</td>
</tr>
<tr>
<td><code>io.jsonwebtoken:jjwt-api</code></td>
<td>JWT生成/解析</td>
</tr>
<tr>
<td><code>io.jsonwebtoken:jjwt-impl</code></td>
<td>JWT实现</td>
</tr>
<tr>
<td><code>io.jsonwebtoken:jjwt-jackson</code></td>
<td>JWT与Jackson集成</td>
</tr>
</tbody>
</table>

注意：**不要**直接加 `spring-boot-starter-web` 之外的其他安全相关starter，除非你真的需要LDAP、OAuth2等高级功能。不然启动日志里一堆你根本用不到的Filter，排查问题时头都大了。

### 第二步：核心配置 —— 别被WebSecurityConfigurerAdapter吓到

很多人一看到这个抽象类就懵了。其实它就是让你重写几个方法来自定义安全规则。我直接贴出我精简后的配置：

```java
@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .csrf().disable() // 前后端分离项目一般关掉CSRF
            .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) // 无状态
            .and()
            .authorizeHttpRequests(authz -> authz
                .requestMatchers("/auth/login").permitAll() // 登录接口放行
                .anyRequest().authenticated() // 其他都要认证
            )
            .addFilterBefore(jwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class);
        
        return http.build();
    }

    @Bean
    public JwtAuthenticationFilter jwtAuthenticationFilter() {
        return new JwtAuthenticationFilter();
    }
}

这里有几个关键点：

csrf().disable()：如果你是纯API服务（比如给Vue/React前端提供接口），可以关掉CSRF。但如果是传统表单提交，千万别关！
SessionCreationPolicy.STATELESS：告诉Spring别创建HttpSession，因为我们用JWT。
addFilterBefore：自定义的JWT过滤器要在UsernamePasswordAuthenticationFilter之前执行，这样才能在登录前就拦截带token的请求。

第三步：自定义JWT过滤器 —— 最容易翻车的地方

我在这里卡了整整两天。一开始我把token解析逻辑写在doFilter里，结果发现用户信息没塞进SecurityContext，导致后续的@PreAuthorize失效。

正确姿势是：在过滤器里完成认证，并把Authentication对象存入SecurityContextHolder。

public class JwtAuthenticationFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(HttpServletRequest request, 
                                   HttpServletResponse response,
                                   FilterChain filterChain) throws ServletException, IOException {
        String token = extractTokenFromHeader(request);
        if (token != null && !isTokenExpired(token)) {
            String username = extractUsername(token);
            // 这里应该从数据库查用户，我简化了
            UserDetails userDetails = new User(username, "", List.of());
            
            UsernamePasswordAuthenticationToken authToken = 
                new UsernamePasswordAuthenticationToken(
                    userDetails, null, userDetails.getAuthorities());
            authToken.setDetails(new WebAuthenticationDetailsSource().buildDetails(request));
            
            // 关键！把认证信息存入上下文
            SecurityContextHolder.getContext().setAuthentication(authToken);
        }
        filterChain.doFilter(request, response);
    }

    // ... 其他JWT解析方法
}

血泪教训：一定要调用 SecurityContextHolder.getContext().setAuthentication()！否则Spring Security压根不知道当前用户是谁。

踩过的坑：那些让我想砸键盘的瞬间

坑1：密码加密方式不匹配

登录接口死活返回401，debug发现PasswordEncoder默认是DelegatingPasswordEncoder，而我数据库里存的是BCrypt加密的密码。结果框架尝试用{bcrypt}前缀去匹配，但我的密码字段没加这个前缀。

解决方案：显式指定PasswordEncoder：

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

同时确保注册时也用同一个encoder加密：

String encodedPassword = passwordEncoder.encode(rawPassword);
user.setPassword(encodedPassword);

坑2：跨域请求被拦截

前端本地开发时（localhost:8080）调后端（localhost:8081），OPTIONS预检请求被Security拦了，返回403。

解决方法是在SecurityConfig里加上CORS配置：

@Bean
public CorsConfigurationSource corsConfigurationSource() {
    CorsConfiguration configuration = new CorsConfiguration();
    configuration.setAllowedOriginPatterns(List.of("*"));
    configuration.setAllowedMethods(List.of("*"));
    configuration.setAllowedHeaders(List.of("*"));
    configuration.setAllowCredentials(true);
    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    source.registerCorsConfiguration("/**", configuration);
    return source;
}

// 在filterChain里加上
http.cors().configurationSource(corsConfigurationSource());

坑3：异常处理不友好

默认情况下，认证失败会重定向到/login页面，但我们的API应该返回JSON错误。

自定义AuthenticationEntryPoint：

@Component
public class JwtAuthenticationEntryPoint implements AuthenticationEntryPoint {
    @Override
    public void commence(HttpServletRequest request, HttpServletResponse response,
                         AuthenticationException authException) throws IOException {
        response.setStatus(HttpStatus.UNAUTHORIZED.value());
        response.setContentType("application/json;charset=UTF-8");
        response.getWriter().write("{\"error\":\"Unauthorized\", \"message\":\"" + 
                                  authException.getMessage() + "\"}");
    }
}

然后在SecurityConfig里注册：

http.exceptionHandling()
    .authenticationEntryPoint(jwtAuthenticationEntryPoint);

性能与可维护性：一个注重代码整洁的强迫症视角

作为重度依赖ChatGPT辅助开发的人，我特别在意代码能不能让同事一眼看懂。Spring Security配置如果全堆在一个类里，后期维护就是噩梦。

我的解法：

拆分配置类：JwtConfig、SecurityConfig、WebSecurityConfig各司其职
自定义注解：比如@CurrentUser，直接注入当前用户对象
统一响应格式：所有接口返回Result<T>结构，避免前端处理各种奇怪的错误格式

另外，不要硬编码权限字符串！见过太多人写：

@PreAuthorize("hasRole('ADMIN')")

一旦角色名变了，全项目搜索替换？不如定义常量：

public class SecurityConstants {
    public static final String ROLE_ADMIN = "ROLE_ADMIN";
    public static final String ROLE_USER = "ROLE_USER";
}

然后：

@PreAuthorize("hasRole(@securityConstants.ROLE_ADMIN)")

（注意这里用了SpEL表达式引用bean）

和Python方案对比：没有银弹，只有权衡

为了验证自己的选择，我还用Flask+PyJWT快速搭了个对照组。结论如下：

维度	Spring Security (Java)	Flask-Login + PyJWT (Python)
开发速度	慢（配置复杂）	快（几行代码搞定）
安全性	高（内置多种防护）	中（需手动补全）
可扩展性	极强（企业级支持）	弱（适合中小型项目）
学习成本	高	低
团队协作	规范清晰	容易各写各的

所以，如果是创业公司MVP阶段，Python方案完胜；但一旦进入稳定迭代、多人协作、高安全要求的场景，Spring Security的前期投入是值得的。

写在最后：从被虐到真香

现在回看，Spring Security确实难，但它难在“全面”，而不是“故意刁难”。理解了Filter Chain、Authentication、Authorization这几个核心概念后，你会发现它的设计其实非常优雅。

上周系统上线后，测试同学反馈：“登录挺快，也没出现越权访问。” 我默默喝了口冰美式，心想：总算没在入职前搞出P0事故。

对了，听说下周要开始做RBAC权限模型了……救命！

如果你也在啃Spring Security，别慌。记住：每一个被Security折磨的夜晚，都是通往高级Java工程师的必经之路。毕竟，面试官下次再问“说说Spring Security原理”，你就可以微微一笑：“巧了，我刚踩完所有坑。”

标签:面试题后端PythonSpring Boot

最热最新

暂无评论

为你推荐

暂无相关推荐