上方那一排：都是”横切”进业务里的能力#

IOC、DI、AOP、事务管理、全局异常处理排在三层上方，这个位置很有意思——它们不属于某一层，而是横切在层与层之间：Controller 里要能拿到 Service 对象（DI 注入），Service 的方法上要能开启事务（事务管理），所有方法外要能包一层公共逻辑（AOP），所有异常要能在最外层被接住（全局异常处理）。它们都由 Spring 框架提供，所以第 4 页会把它们圈进同一个框里。

下方那一排：进出的”标记”与”外围资源”#

会话、令牌、云存储、持久层框架排在三层下方，它们都和”数据怎么流转”有关：

• Cookie/Session 与 JWT 管的是”这个人是谁”——先有标记，才谈得上拦（82 篇把这条依赖讲得很清楚）；
• 阿里云 OSS 管的是”文件存哪”——业务数据进 MySQL，文件类数据进 OSS；
• MyBatis 管的是”数据怎么进 MySQL”——它紧挨着 Dao 和 MySQL 之间。

左边那两道门：先拦请求，再进业务#

过滤器 → 拦截器 → Controller 这个先后顺序不是随便排的：Filter 是 Servlet 规范里的组件，请求还没进 SpringMVC 就被它经手；Interceptor 是 SpringMVC 内部的机制，请求已经到了 SpringMVC、正要调用 Controller 方法时才轮到它（84 篇有一节专门把两者摆在一起对比）。所以登录校验的两套方案写的是同一段逻辑，位置却不一样。

把图读成一条链路#

把四版图叠起来，一条请求的走向就是从左边进入、穿过三层、到右边的数据库、再原路返回：

1
浏览器
2
  │  ① 请求（请求头里带着 JWT 令牌）
3
  ▼
4
过滤器 Filter                                        ← 第一道门（JavaWeb 解决方案那一列）
5
  │
6
  ▼
7
拦截器 Interceptor ──▶ Controller                     ← 第二道门 + 控制层（都在 SpringMVC 这一格里）
8
  │                        ▲
9
  │                        │  接收请求 / 响应数据由 SpringMVC 负责
10
  ▼                        │
11
Service ──▶ AOP 代理（事务管理 / 记录操作日志）          ← 业务逻辑层
12
  │
13
  ▼
14
Mapper（MyBatis）──▶ MySQL                            ← 数据访问层 + 数据库
15
  │
16
  └── ② 响应：Result 由 SpringMVC 转成 JSON 原路返回浏览器
17
      ③ 中途任何异常 ──▶ 全局异常处理 ──▶ Result
18
      ④ 文件类数据 ──▶ 阿里云 OSS（不进 MySQL）
19
      ⑤ 上面这一切能跑起来 ──▶ SpringBoot（起步依赖 + 自动配置 + 内嵌 Tomcat）

一、知识回顾（读完直接做下面的实践题）#

下面 12 条就是整张地图的”关键点清单”，每条都给出”这个技术解决什么问题、在哪一层”。合上笔记，逐条问自己能不能说出来；说不出来的，点回对应笔记再看一眼。

