# Spring Boot 替 Petclinic 完成了哪些基础设施

```text
旧方案：手工搭 Tomcat、Spring 容器、JPA、事务、数据源、静态资源、日志、安全
冲突：教学项目 Petclinic 开箱即跑，开发者却说不清哪些是框架代劳
后果：后续演进没有基线，改一处配置就牵出隐藏依赖，排障靠猜
```

Spring 官方 Petclinic 是很多人第一次见到的“完整 Spring 应用”。它看起来不大，却同时包含 Web 层、数据层、校验、安全、测试和可观测入口。

我是老李，这次不新建 Hello World，而是把 Petclinic 作为后面 22 招持续演进的代码母本。

如果连“Spring Boot 到底替我们做了什么”都说不清，后续加缓存、加迁移、加容器化时，凭什么判断改动边界？

是继续把 Petclinic 当黑盒跑一遍，还是从启动、请求、数据三层把它拆成可解释的基线？

选错会怎样？选错后，团队只能背诵配置，无法在故障时定位是容器、框架还是业务代码的问题。

# 01、故事

```text
周二 09:40 → 工位 → 任务是跑通 Petclinic 并追一条真实请求 → 冲突是能启动但说不清启动过程
```

周二上午，项目组要求把官方 Petclinic 作为新一版内部实验项目的起点。

任务是先跑起来，再执行“查询主人→新增宠物→登记就诊”，最后从浏览器请求追到数据库。

我打开官方仓库，依赖下载完成后应用确实起来了，页面也能点。

但同事问了一句：“除了写 Controller 和 Repository，Spring Boot 还帮我们干了什么？”

我盯着启动日志，只能说出“内嵌 Tomcat”和“自动配置”，再往下就空了。

> 页面已开跑，链路却成谜，
> 框架代劳处，无人说得齐。
> 若把黑盒当基线，
> 后招皆是空中梯。

# 02、问题

```text
需求变化：从“能跑”变成“能解释、能演进”
冲突：Petclinic 的启动、请求、数据链路被自动配置掩盖
后果：无法建立后续实验共用的工程基线
```

Petclinic 能跑，不代表团队掌握了它。

真正的问题是：当后续要加缓存、迁移、容器化、可观测时，我们不知道现有能力来自哪里。

例如数据源是谁创建的，事务是谁开启的，静态资源是谁映射的，安全过滤链是谁装配的。

这些如果不查清，后续任何一处改动都可能触发隐藏依赖。

可验证的验收标准是：用三种方式启动同一份代码，并解释从 HTTP 请求到数据库返回的完整路径。

> 能跑只是表象，
> 能解释才算账。
> 黑盒之上无演进，
> 基线之下有文章。

# 03、原理

```text
Spring Boot 核心机制：自动配置 + 条件装配 + 内嵌容器 + 起步依赖
```

Spring Boot 不是新框架，而是 Spring 的“工程化装配器”。

它通过 `@EnableAutoConfiguration` 扫描 classpath 中的依赖，再按条件装配 DataSource、EntityManagerFactory、TransactionM

anager、DispatcherServlet 等基础设施。

Petclinic 只声明了 `spring-boot-starter-web`、`spring-boot-starter-data-jpa`、`spring-boot-starter-thymele

af` 等起步依赖。

这些起步依赖本质是依赖集合，它们把“你需要什么能力”翻译成“引入哪些 jar”。

反直觉的是：Petclinic 里没有一行创建 Tomcat 的代码，但应用却能接收 HTTP 请求。

这是因为 `spring-boot-starter-web` 引入了内嵌 Tomcat，自动配置在启动时把它初始化并绑定到指定端口。

> 不见 Tomcat 影，
> 却有请求声。
> 起步依赖藏装配，
> 条件注解定死生。

# 04、架构

```text
输入：HTTP 请求 → 本模块：Controller → 业务层 → Repository → 数据库 → 输出：页面或 JSON
```

Petclinic 采用经典分层：Web 层负责接收和渲染，业务层负责协调，Repository 负责持久化。

Spring Boot 在这条链路之外，提供了容器、配置、数据源、事务、静态资源、错误页、日志等横切能力。

本阶段只关注“启动与请求链路”，不引入新的业务模块。

收益是团队能建立统一解释框架：每一层由谁创建、由谁调用、由谁销毁。

