企业官网建设流程全解析

1. 这不是又一篇“Hello World”式Security教程——为什么你学了三遍还是配不通过登录

Spring Security 是我带过的十多个 Spring Boot 项目里，被问得最多、改得最频繁、上线前夜加班最多的一个模块。不是因为它难，而是它太“聪明”——聪明到会默默拦截你根本没意识到的请求，聪明到把 401 和 403 当成日常问候，更聪明到在你删掉一行http.csrf().disable()后，整个登录表单突然变成 403 Forbidden，而控制台连个日志都不打。

我见过某高校实验室的 A 同学，照着三篇不同博客配置数据库认证，跑通了登录页，但每次输入正确账号密码，页面就原地刷新；也见过某公司后端组的 B 开发者，在生产环境切掉 H2 控制台后，发现/actuator/health突然 401，排查三天才发现 Security 默认把所有/actuator/**都拦了，而文档里那句 “Actuator endpoints are secured by default” 被他当成了免责声明，没当操作指南。

这篇内容不讲“什么是 Filter Chain”，不画“DelegatingFilterProxy 如何委托”，也不堆砌AuthenticationManagerBuilder的 API 列表。它只做四件事：

• 给出一个开箱即用、可直接粘贴进src/main/java目录下就能跑通数据库登录的最小可运行模板（含 UserDetailsService 实现、密码编码器配置、核心 HttpSecurity 规则）；
• 拆解这个模板里每一行代码背后的决策逻辑：为什么必须用BCryptPasswordEncoder？为什么formLogin().loginPage("/login")后必须.permitAll()？为什么sessionManagement().sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)是多数 Web 应用的合理选择？
• 列出我在五个真实项目中踩出的高频、隐蔽、文档不提但必现的坑，比如“用户名字段名不匹配导致永远提示密码错误”、“Thymeleaf 表单 CSRF token 缺失却无任何报错”、“自定义登录成功处理器里 redirect 不生效”；
• 最后，分享一套非线性、抗遗忘、能闭环验证的学习路径：不从源码开始，不从 UML 图入手，而是用“改一行 → 看现象 → 查日志 → 定边界”的方式，把 Security 变成你调试工具箱里最顺手的一把螺丝刀。

如果你正卡在“能显示登录页，但输完账号密码就 401”、“数据库查到了用户，但 Security 就是不认”、“加了@PreAuthorize("hasRole('ADMIN')")却始终跳不到方法体里”——那你不是学得慢，是缺一份从失败现场反推配置意图的实操地图。我们这就从第一行@EnableWebSecurity开始画。

2. 通用数据库认证模板：不是抄代码，是理解每行代码在和谁对话

这个模板是我从模拟项目 X 的第 7 个迭代中提炼出来的，它不追求功能完整（比如没集成 OAuth2、没做 Remember-Me），只确保三件事：① 用户名密码从 MySQL/PostgreSQL 查；② 密码用 BCrypt 加密存储与比对；③ 登录成功跳转到/home，失败留在/login?error。所有代码均可直接复制，无需修改包名或路径（假设你用的是 Spring Boot 2.7+ 或 3.x）。

2.1 核心配置类：SecurityConfig.java

@Configuration @EnableWebSecurity public class SecurityConfig { @Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(12); } @Bean public UserDetailsService userDetailsService(JdbcTemplate jdbcTemplate) { return username -> { String sql = "SELECT username, password, enabled FROM users WHERE username = ?"; try { Map<String, Object> row = jdbcTemplate.queryForMap(sql, username); String password = (String) row.get("password"); boolean enabled = (Boolean) row.get("enabled"); // 注意：这里必须返回 GrantedAuthority 列表，Security 用它判断权限 List<GrantedAuthority> authorities = Collections.singletonList(new SimpleGrantedAuthority("ROLE_USER")); return new org.springframework.security.core.userdetails.User( username, password, enabled, true, true, true, authorities ); } catch (EmptyResultDataAccessException e) { throw new UsernameNotFoundException("User not found: " + username); } }; } @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf(csrf -> csrf.disable()) // 开发阶段先关掉，后面再开 .authorizeHttpRequests(authz -> authz .requestMatchers("/login", "/css/**", "/js/**", "/images/**").permitAll() .requestMatchers("/admin/**").hasRole("ADMIN") .requestMatchers("/home", "/").authenticated() .anyRequest().authenticated() ) .formLogin(form -> form .loginPage("/login") .loginProcessingUrl("/login-process") // 注意：这是表单 POST 的 action 地址 .defaultSuccessUrl("/home", true) // true 表示总是重定向到 /home，不保留原始请求 .failureUrl("/login?error=true") .usernameParameter("username") // 表单里 input name="username" .passwordParameter("password") // 表单里 input name="password" .permitAll() ) .logout(logout -> logout .logoutUrl("/logout") .logoutSuccessUrl("/login?logout=true") .invalidateHttpSession(true) .deleteCookies("JSESSIONID") .permitAll() ) .sessionManagement(session -> session .sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED) .invalidSessionUrl("/login?invalid-session=true") ); return http.build(); } }

提示：这段代码里没有@Order、没有WebSecurityCustomizer、没有SecurityContextRepository，因为它们属于进阶场景。新手第一目标是让SELECT * FROM users跑通，而不是提前设计分布式 Session。

现在，我们逐行拆解它在和系统哪部分“对话”，以及为什么这样写：

2.1.1@EnableWebSecurity—— 不是开关，是注册入口

很多人以为加了这个注解就“启用 Security”，其实它真正的含义是：告诉 Spring 容器，“请把我下面定义的SecurityFilterChainbean 注册进全局 Filter 链，并接管所有 HTTP 请求的生命周期”。它不启动任何过滤器，只是触发注册动作。如果你删掉它，filterChain()方法依然会被执行，但返回的SecurityFilterChain对象永远不会被 Spring MVC 拦截到——就像写了份作战计划却没交给前线指挥官。

2.1.2passwordEncoder()—— 为什么是BCryptPasswordEncoder(12)？

BCrypt 是目前 Web 应用最主流的密码哈希算法，它的核心优势不是“不可逆”，而是故意慢。12是 log rounds 参数，代表加密时进行 2^12 ≈ 4096 次哈希迭代。这个值不是越大越好：

• 太小（如 4）：2^4=16 次迭代，现代 CPU 几微秒就能算完，暴力破解成本极低；
• 太大（如 16）：2^16=65536 次，单次登录验证可能耗时 300ms+，高并发下拖垮响应；
• 12是 Spring Security 官方推荐的平衡点，在 100~200ms 验证耗时内提供足够安全边际。

注意：数据库里存的密码必须是BCryptPasswordEncoder.encode("原始密码")生成的字符串，形如$2a$12$K8QZ...。如果直接存明文或 MD5，UserDetails返回的密码字段再长也没用——Security 会拿你传入的明文密码去 BCrypt 验证，必然失败。

2.1.3userDetailsService()—— 数据库查询的“翻译官”

这个 Bean 的本质是一个函数：String username → UserDetails。它不负责查库逻辑，只负责把查到的原始数据“翻译”成 Security 能懂的格式。关键点有三个：

1. 字段名必须严格匹配：SQL 里SELECT username, password, enabled，username和password字段名必须和User构造函数参数顺序一致。如果数据库里叫user_name或pwd，这里就要显式取值：row.get("user_name")；
2. enabled字段决定账户是否可用：它对应User构造函数第 3 个参数（accountNonExpired）、第 4 个（credentialsNonExpired）、第 5 个（accountNonLocked）的默认值。如果你的表里没有enabled字段，可以硬编码true，但强烈建议加一列，方便后台冻结账号；
3. GrantedAuthority是权限载体，不是角色名：new SimpleGrantedAuthority("ROLE_USER")中的"ROLE_USER"是一个字符串标识，Security 内部用它做hasRole("USER")匹配。你不能写成"user"，否则@PreAuthorize("hasRole('user')")会失效——因为hasRole()方法内部会自动给参数加"ROLE_"前缀。

2.1.4filterChain()—— HttpSecurity 是 DSL，不是配置文件

HttpSecurity是一个构建式 API（Builder Pattern），它的链式调用不是“设置属性”，而是向内部规则列表追加匹配条件与处理动作。比如：

• .requestMatchers("/login", "/css/**").permitAll()：意思是“当请求路径匹配/login或/css/xxx.css时，跳过所有认证检查，直接放行”；
• .requestMatchers("/admin/**").hasRole("ADMIN")：意思是“当请求路径匹配/admin/xxx时，要求当前用户必须拥有ROLE_ADMIN权限”；
• .anyRequest().authenticated()：这是兜底规则，放在最后，意思是“除了上面明确放行或限制的路径，其他所有请求都必须已登录”。

关键陷阱：规则顺序极其重要！如果你把.anyRequest().authenticated()放在.requestMatchers("/login").permitAll()前面，那么/login请求会先被anyRequest拦住，永远到不了permitAll。这就像交通灯，红灯（认证）必须在绿灯（放行）之后才有效。

2.1.5formLogin()—— 表单提交的“协议握手”

.formLogin()配置的不是“登录页面长什么样”，而是“当浏览器 POST 数据过来时，Security 怎么解析、校验、跳转”。其中：

• loginProcessingUrl("/login-process")是 Security 监听登录请求的 endpoint，必须和 HTML 表单的action属性完全一致。很多新手写成/login，结果表单提交后 Security 根本不处理，因为/login被permitAll()放行了，没进认证流程；
• usernameParameter("username")和passwordParameter("password")必须和表单<input name="username">的name属性一致。如果前端用了email作为用户名字段，这里就必须写"email"，否则 Security 从 request.getParameter("username") 拿不到值，永远提示“用户名为空”；
• defaultSuccessUrl("/home", true)的true参数是灵魂：它表示“无论用户原本想访问/admin/dashboard还是/profile，登录成功后一律重定向到/home”。如果设为false（默认），Security 会尝试跳转回原始请求（即/admin/dashboard），但如果该路径需要ROLE_ADMIN而用户只有ROLE_USER，就会陷入“登录 → 403 → 重新登录 → 403”的死循环。

3. 数据库建表与初始化：别让 DDL 成为第一个拦路虎

模板里userDetailsService()直接查users表，但没人告诉你这张表长什么样。很多教程直接甩一句“自己建个 users 表”，结果新手建了个id, name, pwd三字段表，跑起来永远UsernameNotFoundException。下面给出最小可行建表语句（MySQL 8.0+），并解释每个字段的不可替代性。

3.1 标准 users 表结构（含注释）

CREATE TABLE users ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录用户名，Security 默认用此字段', password VARCHAR(100) NOT NULL COMMENT 'BCrypt 加密后的密码，长度必须 >=60', enabled TINYINT(1) NOT NULL DEFAULT 1 COMMENT '1=启用，0=禁用，Security 用此判断 accountEnabled', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 插入测试数据（密码为 "123456" 的 BCrypt 加密结果） INSERT INTO users (username, password, enabled) VALUES ( 'testuser', '$2a$12$K8QZvXqY7jR9pLmNcVbWuOeFgH1iJkMnOpQrStUvWxYzA1bC2dE3fG4hI', 1 );

3.1.1 为什么password字段长度必须 ≥60？

BCrypt 加密后的字符串固定格式为：$2a$12$...（共 60 个字符）。如果你用VARCHAR(20)，MySQL 会自动截断，存进去的是$2a$12$K8QZvXqY7jR9pLmNcVbWuOeFgH1iJkMnOpQrStUvWxYzA1bC2dE3fG4hI的前 20 位，验证时自然失败。实测VARCHAR(100)是安全冗余值。

3.1.2 为什么username必须UNIQUE？

UserDetailsService.loadUserByUsername()方法契约要求：同一个 username 只能返回一个用户。如果数据库里有两条username='testuser'的记录，jdbcTemplate.queryForMap()会抛IncorrectResultSizeDataAccessException（查到多条），Security 捕获后转为AuthenticationServiceException，最终页面显示“Internal Server Error”，而不是“用户名重复”。

3.1.3 初始化脚本：用schema.sql+data.sql自动注入

Spring Boot 启动时会自动执行src/main/resources/schema.sql（建表）和data.sql（插数据）。把上面建表和插入语句分别存入这两个文件，就能保证每次启动应用时数据库都是干净可用的。注意：

• schema.sql在data.sql之前执行；
• 如果用的是 H2 内存数据库，加spring.h2.console.enabled=true可以在http://localhost:8080/h2-console直接查表验证；
• 如果用 MySQL，确保application.yml里spring.datasource.url正确指向你的数据库实例。

实操心得：我习惯在data.sql里插入三条测试数据：testuser（普通用户）、admin（管理员）、disabled（enabled=0，用于测试禁用账号逻辑）。这样后续测hasRole("ADMIN")和账号冻结功能时，不用反复改数据库。

4. 前端登录页与 Thymeleaf 集成：看不见的 CSRF 是最大静音杀手

Security 默认开启 CSRF（跨站请求伪造）防护，这意味着：所有非 GET 请求（如 POST 登录、DELETE 删除）都必须携带一个服务端生成的 token。而这个 token，必须由前端模板引擎（如 Thymeleaf）自动注入到表单里。很多新手页面能显示，但点击登录按钮毫无反应，控制台也没有报错——问题就出在这里。

4.1 标准 Thymeleaf 登录页（login.html）

<!DOCTYPE html> <html xmlns:th="http://www.thymeleaf.org"> <head> <title>Login</title> <link rel="stylesheet" th:href="@{/css/login.css}"> </head> <body> <div class="login-container"> <h2>Login</h2> <!-- 错误提示：Security 会在 /login?error 时设置 error 属性 --> <div th:if="${param.error}" class="alert alert-danger"> Invalid username or password. </div> <!-- 成功提示：/login?logout 时设置 logout 属性 --> <div th:if="${param.logout}" class="alert alert-success"> You have been logged out. </div> <form th:action="@{/login-process}" method="post"> <!-- 关键：CSRF token 必须存在，且 name="_csrf" --> <input type="hidden" name="_csrf" th:value="${_csrf.token}"/> <div class="form-group"> <label for="username">Username:</label> <input type="text" id="username" name="username" required /> </div> <div class="form-group"> <label for="password">Password:</label> <input type="password" id="password" name="password" required /> </div> <button type="submit">Sign In</button> </form> </div> </body> </html>

4.1.1th:action="@{/login-process}"—— 必须和后端loginProcessingUrl一致

这是表单提交的目标地址。如果后端配置了.loginProcessingUrl("/login-process")，这里就必须写@{/login-process}。写成@{/login}或/login都会导致 404 或 403。

4.1.2<input name="_csrf" th:value="${_csrf.token}"/>—— CSRF 的生命线

这是整个登录流程中最容易被忽略的一行。Security 在渲染/login页面时，会自动往 Model 里塞一个_csrf对象，其中token字段是随机生成的字符串。Thymeleaf 用${_csrf.token}把它注入到隐藏域。当表单 POST 时，Security 会检查请求里是否有_csrf参数，且值是否匹配服务端缓存的 token。

• 如果漏掉这行：POST 请求到达/login-process时，Security 发现没有_csrf，直接返回 403 Forbidden，浏览器控制台没有任何 JS 错误，Network 面板里能看到 403 响应，但页面就是不跳转、不报错；
• 如果name写错（如_csrt）：同上，403；
• 如果用th:field替代th:value：Thymeleaf 会尝试绑定到某个对象，报PropertyNotFoundException。

验证技巧：打开浏览器开发者工具，切换到 Network 面板，点击登录按钮，找到/login-process请求，点开看 Headers → Form Data，确认里面有_csrf=xxxxxx这一项。没有？那就是前端漏了。

4.1.3 错误提示的两种来源

• ${param.error}：来自 URL 参数/login?error=true，由 Security 自动添加，表示认证失败；
• ${param.logout}：来自/login?logout=true，表示登出成功。

这两者都不需要你在 Controller 里手动 setAttribute，Security 已经帮你做好了。如果你在 Controller 里写了model.addAttribute("error", true)，反而会造成混淆。

5. 学习过程中的五大高频坑：不是 Bug，是 Security 的“合理行为”

以下是我带新人、做 Code Review、线上救火时，遇到频率最高的五个问题。它们都不是框架 Bug，而是 Security 在严格执行设计契约时，暴露了开发者对“认证流程边界”的认知盲区。每个坑都附带现象、根因、验证方法、修复方案四步定位法。

5.1 坑一：登录成功后跳转到空白页或 404，而不是/home

现象：输入正确账号密码，页面一闪，URL 变成/home，但页面是白屏或 404。
根因：/home路径没有对应的 Controller 方法，或者该方法没加@ResponseBody/ 没配置视图解析器。Security 只负责跳转，不负责渲染页面。
验证方法：

1. 在浏览器直接访问http://localhost:8080/home，看是否 404；
2. 检查HomeController.java是否有@GetMapping("/home")方法；
3. 如果用 Thymeleaf，确认src/main/resources/templates/home.html文件存在。
   修复方案：

• 添加最简 Controller：

  @Controller public class HomeController { @GetMapping("/home") public String home() { return "home"; // 返回 templates/home.html } }

• 或者用@RestController返回 JSON：

  @RestController public class HomeController { @GetMapping("/home") public Map<String, String> home() { return Map.of("message", "Welcome!"); } }

5.2 坑二：用户名正确，密码正确，但始终提示“Invalid credentials”

现象：数据库查到了用户，UserDetails对象也构造成功，但登录失败。
根因：UserDetails.getPassword()返回的密码字符串，和用户输入的明文密码，经过PasswordEncoder.matches()比对后返回false。常见原因有：

• 数据库密码字段存的是明文（如"123456"），但passwordEncoder是BCryptPasswordEncoder；
• 数据库密码是 BCrypt 加密的，但加密时用了不同强度（如BCryptPasswordEncoder(10)存的，BCryptPasswordEncoder(12)读的）；
• UserDetails构造时，password参数传错了字段（如传了enabled值）。
  验证方法：

1. 在userDetailsService()里加日志：log.info("Loaded user: {}", user);，确认password字段值是$2a$12$...开头；
2. 手动用BCryptPasswordEncoder.matches("123456", "$2a$12$...")测试，看是否true。
   修复方案：

• 用BCryptPasswordEncoder.encode("123456")生成新密码，更新数据库；
• 确保passwordEncoder()Bean 和数据库加密时用的是同一强度。

5.3 坑三：@PreAuthorize("hasRole('ADMIN')")不生效，方法体直接执行

现象：访问/admin/dashboard，Controller 方法正常执行，没被拦截。
根因：@EnableMethodSecurity注解缺失，或@PreAuthorize注解所在类没被 Spring 管理（如用new AdminController()手动创建实例）。
验证方法：

1. 检查主类或配置类是否有@EnableMethodSecurity；
2. 在 Controller 类上加@Component或@RestController，确认它是 Spring Bean；
3. 在方法上加System.out.println("Before method")，看是否打印。
   修复方案：

• 在主配置类加@EnableMethodSecurity；
• 确保 Controller 是 Spring 托管的 Bean（不要new）；
• 检查spring-boot-starter-aop依赖是否引入（@PreAuthorize依赖 AOP）。

5.4 坑四：Thymeleaf 模板里sec:authorize="hasRole('ADMIN')"不显示内容

现象：管理员登录后，<div sec:authorize="hasRole('ADMIN')">Admin Panel</div>不渲染。
根因：Thymeleaf Security Dialect 未启用，或sec命名空间未声明。
验证方法：

1. 检查pom.xml是否有thymeleaf-extras-springsecurity6（Spring Boot 3.x）或thymeleaf-extras-springsecurity5（2.x）依赖；
2. 检查 HTML 头部是否有xmlns:sec="http://www.thymeleaf.org/extras/spring-security"。
   修复方案：

• 添加依赖：

  <dependency> <groupId>org.thymeleaf.extras</groupId> <artifactId>thymeleaf-extras-springsecurity6</artifactId> </dependency>

• 在 HTML 根标签加命名空间：<html xmlns:th="http://www.thymeleaf.org" xmlns:sec="http://www.thymeleaf.org/extras/spring-security">。

5.5 坑五：关闭 CSRF 后，/logout无法登出

现象：点击登出链接，URL 变成/logout，但用户仍处于登录状态。
根因：/logout默认是 POST 请求，关闭 CSRF 后，Security 仍要求 POST，但<a href="/logout">是 GET。
验证方法：

1. 点击登出链接，看 Network 面板里是 GET 还是 POST；
2. 检查logout()配置里是否指定了logoutUrl("/logout")。
   修复方案：

• 用表单提交登出：

  <form th:action="@{/logout}" method="post"> <input type="hidden" name="_csrf" th:value="${_csrf.token}"/> <button type="submit">Logout</button> </form>

• 或者配置logout()允许 GET：

  .logout(logout -> logout .logoutRequestMatcher(new AntPathRequestMatcher("/logout", "GET")) // ... 其他配置 )

6. 一条反直觉但高效的学习路径：从“破坏”开始，而非“搭建”

大多数教程教你怎么“搭”，但我发现最有效的入门方式是“拆”——用最小改动制造一个明确失败，然后看日志、查文档、定位边界。这套路径我在某跨平台系统项目中验证过，新人平均 3 天内能独立配置数据库认证，不再依赖 Stack Overflow。

6.1 第一步：先让它“坏”，再看它怎么“报”

新建一个空 Spring Boot 项目，只加spring-boot-starter-web和spring-boot-starter-security依赖。不写任何@Configuration，不加@EnableWebSecurity。启动后访问http://localhost:8080，你会看到一个默认的 Basic Auth 登录框，用户名是user，密码是控制台打印的随机字符串（形如Using generated security password: 7d8f...）。

目的：建立基线认知——Security 默认行为是什么？它拦截了什么？没拦截什么？

6.2 第二步：关掉默认登录页，强制走表单

在application.yml里加：

spring: security: user: name: "" # 清空默认用户名，触发 401

重启，访问/，页面变成纯白，Network 面板里/返回 401。这时你知道：Security 默认只放行/login（Basic Auth 的登录页），其他路径全拦。

6.3 第三步：加最简SecurityConfig，只开/login

写一个SecurityConfig，只包含@EnableWebSecurity和filterChain()，里面只写：

http.authorizeHttpRequests(authz -> authz .requestMatchers("/login").permitAll() .anyRequest().authenticated() );

启动，访问/login，页面显示 404（因为没login.html）。这时你知道：permitAll()只是放行路径，不提供页面。

6.4 第四步：加login.html，观察 CSRF 报错

放一个空的login.html到templates/，内容只有<h1>Login</h1>。访问/login，能显示。点击登录（随便输），Network 面板里/login-process返回 403。这时你知道：CSRF 生效了，但前端没传 token。

6.5 第五步：加_csrftoken，观察 404

在login.html里加<input name="_csrf" th:value="${_csrf.token}"/>，再试。这次/login-process返回 404。为什么？因为loginProcessingUrl默认是/login，但你的表单action是/login-process，而 Security 没配这个 URL。

6.6 第六步：配loginProcessingUrl，观察 401

在filterChain()里加.formLogin(form -> form.loginProcessingUrl("/login-process"))，再试。这次/login-process返回 401。为什么？因为UserDetailsService没配，Security 查不到用户。

6.7 第七步：配userDetailsService，观察密码错误

加一个返回固定UserDetails的userDetailsService()，密码写死"123456"。再试，提示“Invalid credentials”。为什么？因为passwordEncoder没配，Security 用默认NoOpPasswordEncoder（已废弃），但你的密码是明文，matches()失败。

6.8 第八步：配passwordEncoder，终于成功

加@Bean PasswordEncoder，用BCryptPasswordEncoder，数据库密码用encode("123456")更新。再试，登录成功，跳转/home。

这个路径的价值在于：每一步失败都有明确现象（401/403/404）、明确日志（控制台打印）、明确修复动作（加一行代码）。它把 Security 从一个“黑盒”变成一个“可调试的组件”，而调试的本质，就是控制变量、观察输出、反推逻辑。

7. 最后一点个人体会：Security 不是门锁，是门禁系统的设计说明书

我最初以为 Security 就是个“加个注解就能拦住非法访问”的工具，直到在某图像处理 Demo 里，为了支持 API Key 认证，不得不重写AuthenticationProvider，才明白：它真正的价值不是“防止未授权访问”，而是提供了一套标准化的、可插拔的、覆盖全链路的安全事件模型。

• Authentication是“你是谁”的声明；
• AuthenticationManager是“如何验证你是谁”的策略；
• SecurityContext是“当前请求的身份上下文”；
• AccessDecisionManager是“你有没有权限做这件事”的裁决者。

你不需要第一天就搞懂所有接口，但当你第一次手动实现UserDetailsService从数据库查用户，第一次在filterChain()里用requestMatchers()精确放行静态资源，第一次在 Controller 里用@PreAuthorize声明权限——你就已经不是在“用框架”，而是在“和框架对话”。

这个对话的过程，就是把“登录失败”从一个模糊的报错，变成“CSRF token 缺失”、“密码比对失败”、“角色权限不足”等可定位、可修复的具体问题。而这种能力，比记住一百个 API 更重要。

所以，别急着看源码，先把你手里的登录页跑通。跑通那一刻，你写的不是代码，是和 Security 的第一份契约。