1. 三层架构 + 数据库（图的骨架）：Controller（控制层）接收前端发送的请求，对请求进行处理，并响应数据；Service（业务逻辑层）处理具体的业务逻辑；Dao（数据访问层/持久层）负责数据的增、删、改、查；MySQL 负责数据存储和管理。调用方向是单向的 Controller → Service → Dao → MySQL（37 篇）。
2. IOC / DI（横在三层上方）：解决”层与层之间焊死”的耦合问题——**IOC（控制反转）**把对象的创建控制权由程序转移到 Spring 容器，DI（依赖注入）让容器把运行所需的资源（对象）注入进来；目标是高内聚低耦合（38、39 篇）。
3. AOP（横在三层上方）：面向特定方法编程——把”统计方法耗时""记录操作日志”这类公共逻辑从业务方法里抽走，由代理对象在指定方法执行前后自动运行，业务方法一行都不改（85-87 篇）。
4. 事务管理（横在三层上方）：一组操作的集合，一个不可分割的工作单位，要么同时成功、要么同时失败；用在 Service 的多表操作上做兜底（新增员工要同时写 emp 和 emp_expr），Spring 用 @Transactional 管（70、71 篇）。
5. 全局异常处理（横在三层上方）：异常不可避免，而默认返回的 {"timestamp","status","error","path"} 不符合项目规范；用一个全局异常处理器把异常统一转成 Result，前端永远只处理一种响应形状（76 篇）。
6. 过滤器 Filter（Controller 左边的第一格）：JavaWeb 三大组件（Servlet、Filter、Listener）之一，把对资源的请求拦截下来做通用操作——登录校验、统一编码处理、敏感字符处理；它在 Servlet 层干活，请求还没进 SpringMVC（83 篇）。
7. 拦截器 Interceptor（过滤器右边、Controller 之前）：Spring 框架提供的、动态拦截控制器方法执行的机制，在指定方法调用前后执行预设代码；接口规范不同（实现 HandlerInterceptor，而过滤器实现 Filter）、拦截范围不同（过滤器拦所有资源，拦截器只拦 Spring 环境中的资源）是它与 Filter 的两点区别；靠配置类的 addPathPatterns / excludePathPatterns 决定拦哪些、放哪些，粒度更细（84 篇）。
8. MyBatis（贴着 Dao 与 MySQL）：持久层框架——Dao 里只写接口 + 注解/XML 映射，参数封装、结果映射、连接池都替我们做了，不再手写 JDBC 那套样板代码（51-55 篇）。
9. SpringMVC（Spring framework 的 web 格）：Spring 框架里的 web 层，负责接收请求（把 HTTP 请求参数绑定到方法参数）与响应数据（把返回对象转成 JSON）；拦截器、全局异常处理也归它这一格（32-35、76、84 篇）。
10. Cookie/Session 与 JWT（三层下方）：登录校验的第一件事——登录标记。Cookie 存在客户端、Session 存在服务端，两者都受”服务端会话”的限制；课程最终选令牌（JWT）——登录成功后生成令牌返回前端，之后每次请求在请求头里带上，配合统一拦截校验（81、82 篇）。
11. 阿里云 OSS（三层下方）：第三方云存储服务，业务数据进 MySQL，文件类数据进 OSS；引出的”参数配置化”还顺手解决了密钥写死在代码里的问题（72、73 篇）。
12. SpringBoot（最下面的底座）：两大能力是起步依赖与自动配置，加上内嵌 Tomcat，一个 main 方法就能把 Web 应用跑起来；正因为它是底座，才托得住 Spring framework 与 MyBatis 这两列（31、88-90 篇）。

二、概念自测#

• 2-1 请求进到后端，会先后经过哪两道”门”？为什么两道门的位置不一样？ 要求：说出两道门的名字、各自拦什么、由谁提供，并说明过滤器为什么排在拦截器前面。

  提示（先自己想，实在想不出再点开）

  一级 · 思路：门的位置由它”住在谁家”决定——一个住在 Servlet 规范里，一个住在 SpringMVC 里 二级 · 角度：谁拦的是”请求”，谁拦的是”控制器方法”？请求先到 Servlet 容器还是先到 SpringMVC？ 三级 · 骨架：第一道门是 ______（来自 ______ 规范），它拦的是 ______；第二道门是 ______（来自 ______ 框架），它拦的是 ______

  参考答案（做完再点开）

  先过 过滤器 Filter，再过 拦截器 Interceptor。

  • Filter：JavaWeb 三大组件（Servlet、Filter、Listener）之一，拦的是请求，用来做登录校验、统一编码处理、敏感字符处理等通用操作。它属于 Servlet 层，请求还没进 SpringMVC 就被它经手（83 篇）。
  • Interceptor：Spring 框架提供，动态拦截控制器方法的执行，拦的是”正要调用某个 Controller 方法”这一步。它住在 SpringMVC 内部，所以只能拦住进了 SpringMVC 的请求（84 篇）。

  顺序的原因：请求是先从浏览器到 Servlet 容器、再到 SpringMVC 的。所以 Filter 天然在外侧、Interceptor 在内侧；PPT 第 3 页把 Filter 画在 Controller 更左边一格，就是这个道理。