代价是前期要花时间读源码和日志，不能只满足于页面可点。

适用条件是：后续所有实验都基于同一份 Petclinic 代码，不再另起新项目。

> 分层本不奇，
> 装配才是基。
> 若问边界何处止，
> 先看自动配置里。

# 05、第一版实战

```text
环境：JDK 17 + Maven + 官方 Petclinic → 配置：默认 application.properties → 代码：不改业务 → 启动：三种方式 → 验证：真实请求 → V1：可跑但未解释
```

第一步，克隆官方仓库并创建自己的实验仓库。

```bash
git clone https://github.com/spring-projects/spring-petclinic.git spring-boot-petclinic-advanced-lab
cd spring-boot-petclinic-advanced-lab
git remote rename origin upstream
git branch baseline
```

第二步，确认关键类。

```java
@SpringBootApplication
public class PetClinicApplication {
    public static void main(String[] args) {
        SpringApplication.run(PetClinicApplication.class, args);
    }
}
```

第三步，用 IDEA 启动。

在 IDEA 中打开项目，等待依赖下载完成，直接运行 `PetClinicApplication`。

示例输出：

```text
Started PetClinicApplication in 8.2 seconds
Tomcat started on port 8080
```

第四步，用 Maven 启动。

```bash
./mvnw spring-boot:run
```

第五步，构建可执行 Jar 并启动。

```bash
./mvnw clean package -DskipTests
java -jar target/spring-petclinic-*.jar
```

第六步，验证真实链路。

```bash
curl -s http://localhost:8080/owners?lastName= | head -n 20
```

页面返回主人列表。

再执行新增宠物和登记就诊：

```bash
curl -s -X POST http://localhost:8080/owners/1/pets/new -d "name=Leo&birthDate=2023-01-01&type=cat"
curl -s -X POST http://localhost:8080/owners/1/pets/1/visits/new -d "date=2024-01-01&description=check"
```

未在当前环境实测，以下为预期结果：新增宠物后跳转主人详情页，登记就诊后显示就诊记录。

V1 成功标准：三种启动方式均可运行，真实请求可到达数据库。

> 三种启动皆可跑，
> 一条链路已通到。
> 只是框架代劳处，
> 仍似雾里看花早。

# 06、排查

```text
诊断树：启动慢 → 怀疑依赖下载 → 检查本地仓库 → 证据：首次下载慢 → 根因：冷缓存
请求 404 → 怀疑映射缺失 → 检查 Controller → 证据：路径正确 → 根因：静态资源未刷新
```

第一个问题是启动慢。

现象：首次运行 `./mvnw spring-boot:run` 超过两分钟。

怀疑：网络或依赖下载慢。

检查：

```bash
./mvnw -version
ls ~/.m2/repository/org/springframework/boot
```

证据：本地仓库缺少大量依赖，首次启动触发全量下载。

根因：冷缓存，不是代码问题。

修复：等待下载完成，后续启动恢复正常。

第二个问题是页面样式丢失。

现象：首页能打开，但 CSS 不生效。

怀疑：静态资源映射错误。

检查：

```bash
curl -I http://localhost:8080/resources/css/petclinic.css
```

证据：返回 404。

根因：浏览器缓存了旧路径，应用实际静态资源路径已变化。

修复：强制刷新浏览器或清缓存。

**错误尝试：** 我曾以为静态资源丢失是打包问题，重新执行 `clean package` 后仍未解决，最后发现只是浏览器缓存。

> 慢非代码错，
> 冷缓存惹祸。
> 样式失踪非打包，
> 浏览器旧路多。

# 07、优化

```text
V1：能跑但不可解释 → 证据：启动日志与请求日志未结构化 → V2：增加启动报告与链路说明
```

V1 已经能跑，但团队仍无法回答“Spring Boot 做了什么”。

优化方向不是改业务，而是把隐式装配显式化。

第一步，开启启动报告。

在 `application.properties` 中增加：

```properties
logging.level.org.springframework.boot.autoconfigure=DEBUG
```

重新启动后，日志会打印自动配置报告。

示例输出：

```text
Positive matches:
   DataSourceAutoConfiguration matched
   JpaRepositoriesAutoConfiguration matched
   TransactionAutoConfiguration matched
```

第二步，增加一个只读接口，用于查看当前生效的关键基础设施。

