Sping 复习

Fri, 20 Feb 2026 00:00:00 +0000

Spring Core

- Spring Core（IoC/DI/Bean 生命周期）
- 概述
- Spring 的核心是 IoC 容器，它负责把对象 Bean 的创建、依赖装配、生命周期管理、扩展点回调统一托管
- 写的业务对象只关心需要什么，不关心怎么 new、怎么组装、什么时候初始化/销毁
- SpringIOC = 依赖反转+容器管理对象生命周期
- DI = 容器把依赖注入进来（构造器/Setter/字段）
- Spring 强大来自于：大量可插拔的扩展点（PostProcessor、Aware、Event...）
- 核心概念与组件
- Bean、BeanDefinition、Container
- Bean：被 Spring 容器管理的对象实例
- BeanDefinition：Bean 的配方/说明书，包括
- beanClass 类
- scope (singleton/prototype/...)
- dependsOn、lazyInit、autowireCandidate...
- initMethods/destroyMethod
- 容器(Container)=读取 BeanDefinition->创建 Bean->注入依赖->生命周期回调
- BeanFactory vs ApplicationContext
- BeanFactory: 最底层的 IoC 容器接口，延迟实例化为主（按需 getBean 才撞见）
- ApplicationContext：更企业级，在 BeanFactory 上提供
- 资源加载
- 国际化
- 事件发布(ApplicationEventPublisher)
- AOP/事务等更完整的生态整合
- 通常启动时预实例化单例（非 lazy 的 singletone）
- 装配方式与注入策略
- 常见装配来源
- @Component + @ComponentScan：扫描注册
- @Configuration + @Bean：显式配置注册（配置复杂时使用）
- @Import：导入配置/Selector/Registrar（Boot 自动配置常用）
- XML（旧系统常用）
- 注入方式对比
- 构造器注入（推荐）
- 依赖不可变，对象更健壮
- 便于测试
- 早失败：缺依赖无法启动
- 循环依赖无法解决，早暴露设计问题
- Setter 注入
- 优点：可选依赖，可后置设置
- 缺点：对象可能处于半初始化状态
- 字段注入
- 难测试
- 破坏封装
- 易隐藏循环依赖与设计问题
- Bean 生命周期全链路
- 生命周期流程
- 解析配置 -> 注册 BeanDefinition
- 实例化：反射/构造器创建对象
- 属性填充：进行依赖注入
- Aware 回调
- BeanNameAware/BeanFactoryAware/ApplicationContextAware 等
- BeanPostProcessor#postProcessBeforeInitialization
- 初始化
- @PostConstructor
- InitializingBean#afterPropertiesSet
- 自定义 initMethod
- BeanPostProcessor#postProcessAfterInitialization
- AOP 代理通常在这生成（返回代理对象替代原对象）
- 容器运行期使用
- 容器关闭，销毁回调
- @PreDestroy
- DisposableBean#destroy
- 自定义 destroyMethod
- 超级扩展点
- BeanFactoryPostProcessor(更早、更底层)
- 作用对象：BeanDefinition
- 执行时机：Bean 实例化之前
- 典型用途：
- 修改 BeanDefinition
- 解析配置占位符
- BeanPostProcessor（最常用，最关键）
- 作用对象：Bean 实例
- 执行时机：初始化前后（before/after init）
- 典型用途
- AOP 代理创建
- 注解处理，例如 @Autowired 的处理
- 作用域与懒加载
- singleton vs prototype
- singleton：容器内单例，默认
- prototype：每次 getBean 创建一个新对象，容器只负责创建与注入，不负责销毁
- @Lazy
- 对 singleton：延迟到第一次使用才创建
- 大量 Bean 时可以缩短启动，但是首次请求会变慢
- 依赖解析与注入规则
- @Autowired 的匹配策略
- 先按类型找候选 Bean
- 如果有多个
- @Primary 优先
- @Qualifier("name") 指定
- 再不行：按照字段名/参数名尝试匹配
- 找不到：默认报错，可以用 required=false 或 Optional<T> 表示可选
- @Resource vs @Autowired
- @Resource：默认按 name，再按照 type
- @Autowired(spring)：默认按 type，可以配合 @Qualifier
- 循环依赖
- 什么是循环依赖
- A 依赖 B，B 依赖 A，常在字段/Setter 注入中
- Spring 为什么能解决部分循环依赖
- 依赖注入发生在实例化之后
- 容器允许暴露一个早期引用给对方注入，从而打破死循环
- 三级缓存
- 一级缓存：完整初始化好的单例 Bean
- 二级缓存：早期单例 Bean（半成本引用，可能是原对象，也可能是代理的早期引用）
- 三级缓存：ObjectFactory（工厂），用于需要时才创建早期引用，并且能让 AOP 有机会在早期阶段接入
- 典型场景
- A 依赖 B，B 依赖 A，流程用容器创建 A 为起点
- 触发创建 A
- 调用 getBean("A")
- 以及缓存没有 A，进入 createBean("A")
- 实例化 A（还没有注入依赖）
- Spring 先 instantiate （反射/构造器）得到 A 的空壳对象 A_raw
- 提前暴露
- 在进入属性注入之前，Spring 会做循环依赖防护的准备
- 向三级缓存放入 singletonFactories["A"] = ObjectFactory
- 这个 ObjectFactory 的职责是：别人需要 A 的早期引用时，能返回 A_raw 或 A_early_Proxy
- 此时，A 还没被放入二级缓存，只是放了一个可生产早期引用的工厂到三级缓存
- 给 A 做属性填充
- A 需要注入 B -> 容器去 getBean("B")
- 创建 B
- getBean("B") 缓存都没有 -> createBean("B")
- 实例化得到 B_raw
- 为 B 做提前暴露准备
- 开始 B 注入依赖
- B 注入 A（触发早期引用获取）
- B 需要 A -> 容器调用 getBean("A")
- A 仍然在创建中
- 一级缓存 singletonObjects：没有
- 但容器发现 A "currently in creation" 会拿走 getSingleton("A", allowEarlyReference=true) 的分支，尝试拿 earlyreference（给 AOP 留入口）
- 拿到 earlyRef 后，放入二级缓存，移除三级缓存，返回 earlyRef 给 B 注入
- A 完成初始化，进入一级缓存
- A 继续完成初始化回调链/BPP afterInitialization
- 为什么一定要三级
- 如果只有二级，无法优雅处理什么时候生成代理/早期暴露代理问题
- 三级缓存工厂，让 Spring 能够在真正需要注入时再决定暴露原对象还是代理对象
- 哪些循环依赖 Spring 解决不了
- 构造器注入的循环依赖：实例化阶段就互相需要对方，无法先构造空壳
- prototype 的循环依赖：每次创建都新对象，不走单例缓存那套
- @Configuration 为什么特殊（CGLIB 增强）
- 同一个 @Bean 方法调用两次
- 普通类写 @Bean 方法，直接调用方法会 new 两次
- 在 @Configuration 类中，Spring 会用 CGLIB 增强它
- @Bean 方法被拦截
- 如果容器里已有该 Bean，就返回容器里的单例，而不是再次执行方法创建