• 2-2 图上为什么把”过滤器、Cookie/Session、JWT、阿里云 OSS”归成一列叫 JavaWeb 解决方案，而把 IOC/DI/AOP/事务管理归到 Spring framework 里？ 要求：说出这两类技术的共同点，并解释 Mybatis 为什么单独占一列。

  提示（先自己想，实在想不出再点开）

  一级 · 思路：看”这些东西是谁提供的”——是 JavaWeb/HTTP/第三方世界的通用方案，还是 Spring 框架自己的核心能力 二级 · 角度：过滤器来自哪个规范？Cookie/Session 来自哪套协议？JWT 是标准还是框架？OSS 是谁的服务？IOC/DI/AOP/事务管理又是谁的能力？ 三级 · 骨架：JavaWeb 解决方案 = ______ 提供的通用方案；Spring framework = ______ 自己的核心能力；Mybatis 是 ______ 框架，SpringBoot 只是帮它做 ______

  参考答案（做完再点开）

  JavaWeb 解决方案这一列的共同点是”通用方案，不靠 Spring”：过滤器来自 Servlet 规范（JavaWeb 三大组件之一），Cookie/Session 来自 HTTP 的会话技术，JWT 是令牌标准（任何语言、任何框架都能用），阿里云 OSS 是第三方云服务。它们解决的是”请求进出的门""登录标记""文件存哪”这类通用问题，换成别的框架也还是这几样东西。 Spring framework 这一列是 Spring 框架自己的核心能力：管对象（IOC/DI）、管切面（AOP）、管事务（事务管理）——它们不是独立的工具，而是同一套容器提供的机制，所以画在一个框里。 Mybatis 单独一列，是因为它是第三方的持久层框架：既不归 Servlet 规范管，也不是 Spring 的亲儿子，SpringBoot 只是通过自动配置把它集成进来（所以图上的 SpringBoot 底座横贯中间和右边两列）。

  换成一句话：左边是”要用的方案”，中间是”框架的能力”，右边是”持久层框架”，下面是”把这一切装起来并跑起来的底座”。

• 2-3 为什么说 SpringBoot 是这张图的”底座”？它自己在图上不写业务，到底做了什么？ 要求：至少说出两件它替我们做的事，并解释”底座”这个位置的含义。

  提示（先自己想，实在想不出再点开）

  一级 · 思路：回想只写了两行依赖坐标的 pom，以及启动日志里那句 Tomcat started on port(s): 8080 二级 · 角度：依赖是谁带进来的（起步依赖 + 依赖传递）？那么多配置是谁配好的（自动配置）？Web 服务器是装出来的还是依赖带进来的（内嵌 Tomcat）？ 三级 · 骨架：SpringBoot 的两大能力是 ______ 和 ______；再加上 ______，所以一个 ______ 方法就能把应用跑起来

  参考答案（做完再点开）

  因为其他技术（Spring framework、MyBatis、SpringMVC、拦截器、全局异常处理……）都是靠它组装起来、并被它拉起来的。 它做的事至少有三件：

  1. 起步依赖：pom 里写一行 spring-boot-starter-web，靠依赖传递把内嵌 Tomcat、SpringMVC、JSON 转换等一整套 jar 带进来（31 篇，本机实测的依赖树见过这件事）；
  2. 自动配置：它按”约定优于配置”的思路替我们配好大量 bean，条件不满足就不配（@Conditional 系列），这也是 application.yml 里往往只需要写几个数据源参数的原因（89 篇）；
  3. 内嵌 Tomcat + 打包运行：Tomcat 是以普通 jar 依赖的形式跟着工程下载的，运行启动类的 main 方法就把服务器和应用一起拉起来，不用自己装 Tomcat、不用打 war 丢进 webapps（31 篇，实测启动日志里有 Tomcat started on port(s): 8080）。

  所以在图上它不是”第 N 层技术”，而是地基：地基不在业务链路上，但上面那些列都站在它上面。至于配置优先级、Bean 管理（88 篇）和自定义 starter（90 篇），讲的都是它是怎么做到这些的。