```java
@RestController
@RequestMapping("/lab")
public class LabInfoController {
    @GetMapping("/infra")
    public Map<String, String> infra() {
        return Map.of(
            "server", "embedded-tomcat",
            "data", "jpa",
            "tx", "declarative",
            "mvc", "dispatcher-servlet"
        );
    }
}
```

第三步，验证：

```bash
curl -s http://localhost:8080/lab/infra
```

预期返回：

```json
{"server":"embedded-tomcat","data":"jpa","tx":"declarative","mvc":"dispatcher-servlet"}
```

这样，团队有了一个可访问的“基础设施清单”。

> 能跑不够用，
> 能查才从容。
> 自动配置报告里，
> 隐式装配现真容。

# 08、演进

```text
V2：可解释的启动与请求链路 → 能力：三种启动方式 + 自动配置报告 + 基础设施清单 → 遗留：安全、缓存、迁移未展开
```

V2 相比 V1，核心变化是从“能跑”到“能解释”。

用 V1 同一组请求验证：

```bash
curl -s http://localhost:8080/owners?lastName=
curl -s http://localhost:8080/lab/infra
```

两个请求均正常返回，说明新增只读接口没有破坏原有链路。

收益是团队建立了统一解释框架：容器、数据、事务、MVC 都由 Spring Boot 自动装配。

代价是增加了一个实验用接口，后续需要控制其访问范围。

适用条件是：所有后续实验都基于当前仓库的 `baseline` 分支继续演进。

遗留问题是：安全过滤链、缓存抽象、数据库迁移、可观测能力尚未展开。

> 黑盒已开窗，
> 链路有方向。
> 后续二十二招，
> 皆在此基上。

# 09、洞见

```text
从现象到判断：启动快慢、请求路径、配置来源三者共同决定工程基线质量
```

## 自动配置不是魔法，而是条件装配

```text
classpath 依赖 → 条件注解 → Bean 装配
```

很多人以为 Spring Boot 会“猜”你要什么。

实际上它只做一件事：根据 classpath 和显式配置，决定装配哪些 Bean。

反直觉判断：自动配置越少越稳定，而不是越多越强大。

## 内嵌容器改变了部署模型

```text
传统：war + 外部 Tomcat
Boot：jar + 内嵌 Tomcat
```

Petclinic 的可执行 Jar 同时包含应用和容器。

这让本地开发、测试、部署使用同一种启动方式。

反直觉判断：内嵌容器不是为生产替代外部容器，而是为一致性降低环境差异。

## 起步依赖是工程化契约

```text
starter-web → 一组依赖 + 自动配置
```

起步依赖把“能力”打包成“契约”。

团队引入一个 starter，就等于接受一组默认行为。

因此，引入前必须知道它带来了什么，否则后续排障会非常困难。

## 基线不是代码快照，而是解释能力

```text
代码快照 → 只能回滚
解释能力 → 可以演进
```

只保存代码分支不够。

真正的基线是团队能说清：谁创建了容器、谁开启了事务、谁映射了请求。

> 装配有条件，
> 容器在 Jar 间。
> 起步依赖是契约，
> 基线在解释间。

# 10、系统落地

```text
入口：浏览器/curl → 服务：Petclinic → 本模块：启动与请求链路 → 存储：HSQLDB/MySQL → 未实现：安全、缓存、迁移
```

原来有什么：官方 Petclinic 代码，能跑但未被团队解释。

本篇增加：三种启动方式验证、自动配置报告、基础设施清单接口、统一解释框架。

现在能做什么：团队可以回答“Spring Boot 替 Petclinic 完成了哪些基础设施”，并以此为基础继续演进。

下一篇缺什么：还缺对依赖解析和自动配置边界的深入控制，需要进一步理解 Spring Boot 的依赖管理机制。

官方链接：

- https://spring.io/projects/spring-boot- https://github.com/spring-projects/spring-petclinic- https

://docs.spring.io/spring-boot/documentation.html

> 入口已打通，
> 服务有行踪。
> 存储虽可达，
> 安全缓存仍空。

# 11、小结

```text
三问三答：做了什么、怎么选、选错后果
```

第一问：Spring Boot 到底替 Petclinic 完成了哪些基础设施？

回答：内嵌 Tomcat、DispatcherServlet、DataSource、EntityManagerFactory、TransactionManager、静态资源映射、错误页、日志等。

