- 1WEB 基础HTTP / Browser / WebServer静态页面写死，人人看到一样
- 2Servlet手写 if-else 分发不可扩展，无生命周期/并发管理
- 3JSP：参数散字符串参数散成一堆 String，取值靠字段名硬记
- 3JSP：scriptlet 塞逻辑scriptlet 把逻辑塞进页面，代码与 HTML 糊在一起
- 3JavaBean：数据对象化对象全靠 new、层层硬依赖
- 4Spring IoCWeb 路由仍手写 web.xml/if-else、手动取参绑定，展示/业务/数据访问没分开
- 5MVC · SpringMVC数据在库里，访问是重复样板 + 拼串有注入风险
- 6MySQLJava 连库要手写五步，连接与资源管理全手动
- 7JDBCSQL 与 Java 混写、结果集逐行手映射、没有动态 SQL
- 8MyBatis四份配置 + web.xml 装配繁琐，部署要外部 Tomcat
- 9SpringBoot链尾 · 不考核
SpringBoot
SpringBoot
目标：理解 Boot「约定大于配置」——从 M8（MyBatis）章末死结「四份配置 + web.xml 装配繁琐，部署要外部 Tomcat」出发，掌握 starter 依赖机制、自动配置原理（对照 SSM 四配置文件逐项省掉什么）、内嵌 Tomcat 与
java -jar单文件部署。⚠️ 考核范围：本章为技术演进接力链的收口章，不纳入期中/期末考核范围——随堂测验仅用于巩固理解。
一、为什么需要 Boot：M8 章末死结
到 M8（MyBatis）为止，一个能跑起来的 SSM 工程要维护四份配置文件：
| 配置文件 | 职责 |
|---|---|
spring.xml | 组件扫描 + DataSource + 声明式事务 |
spring-mvc.xml | DispatcherServlet + 注解驱动 + 视图解析器 |
mybatis-config.xml | SqlSessionFactory + Mapper 扫描 |
web.xml | 容器级组件（DispatcherServlet、Filter、监听器） |
问题有两层：
- 装配繁琐：四份 XML 手工对齐 bean 名、id、扫描路径，改一处要同步多处，新手极易配错；
- 部署笨重：工程打成
.war丢进外部 Tomcat，环境不一致时「在我机器上能跑」频现。
SpringBoot 的解法一句话：约定大于配置（convention over configuration）——把「这套东西通常怎么配」固化成自动配置类，你只需给最少的输入，其余它替你补全。
二、starter 依赖机制
传统 Spring 工程要逐个引入 spring-core、spring-webmvc、mybatis-spring……版本还要自己对齐。Boot 用 starter 把「某类能力所需的一组依赖」打包成一个坐标：
spring-boot-starter-web：一次性带入 Web MVC + 内嵌 Tomcat + Jackson 等；mybatis-spring-boot-starter：带入 MyBatis + 连接池 + 自动配置；spring-boot-starter-data-jpa、spring-boot-starter-test……同理。
好处：你只声明「我要做 Web」「我要用 MyBatis」，依赖版本由 Boot BOM 统一托管，不再手工对齐——引一个 starter = 拿到一整套开箱即用的能力。
三、自动配置原理：对照 SSM 四配置逐项省掉什么
Boot 的核心是 @SpringBootApplication（= @Configuration + @EnableAutoConfiguration + @ComponentScan）。启动时它按「类路径上有什么依赖」去匹配 自动配置类，逐项替你把 SSM 里手写的装配补上。下面这个交互组件把四份配置的对应关系摆在一起，点左侧文件看右侧 Boot 怎么省掉它：
SSM：手写装配（4 份配置 + web.xml）
SpringBoot：自动配置（对照省掉什么）
组件扫描（<context:component-scan>）+ DataSource + 声明式事务（<tx:annotation-driven>）
自动配置：组件扫描 + 数据源 + 声明式事务，一并就绪
@SpringBootApplication（内含 @ComponentScan）· DataSourceAutoConfiguration · TransactionAutoConfiguration
一句话：Boot = SSM 的「全自动档」——四份手写配置逐项交给自动配置类，部署从外部 Tomcat 变成内嵌容器 + java -jar。
记忆锚点：
spring.xml→ 组件扫描/数据源/事务自动配置；spring-mvc.xml→WebMvcAutoConfiguration；mybatis-config.xml→MybatisAutoConfiguration；web.xml→ 内嵌容器直接省掉。
四、内嵌 Tomcat + java -jar 单文件部署
SSM 时代要「打 war → 丢进外部 Tomcat」。Boot 把 Tomcat 内嵌进 jar：应用启动时自己拉起一个 Servlet 容器，不再依赖外部安装。于是部署退化成一条命令：
mvn clean package # 打出可执行 fat-jar
java -jar app.jar # 直接跑，自带 Tomcat，默认 8081（本课程约定端口）
对照：SSM 部署 = 外部 Tomcat + war；Boot 部署 =
java -jar单文件。环境一致性由 jar 自身保证，「在我机器上能跑」的问题被消解。
五、最小工程走查：SimpleSpringBoot
一个最小的 Boot Web 工程只有三样东西：一个 @SpringBootApplication 主类（带 main）、一个 @RestController、一份 application.properties（配数据源/端口）。没有 web.xml、没有四份 XML。下面用 CodePlayground 跑一段纯 Java 片段，体会「主类即入口、启动即拉起容器」的最小形态：
交互实验：浏览器里编译运行 Java（CodePlayground）
未连接左边写 Java，点「运行」——源码经 WebSocket+STOMP 发给后端（端口 8081），真实javac编译 + java 运行，输出推回你的浏览器。先选一个预置程序试试：
← 点「运行」看编译/运行结果
💡 最小可运行程序：UTF-8 中文输出 + 表达式求值。
ws://<host>:8081/ws)→ 后端 STOMP /app/run → 沙箱编译运行 → 结果推回你的会话专属队列 /queue/result-<你的id>。每个浏览器标签页只收自己的结果，互不串台。一句话收束：Boot = SSM 的「全自动档」。它不是新框架，而是把 Spring + SpringMVC + MyBatis 的手写装配自动化了——你学过的 M4/M5/M8 一个都没废，只是配置被自动配置类接管。
思考题
- 「四份配置 + web.xml」的痛点具体是什么？Boot 分别用哪个机制省掉它们？
- starter 相比逐个引依赖，解决了哪两个麻烦（版本对齐 / 依赖爆炸）？
- 内嵌 Tomcat 让部署方式从什么变成什么？为什么这能解决「环境不一致」？
@SpringBootApplication由哪三个注解合成？各自负责什么？- 为什么说 Boot 不是「新框架」而是 SSM 的「全自动档」？
学习小测验（仅随堂，不入期中/期末卷）
学习小测验
SpringBoot 引入 spring-boot-starter-web 后，会自动带入什么？
SSM 里 spring.xml 负责的「组件扫描 + 数据源 + 声明式事务」，在 Boot 中对应（ ）
SSM 里 spring-mvc.xml 装配 DispatcherServlet 与注解驱动，Boot 中由谁完成？
SSM 里 mybatis-config.xml 配置 SqlSessionFactory，Boot 中由谁完成？
SSM 需要 web.xml 声明 DispatcherServlet/Filter 并依赖外部 Tomcat；Boot 里 web.xml 被省掉的原因是（ ）
相比 SSM「打 war 丢进外部 Tomcat」，Boot 的典型部署方式是（ ）
对 SpringBoot 最准确的定位是（ ）