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 表示可选
      • @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）
        • 调用 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：最推荐的 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：可以把一个前缀下的配置绑定到一个对象，支持嵌套、集合、校验

数据访问整合

  • 数据访问整合
    • 通用底座
      • DataSource：连接的来源
        • DataSource 是连接池的抽象
        • Spring 从 DataSource 拿 Connection，但事务期间会把 Connection 绑定到线程，避免每次 DAO 都新拿连接
      • 事务贯穿的关键：TransactionSynchronizationManager(TSM)
        • 开启事务时：取连接->setAutoCommit(false)->bind 到线程
        • DAO 执行时：通过 Spring 提供的工具从线程拿到同一连接
        • 提交/回滚后：解绑并释放连接
      • 同一异常体系：DataAccessException
        • Spring 会把各类底层异常统一成 DataAccessException 体系
        • 屏蔽不同驱动/框架的异常差异
        • 让事务默认回滚更符合直觉
    • JDBC: JdbcTemplate
      • JdbcTemplate 的价值
        • 封装样板代码：拿连接、创建 statement、执行、关闭资源、异常翻译
        • 与 Spring 事务自然融合：事务内复用同一连接
    • MyBatis 与 Spring 集成
      • MyBatis 的核心对象
        • SqlSessionFactory：会话工厂
        • SqlSession：一次会话（执行 SQL 的入口）
        • Mapper：接口代理，最终通过 SqlSession 执行
        • Executor：执行器（缓存、批处理等）
      • Spring-MyBatis 如何整合
        • Spring 提供 SqlSessionTemplate
        • 在事务中，通过 Spring 的事务同步机制把 SqlSession 与当前事务绑定
        • 事务提交/回滚时，SqlSession 会随着事务一起 commit/rollback
      • Mapper 扫描与处理
        • @MapperScan 会注册 Mapper 接口代理 Bean
        • 调用 Mapper 方法 -> 代理 -> SqlSessionTemplate -> 执行 SQL

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 级授权