• 2-4 判断题：图上把”拦截器”和”全局异常处理”划进了 SpringMVC 那一格，而不是和 AOP、事务管理并排——这样分有道理吗？为什么？ 要求：先判断，再说明这两个东西”web 层”的属性体现在哪里。

  提示（先自己想，实在想不出再点开）

  一级 · 思路：问自己一句——AOP 和事务管理是”给谁用都行”的能力，还是”只有处理请求时才用得上”的能力？ 二级 · 角度：拦截器拦的是谁（控制器方法 vs 任意方法）？全局异常处理器是挂在什么类上的（普通 bean 还是 web 层的 advice）？ 三级 · 骨架：有道理——拦截器拦的是 ______，全局异常处理处理的是 ______ 抛出的异常；它们只出现在 ______ 这一层，而 AOP/事务管理是 ______ 的能力

  参考答案（做完再点开）

  有道理。

  • 拦截器拦的是”控制器方法”的执行——它只能拦进到 SpringMVC 的请求，离开 web 层就不存在了（84 篇）；
  • 全局异常处理是接住 Controller 方法链上抛出的异常、把它转成 Result 响应——没有请求就没有”响应格式”这回事，它同样只在 web 层生效（76 篇）；
  • 相比之下，AOP 和事务管理是 Spring 容器的通用能力：任意一个 bean 的方法都能被 AOP 增强，任意一个 Service 方法都能开启事务，跟”有没有 web 请求”无关。

  所以 PPT 第 3 页它们还只是五个并排的词，到第 5 页就被收进 SpringMVC 那一格——同一排词按”只属于 web 层 / 属于整个 Spring”重新分了一次家。这也顺便解释了为什么拦截器排在 Filter 后面（一个是 SpringMVC 内部的机制，一个是 Servlet 规范的组件）。

三、综合题#