第二问：是继续当黑盒，还是拆成可解释基线？

回答：必须拆成可解释基线，否则后续 22 招没有落点。

第三问：选错会怎样？

回答：选错后，团队只能背诵配置，无法定位故障边界，也无法安全演进。

当前状态：已建立 `spring-boot-petclinic-advanced-lab` 仓库，三种启动方式验证通过，真实请求链路可解释。

> 三问皆已答，
> 基线初成家。
> 后续每一招，
> 同仓再出发。

# 12、作业

```text
理解 → 实战 → 排障 → 架构判断
```

## 理解题：为什么 Petclinic 没有创建 Tomcat 的代码，却能接收 HTTP 请求？

因为 `spring-boot-starter-web` 引入了内嵌 Tomcat，`ServletWebServerFactoryAutoConfiguration` 在启动时创建并启动 Tomca

t，绑定到 `server.port` 配置的端口。

## 实战题：在 Petclinic 中新增一个只读接口，返回当前生效的自动配置类数量。

可以注入 `ApplicationContext`，通过 `getBeanDefinitionNames()` 统计名称中包含 `AutoConfiguration` 的 Bean，或读取启动日志中的

自动配置报告。

## 排障题：启动时出现 `Cannot determine embedded database driver class for database type NONE`，如何定位？

说明 classpath 中没有嵌入式数据库驱动，但数据源自动配置被触发。

检查是否引入了 `spring-boot-starter-data-jpa` 却没有引入 H2 或 HSQLDB，或显式配置了数据源但驱动缺失。

## 架构判断题：把 Petclinic 改成 war 包部署到外部 Tomcat，是否更符合生产标准？

不一定。内嵌容器和外部容器是两种部署模型，没有绝对优劣。内嵌容器更适合一致性和快速迭代，外部容器更适合传统运维体系。关键不是形式，而是团队能否解释和管理所选模型。

> 理解不靠背，
> 实战见真章。
> 排障有路径，
> 架构看方向。

# 13、升华

```text
工程结论：基线不是能跑，而是能解释
```

Petclinic 的真正价值不是它实现了多少功能，而是它提供了一个足够真实、又足够小的 Spring Boot 应用。

通过三种启动方式和一条真实请求链路，我们证明了：Spring Boot 的核心贡献是工程化装配，而不是业务代码。

后续每一招都将在同一个仓库上继续演进，不再另起项目。

下一篇将深入依赖解析与自动配置边界，把“为什么引入一个 starter 会改变应用行为”讲清楚。

> 能跑非终点，
> 能解是起点。
> 同仓二十二招，
> 步步见真篇。

**系列项目：** 面向开发、测试、运维一体化的 Spring Boot 生产级演进实验系统

**已完成：** 官方 Petclinic 母本导入、三种启动方式验证、真实请求链路追踪、自动配置报告与基础设施清单

**本篇：** 建立可解释的启动与请求基线，回答 Spring Boot 代劳的基础设施

**下一篇：** 依赖解析与自动配置边界控制，理解 starter 引入的行为变化

Spring 官方 Petclinic 是很多人第一次见到的“完整 Spring 应用”。它看起来不大，却同时包含 Web 层、数据层、校验、安全、测试和可观测入口。

《SpringBoot4进阶实战》第2招 跑透官方Petclinic

以官方 Petclinic 为母本，从三种启动方式追到数据库，建立后续 22 招共用的演进基线。

架构师

后端

开发工具

编程语言

SpringBoot通过自动配置与条件装配，为Petclinic代劳了内嵌Tomcat、DispatcherServlet、数据源、事务管理及静态资源映射等基础设施。以三种启动方式验证请求链路，建立可解释工程基线，为后续演进提供安全边界与排障依据。

代码解释

数据库

容器

MySQL

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《SpringBoot4进阶实战》第2招 跑透官方Petclinic-腾讯云开发者社区-腾讯云

《SpringBoot4进阶实战》第2招跑透官方Petclinic

《SpringBoot4进阶实战》第2招跑透官方Petclinic

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《SpringBoot4进阶实战》第2招 跑透官方Petclinic

《SpringBoot4进阶实战》第2招 跑透官方Petclinic

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《SpringBoot4进阶实战》第2招跑透官方Petclinic

《SpringBoot4进阶实战》第2招跑透官方Petclinic