Spring Boot 和 Spring Cloud 之间的区别？

🏛 业务架构师

一句话定位：Spring Boot 解决"单个服务怎么快速开发和交付"，Spring Cloud 解决"一堆服务怎么协同和治理"——一个是服务构建框架，一个是微服务治理套件，且后者完全构建在前者之上（每个微服务都是 Boot 应用）。

分层看职责：

Spring Boot：自动配置、starter、内嵌容器、Actuator——把一个服务从代码变成可运行、可观测的交付物；
Spring Cloud：注册发现（Nacos）、配置中心、远程调用（OpenFeign）、负载均衡、熔断限流（Sentinel）、网关（Gateway）、分布式事务（Seata/集成）——让几十个交付物作为一个系统协同工作：互相找得到、调用有保护、故障不扩散、配置统一管。

打个业务比方：Boot 是"标准化建每一间店铺"，Cloud 是"整个商圈的物业管理体系"（导览、安保、水电、客流调度）。

架构师视角的引申（面试加分点）：

关系正在重构：Spring Boot 3+ 吸收了部分治理能力（Micrometer Tracing 内置链路），K8s 吸收了部分基础设施职能（服务发现、健康检查）——"Cloud 的组件清单在瘦身"是 2026 年的现实；
粒度决策：小规模系统"Boot 单体 + 模块化"可能比"Boot + Cloud 全家桶"更优——先有服务化的组织诉求，再有 Cloud 的技术投入，顺序不能反。

一句话：Boot 是刀，Cloud 是刀架；没有一批需要治理的服务，就不需要这个刀架。

一句话定位：Boot 解决单个服务的开发与交付效率，Cloud 解决服务集群的分布式治理。Cloud 构建在 Boot 之上——每个 Cloud 组件都以 Boot 的自动配置加 starter 形态交付，没有 Boot 就没有 Cloud。

Boot 内核：自动配置、starter、内嵌容器、Actuator——「单体应用跑得好」；
Cloud 叠加：注册发现（Nacos）、配置（Nacos）、调用（OpenFeign 加 LoadBalancer）、容错（Sentinel）、网关（SCG）、事务（Seata）、追踪（Micrometer）——「一堆服务协同得好」。

版本治理（工程要点）：Cloud 与 Boot 有严格版本列车对应（如 2024.x 对应 Boot 3.4~3.5、2025.x 对应 3.5+），乱配版本是依赖冲突的头号来源；引入 Alibaba 系还要三方对齐——我的做法是平台出统一 BOM，业务只引 BOM 不写版本号。

架构视角：我的实践是把这套东西平台化封装——内部「脚手架加 BOM 加平台 starter」预置全套 Cloud 组件的合规配置，业务团队无感接入。Cloud 是能力原料，平台才是交付形态。

一句话定位：Boot 解决"单个服务怎么快速开发部署"，Cloud 解决"一群服务怎么协同治理"。

Spring Boot：自动配置、内嵌容器、starter、Actuator——单体应用也完整可用
Spring Cloud：构建在 Boot 之上的一组子项目，提供微服务治理能力：注册发现（Nacos/Eureka）、配置（Nacos/Config）、网关（Gateway）、调用（OpenFeign）、容错（Sentinel）、观测（Micrometer Tracing）、事务（Seata）

依赖关系：Cloud 每个组件都以 Boot starter 形式提供，没有 Boot 就没有 Cloud；但 Boot 完全可独立存在。版本对应也体现从属：Cloud 2023.0.x 要求 Boot 3.2.x，用官方矩阵选型。

类比：Boot 是"造一辆好开的卡车"，Cloud 是"车队调度系统"。实操边界感：单体阶段只用 Boot，别提前上 Cloud（一堆中间件换不来收益）；拆微服务时按需引入网关 + 注册 + Feign 起步，观测和容错后补——这个演进顺序是我带团队的标准打法。