• 3-1 把”新增员工”这条链路从浏览器讲到数据库，说清每个环节是谁在干活 背景：Tlias 的”新增员工”接口要接收一个表单（姓名、性别、入职时间、头像文件、多行工作经历），往 emp 和 emp_expr 两张表里写数据，还要记录一次操作日志；数据库里 emp.username 建了唯一约束，撞名要正常返回提示。 请按顺序回答（每一步都要点明”在哪一层 / 是图上哪一格”）：

  1. 进门：请求从浏览器出发时带着什么凭证？路上先后被哪两道”门”检查？没带凭证时在哪一步就被挡住、还进不进得到 Controller？
  2. 收参：请求里的表单数据（普通字段 + 文件）是怎么变成 Controller 方法参数的？分别靠什么技术？
  3. 调业务：Controller 是”自己 new 一个 Service”，还是拿到容器给的对象？这件事由哪两个词负责？
  4. 业务里挂着的两件事：Service 执行过程中，有哪两个”横切能力”在起作用？各自解决什么问题（多表写入 / 留痕）？
  5. 落库：Service 往下调的是谁？它凭什么不用手写 JDBC？SQL 最终怎么到 MySQL？
  6. 出错：如果撞了 emp.username 的唯一约束，异常从哪一层抛出来、被谁接住、最终前端收到什么形状的响应？
  7. 回程：结果怎么变成浏览器认识的 JSON？
  8. 收官一问：把上面这些环节按”图上的区域”归类——JavaWeb 解决方案、Spring framework（含 SpringMVC 那一格）、Mybatis、SpringBoot 各出了哪些力？为什么说 SpringBoot 是底座？

  涉及知识点

  知识点	在这里的应用
  过滤器 Filter / 拦截器 Interceptor	第 1 步——令牌校验的两道门
  SpringMVC（接收请求 / 响应数据）	第 2、7 步——参数绑定与 JSON 响应
  IOC / DI	第 3 步——Service、Mapper 都是容器注入的
  事务管理 / AOP	第 4 步——多表写入的一致性 + 操作日志
  MyBatis	第 5 步——接口 + 注解/XML 映射，参数与结果自动处理
  全局异常处理	第 6 步——异常统一转成 Result
  阿里云 OSS	第 2 步——头像文件先上传到云存储，拿到 URL 再入库
  三层架构	全程——请求的走向就是 Controller → Service → Dao → MySQL

  提示（先自己想，实在想不出再点开）

  一级 · 思路：别按”类名”背，按”图上从外向里再原路返回”走——先两道门，再 SpringMVC 收参、Controller、Service（挂事务和 AOP）、MyBatis、MySQL，然后响应原路返回，异常有专门的出口 二级 · 方法：带的是 JWT 令牌（请求头里），先过 Filter 再过 Interceptor；控制器参数靠 @RequestParam / @RequestBody / MultipartFile 绑定；Service 和 Mapper 靠依赖注入拿到；多表写入用 @Transactional，切面用 AOP（记录操作日志）；数据访问靠 MyBatis（@Insert / XML + #{}）；异常交给全局异常处理器转成 Result；返回对象由 SpringMVC 转 JSON 三级 · 骨架：① JWT → Filter → Interceptor（挡在 401）② MultipartFile + 普通参数 → Controller 方法 → 头像先上 ______ 拿 URL ③ Controller 注入 Service → Service 注入 Mapper ④ @Transactional 管两表 + 切面记日志 ⑤ MyBatis 发 SQL → MySQL ⑥ 唯一约束异常 → 全局异常处理器 → Result.error(...) ⑦ 返回对象 → JSON ⑧ 归类到四个区域，底座是 ______

  参考答案（做完再点开）

  1. 进门：请求在请求头里带着登录成功时拿到的 JWT 令牌。先过过滤器 Filter（Servlet 规范，JavaWeb 解决方案那一列），再过拦截器 Interceptor（SpringMVC 那一格）。令牌不合法的话，在过滤器（或拦截器）这一步就被挡住、直接返回 401，根本进不到 Controller——这正是”统一拦截”的意义：几十个接口不用各写一遍校验（83、84 篇）。 2. 收参：这一步是 SpringMVC 干的（图上”接收请求”）。普通表单字段靠 @RequestParam 一类的方式绑定到方法参数；头像文件用 MultipartFile 接收，按 72/73 篇的流程先上传到阿里云 OSS，拿回一个可访问的 URL；工作经历是多行数据，用对象/集合接收。 3. 调业务：Controller 不自己 new，而是用依赖注入拿容器创建好的 Service 对象；Service 里同样注入 Mapper。负责这两个词的是 IOC（创建权交给容器） 和 DI（容器把依赖注入进来），对应图上横在三层上方的前两格（38、39 篇）。 4. 业务里挂着的两件事：① 事务管理——emp 和 emp_expr 两张表要么一起成功、要么一起失败，方法上加 @Transactional，避免出现”基本信息存了、工作经历没存”的残缺数据（70、71 篇）；② AOP——在方法前后自动织入公共逻辑，这里用来记录操作日志（谁、什么时候、做了什么），业务代码一行都不改（87 篇）。顺带 @Transactional 本身也是靠 AOP 代理实现的。 5. 落库：Service 往下调 Mapper（持久层/数据访问层），它是 MyBatis 的接口——只写接口方法 + 注解或 XML 映射，SQL 里的 #{} 负责参数封装、结果自动映射成对象、连接交给数据库连接池，不用手写 JDBC 的注册驱动/获取连接/释放资源那一套（51-55 篇）。SQL 最终发到 MySQL，数据落在 emp、emp_expr 两张表里。 6. 出错：唯一约束冲突的异常由 Dao/Service 这一层抛出，一路往上到 Controller；全局异常处理器（SpringMVC 那一格）把它接住，转成统一响应，前端收到的是

  1
  {"code":0,"msg":"...","data":null}

  而不是 SpringBoot 默认的 {"timestamp","status","error","path"}（76 篇实测过默认结构）。 7. 回程：Controller 返回的 Result 对象由 SpringMVC（响应数据） 转成 JSON 写回浏览器——这一步和第 2 步是同一格的两个方向（34、35 篇）。 8. 归类：

  • JavaWeb 解决方案：过滤器（拦请求、校验令牌）；
  • Spring framework：IOC/DI（造对象、注入依赖）、AOP（记日志）、事务管理（两表一致），以及 SpringMVC 那一格（接收请求、响应数据、拦截器、全局异常处理）；
  • Mybatis：数据访问，SQL 与结果映射；
  • SpringBoot：把这些技术组装起来并跑起来——一行起步依赖把 web 相关的一整套 jar（含内嵌 Tomcat）带进来，自动配置把 MyBatis、SpringMVC 这些配好，所以它是底座；application.yml 里的数据源参数、Bean 的创建与作用域，都归它管（31、56、88-90 篇）。

  一句话收尾：这条链路就是整张图在动——浏览器从左下角进，穿过两道门（Filter、Interceptor）进入 SpringMVC，沿着三层架构往下走到 MySQL，再原路带着 Result 回到浏览器；图上的每一个技术都对应链路上的一个环节，没有一个词是白画的。