Spring AOP

- Spring AOP
- AOP 在 Spring 里解决什么问题
- 目标：把横切关注点从业务逻辑中剥离出来，日志，鉴权，事务，监控，限流，缓存，重试等
- Spring AOP 的定位：基于运行时代理，拦截方法调用，织入增强逻辑
- Spring AOP 只能对方法执行做增强
- 核心术语与对象模型
- Join Point/Pointcut/Advice/Aspect
- JoinPoint：可被拦截的位置。Spring AOP 里基本就是方法执行点。
- Pointcut：切点表达式，决定哪些 JoinPoint 被拦截。常见：execution/@annotation/within/this/target 等
- Advice：增强逻辑，要做什么
- Aspect：切面=Pointcut+Advice 的集合
- Advisor
- Advisor：把 Pointcut 和 Advice 打包成一个可应用单元
- Spring 内部处理的是 Advisor 列表，而不是直接处理注解切面
- 事务就是一个 Advisor
- @Aspect 最终会被解析成多个 Advisor，由容器在创建 Bean 时用这些 Advisor 决定是否生成代理以及代理链顺序
- 代理机制：JDK vs CGLIB
- JDK 动态代理
- 只能代理接口
- 通过 InvocationHandler 拦截接口方法调用
- 优点：标准 JDK 能力、生成快、类结构简单
- 缺点：无接口时不可用，对直接调用实现类方法这类场景不覆盖
- CGLIB 代理
- 通过生成目标类的子类并覆写方法拦截
- 适用于无接口的类
- final 类无法被继承 -> 不能代理
- final 方法、构造器逻辑、私有方法不能被增强
- Spring 如何选择代理方式
- 有接口优先 JDK，没接口用 CGLIB
- 强制开启 CGLIB @EnableAspectJAutoProxy(proxyTargetClass= true)/spring.aop.proxy-target-class=true
- Spring AOP 的工作流程
- Auto Proxy Creator
- AnnotationAwareAspectJAutoProxyCreator
- 本质是一个 BeanPostProcessor
- 介入时机：在 PostProcessAfterInitialization 决定是否为 Bean 创建代理
- 简化流程
- 容器启动：扫描到 @Aspect，解析成多个 Advisor
- 创建普通 BeanX 时
- AutoProxyCreator 收集可应用到 X 的 Advisor
- 如果存在匹配
- 创建代理对象 Proxy(X)
- 将 Advisor 转成 MethodInterceptor 链
- 返回 Proxy 替换原对象放入单例池
- 调用 X.method() 时
- 进入代理 -> 执行 interceptor chain -> 最后调用目标方法
- 切点表达式
- execution
- execution(访问修饰符 返回类型 包名.类名.方法名(参数))
- execution(* com.demo.service..*(..))：service 包以及子包所有方法
- execution(* *..*Service.*(..))：所有以 Service 结尾类的方法
- execution(public * *(..))：所有 public 方法
- 注解切点（工程最常见）
- @annotation(com.demo.Loggable)：方法上标注注解才拦截
- @within(...)：类上注解
- @target(...)：目标对象类型带注解（与代理类型可能有差异
- within/this/target
- within(TypePattern)：按声明类型匹配
- this(Type)：按代理对象类型匹配
- target(Type)：按目标对象类型匹配
- Advice 类型与执行顺序
- 五种 Advice
- @Before：目标方法前
- @After：finally（无论是否异常）
- @AfterReturning：正常返回后
- @AfterThrowing：抛异常后
- @Around：最强，包裹整个调用
- 一个调用的典型顺序
- Around（进入）
- Before
- method 执行
- AfterReturning/AfterThrowing (二选一)
- After
- Around 退出
- 多个切面怎么排序
- @Order 数字越小优先级越高（越外层，越先进入 Around）
- Ordered 接口同理
- 没有 order：可能按注册顺序
- 多个 Around 像洋葱圈，order 小的在最外层
- 代理链/拦截器链
- Spring 会把 Advisor 适配成一组 MethodInterceptor，形成链
- MethodInvocation.proceed() 是关键递归点
- 每个 interceptor 做一段逻辑，然后调用 process() 交给下一个
- 最后一个调用 invokeJoinPoint() 执行目标方法
- AOP 经典失效点
- 自调用失效（No proxy，no AOP）
- ![](https://an-img.oss-cn-hangzhou.aliyuncs.com/2026/02/21/20260221112533671.png,183,88)
- 调用 m1() 内部 m2() 是 this.m2()，不会经过代理 -> @Transactional/@Around 不生效
- 解决策略
- 拆分 Bean：把 m2 放到另一个 Spring Bean，通过注入调用
- 通过 AopContext.currentProxy()：获取当前代理再调用，需要 exposeProxy = true，侵入性强
- 注入自身代理
- 非 public 方法
- 直接 new 出来的对象没有 AOP

Spring Transaction

- Spring Transaction
- 定义：Spring 事务本质是 AOP 拦截方法调用，在方法执行前后通过 TransactionManager 控制开启/加入事务、提交/回滚、资源绑定/解绑
- 事务体系的关键对象
- PlatformTransactionManager：事务管理器抽象
- DataSourceTransactionManager
- JpaTransactionManager
- TransactionDefinition：事务定义（传播、隔离、超时、只读）
- TransactionStatus：事务状态（是否新建、是否完成、是否回滚标记等）
- TransactionSynchronzationManager：线程级资源管理
- Spring 事务是线程绑定资源，所以跨线程（异步）默认不会继承事务上下文
- @Transactional 做了什么
- 发生在 AOP 的哪个位置
- @Transactional 会被解析为一个 Advisor
- 方法调用进入代理后由 TransactionInterceptor 拦截
- 会读取事务属性，决定
- 加入已有事务还是新开事务
- 方法结束时 commit 还是 rollback
- 时序
- 进入代理方法
- TransactionInterceptor 读取事务属性
- getTransaction()：根据传播行为决定新开/挂起/加入
- 执行目标方法
- 正常返回 -> commit()
- 抛异常 -> 根据回滚规则 rollback() 或者 commit()
- 传播行为
- 方法 A 调用方法 B 时，事务边界怎么处理
- REQUIRED 默认
- 规则：有事务就加入，没有就新建
- 典型：大多数业务方法
- REQUIRES_NEW
- 规则：总是新建事务，若外部已有事务，则挂起外部事务
- 典型：记录操作日志/发送消息/保存审计记录
- NESTED
- 规则：在外层事务存在时，使用 Savepoint 实现部分回滚
- 外层回滚：内层也回滚
- 内层回滚：回到保存点，外层可继续
- SUPPORTS：有事务就加入，没有就非事务执行
- NOT_SUPPORTED：总是非事务执行；若有事务则挂起
- NEVER：如果存在事务则抛异常
- MANDATORY：必须在事务中运行，否则抛异常
- 隔离级别
- Read Uncommitted：可能脏读
- Read Committed：防脏读
- Repeatable Read：防不可重复读
- Serializable：最强，吞吐最差
- 回滚规则
- 默认规则
- 默认只对 RuntimeException 和 Error 回滚
- 受检异常默认不回滚
- 配置回滚规则
- @Transactional(rollbackFor=Exception.class)：受检异常也回滚
- noRollbackFor = XxxException.class：指定异常不回滚
- 事务提交/回滚的关键机制：线程绑定资源
- TransactionSynchronizedManager (TSM)
- 开启事务时
- 从 DataSource 取 Connection
- Connection.setAutoCommit(false)
- 把 Connection 绑定到当前线程(TSM)
- 同一线程后续 DAO 操作会复用这个 Connection
- 提交/回滚后
- commit/rollback
- 解绑资源，释放连接，恢复 autoCommit 等

Spring MVC

- SpringMVC(请求链路、参数绑定、异常处理)
- 总控思维模型
- Spring MVC 是一个基于 DispatcherServlet 的前端控制器框架，它把一次 HTTP 请求拆分
- 映射（找谁处理）-> 适配（怎么调用）-> 参数解析（怎么组装入参）-> 执行（调用 controller）-> 返回值处理（怎么写响应）-> 异常处理（失败怎么兜底）
- 核心入口是 DispatcherServlet#doDispatch：通过 HandlerMapping 找到 handler，再通过 HandlerAdapter 执行；执行前后分别由 ArgumentResolver 和 ReturnValueHandler 处理出参入参，异常交给 HandlerExceptionResolver 链
- 核心组件和职责
- DispatcherServlet（总入口）
- 接受请求
- 找 Handler（Controller 方法）
- 调 HandlerAdapter 执行
- 走视图解析/写回响应
- 捕获异常并交给异常解析器链
- HandlerMapping（找谁处理）
- RequestMappingHandlerMapping：处理 @RequestMapping/@GetMapping，它会维护映射表：URL+HTTP Method+consumers/produces+headers+params->HandlerMethod
- HandlerAdapter（怎么调用 Handler）
- RequestMappingHandlerAdapter：负责调用 @RequestMapping 方法
- 使用 HandlerMethodArgumentResolver 解析方法入参
- 使用 HandlerMethodReturnValueHandler 处理返回值
- ViewResolver（视图解析，前后端分离可选）
- 返回 String 视图名才需要（JSP/Thymeleaf）
- REST 场景通常直接 @ResponseBody/@RestController，通过 HttpMessageConverter 写响应
- HttpMessageConverter（对象<->报文）
- @RequestBody：把 JSON/XML/表单正文 -> Java 对象
- @ResponseBody：把 Java 对象 -> JSON/XML
- 常见 Jackson JSON converter
- 一次请求到完整链路
- 按 DispatcherServlet#doDispatch 的逻辑
- 接受请求（Servlet 容器调用 DiapatcherServlet#service）
- 拿 Handler：遍历 HandlerMapping，找到匹配的 Handler，通常是 HandlerMethod
- 拿 HandlerAdapter：选择能执行该 Handler 的适配器，通常是 RequestMappingHandlerAdapter
- 执行前置
- 绑定/转换：WebDataBinder（类型转换、校验）
- 参数解析：ArgumentResolver
- 拦截器 preHandler（HandlerInterceptor）
- 调用 Controller 方法
- 处理返回值
- REST：ReturnValueHandler -> HttpMessageConverter 写回 JSON
- 视图：返回 ModelAndView -> ViewResolver 渲染
- 执行后置：拦截器 postHandle/afterCompletion
- 异常处理：catch 异常 -> HandlerExceptionResolver 链处理->统一响应
- 请求映射匹配细节
- @RequestMapping 能参与匹配的额求
- path(含 Ant 风格、PathVariable)
- HTTP method (GET/POST/PUT/DELETE)
- params（必须带参数/参数值）
- headers （必须带 header）
- consumes（请求 content-type）
- produces（响应 Accept/Content-Type）
- 参数绑定
- 请求行/URL/Query/Form 类
- @PathVariable：从 URL 路径中取值
- @RequestParam：从 queryString 或表单中取值
- @RequestHeader：从 header 取值
- @CookieValue：从 cookie 取值
- HttpServletRequest/Response、Principal 等：直接注入
- 默认绑定
- 对简单类型：往往当做 @RequestParam
- 对复杂类型：走 @ModelAttribute 逻辑，把 query/form 参数按字段名绑定进去
- @RequestBody （正文序列化）
- 请求体 (JSON) 通过 HttpMessageConverter 反序列化成对象
- 常见错误
- Content-Type 不是 application/json
- 字段类型不匹配导致 HtppMessageNotReadableException
- 缺少无餐构造器/反序列化失败
- 类型转换与校验
- 类型转换链路
- ConversionService：负责类型转换
- Converter/Formatter：自定义转换规则
- 校验 JSR-303
- @Valid/@Validated
- 常见异常
- MethodArgumentNotValidException(@RequestBody + @Valid)
- BindException(@ModelAttribute 绑定错误)
- 配合 @ControllerAdvice 做统一错误响应
- 返回值处理
- 常见返回类型
- String：视图名
- ModelAndView：显式指定视图和模型
- ResponseEntity<T>：最推荐的 REST 返回方式之一，可控状态码/headers/body
- T + @ResponseBody：直接序列化成 JSON
- 返回值处理关键点
- @RestController = @Controller + @ResponseBody
- 选择哪个 converter 取决于
- 返回对象类型
- Accept 头
- produces 配置
- 异常处理体系
- HandlerExceptionResolver 链
- 按顺序尝试解析异常
- ExecptionHandlerExceptionResolver：处理 @ExceptionHandler/@ControllerAdvice
- ResponseStatusExceptionResolver：处理 @ResponseStatus
- DefaultHandlerExceptionResolver：处理框架内置异常
- @ControllerAdvice 正确用法
- 全局异常 -> 统一 error code + message + traceId
- 参数校验异常 -> 返回字段级错误列表
- 业务异常 -> 返回业务错误码
- 兜底异常 -> 返回 500 + 记录日志
- Filter vs Interceptor
- Filter（Servlet 规范）
- 发生在 Servlet 容器层面
- 能包裹整个请求响应链
- 用于：编码/CORS/鉴权/请求体包装/日志 traceId 注入
- Interceptor（Spring MVC）
- 发生在 Handler 执行前后，更靠近 Controller
- 包含三段内容
- preHandler（调用前）
- postHandler（方法返回后，视图渲染前）
- afterCompletion（整个请求完成后，用于清理资源/记录异常）
- Filter 是容器级，Interceptor 是框架级，能拿到 HandlerMethod，适合做与业务 Handler 相关的逻辑

Spring boot （自动配置、启动过程、外部化配置）

- Spring boot
- 解决了什么问题
- Boot 的核心价值是：约定优于配置+自动配置+Starter依赖聚合
- Starter：把一组常用的依赖按照场景打包
- Auto-Configuration：根据 classpath、bean、配置项等条件自动创建 Bean
- Externalized Configuration：同一的多来源配置体系
- Production-ready：Actuator、metrics、health、logging 等
- @SpringBootApplication 注解做了什么
- @SpringBootConfiguration 本质就是 @Configuration
- @ComponentScan 默认扫描启动类所在包及其子包
- @EnableAutoConfiguration：开启自动配置导入
- 自动配置原理
- 概述
- Boot 会在启动阶段把候选自动配置类加载进容器，但是不是无脑全开，而是通过大量的 @Conditional 做条件装配
- 类路径上有没有哪个类
- 容器里有没有某个 Bean
- 配置属性是否存在且满足
- 是否 Web 环境、是否 Servlet/Reactive
- 自动配置类从哪里来
- 自动配置类的来源本质是声明式列表，Boot 在启动时读取他们并导入
- Boot 在启动阶段通过自动配置导入机制读取 classpath 上各个 starter 提供的自动配置声明，然后把这些自动配置类作为配置类导入容器；最终每个自动配置类再通过 @Conditional 决定是否生效
- 条件注解
- @ConditionalOnClass(A.class)：classpath 有 A 才启动
- @ConditionalOnMissingBean(X.class)：容器里没有 X 才创建默认实现
- @ConditionalOnBean(Y.class)：必须已存在 Y 才启用
- @ConditionalOnProperty(prefix="a", name="b)
- @ConditionalOnWebApplication
- 自动配置覆盖/接管机制
- Boot 默认提供一个 Bean，例如某个 DataSource
- 只要自己定义同类型 Bean，通常由于自动配置里用了 @ConditionalOnMissingBean，默认不会创建
- 启动过程
- 启动过程的分段
- 构建 SpringApplication
- 推断应用类型：Servlet/Reactive/None
- 加载初始化器/监听器（Initializers/Listeners）
- 准备 Environment
- 读取配置源：application.yml、环境变量、命令行参数、profile 等
- 绑定 spring.* 相关关键属性（例如 banner、log、profiles）
- 创建 ApplicationContext
- Servlet Web：AnnotationConfigStyleWebServletApplicationContext
- Reactive Web：对于 reactive context
- 准备 Context
- 注册启动类
- 执行 ApplicationContextInitializer
- 刷新 Context
- 进入 Spring Core 经典流程
- 自动配置也在这一阶段被导入并参与 Bean 创建
- 启动 WebServer
- 发布 ApplicationReadyEvent
- 应用可以对外提供服务
- 外部化配置
- 配置来源
- application.properties/application.yml
- profile 文件：application-dev.yml
- 环境变量 ENV
- JVM 系统属性（-Dkey=value）
- 命令行参数(--key=value)
- 优先级
- 越靠近运行时/越具体的优先级越高
- 命令行/系统属性/环境变量高于配置文件
- profile 配置文件会在激活 profile 后叠加
- Boot 会把多来源配置汇总成 Environment 的 PropertySources，按优先级从高到低解析；同名 key 取最高优先级来源的值
- Profile
- 激活方式
- spring.profiles.active=dev
- --spring.profiles.active=dev
- 环境变量
- 生效规则
- application.yml 的默认块+application-dev.yml 覆盖叠加
- 配置绑定 @ConfigurationProperties
- 对比 @Value
- @Value：零散，难管理，不支持复杂层级/校验/IDE提示弱
- @ConfigurationProperties：可以把一个前缀下的配置绑定到一个对象，支持嵌套、集合、校验

数据访问整合

Spring Security

- Spring Security
- 核心概念
- SecurityContext：安全上下文，存当前请求/线程的认证信息
- Authentication：一次认证的结果对象
- principle：用户主体（UserDetail 或 userId）
- credentials：凭证（密码/token）
- authorities：权限集合（角色/权限点）
- authenticated：是否已认证
- SecurityContextHolder：存取 SecurityContext，默认 ThreadLocal
- 认证成功后，SecurityContextHolder 里面会有 Authentication，后续授权判断都基于它
- UserDetails 体系
- UserDetails：用户信息抽象（用户名、密码、权限、是否过期）
- UserDetailsService：按用户名加载用户
- PasswordEncoder：密码编码/校验
- 过滤器链：SecurityFilterChain
- 请求进入一堆 SecurityFilters 才会进入到 SpringMVC
- 认证机制
- AuthenticationManager/ProviderManager
- AuthenticationManager：认证入口
- 常用实现：ProviderManager 内部持有多个 AuthenticationProvider
- AuthenticationProvider：一种认证方式的具体实现
- 认证流程
- 过滤器拿到凭证，构造一个未认证的 Authentication
- 交给 AuthenticationManager
- ProviderManager 遍历 Providers，找到 supports 的 provider
- provider 校验成功 -> 返回已认证的 Authentication
- 写入 SecurityContexHolder
- 后续授权阶段使用
- 授权机制
- authorities/roles 的关系
- Spring Security 里面权限统一叫做 GrantedAuthority
- 角色以 ROLE_ 前缀表示
- hasRole("ADMIN") 等价于检查 authority ROLE_ADMIN
- hasAuthority("xxx:read") 检查精确权限点
- URL 级授权

Spring on 安橙的博客