一、请介绍下Spring Boot，它有哪些核心优点？
• 核心回答：Spring Boot是基于Spring的"快速开发工具"，不替代Spring框架本身，而是以"约定大于配置"为核心思想，简化Spring应用的搭建、运行与配置流程；核心价值是降低开发门槛，让开发者无需花费精力处理环境配置，专注于业务逻辑的实现。
• 通俗理解（类比"组装电脑"）：
◦ 传统Spring开发：像"攒兼容机"------得自己逐个挑选CPU、主板、内存（手动引入各类依赖），对照说明书调试BIOS参数（编写大量XML配置），还要单独安装操作系统（部署外部Tomcat容器），少一个零件或参数错配就可能无法启动，耗时且易出错。
◦ Spring Boot开发：像"买品牌整机"------商家已按需求搭配好全套硬件（比如"游戏整机"自带高性能显卡、大内存，对应spring-boot-starter-web依赖自带Web开发所需的spring-webmvc、Tomcat等），预装了系统（内嵌Tomcat/Jetty容器），开机即可使用（直接运行main方法启动应用），无需自己折腾零件适配和系统安装。
• 核心优点补充：
◦ 无XML配置：将传统Spring的XML bean配置，替换为@Autowired注解注入和application.yml（或properties）统一配置，比如用"server.port=8080"一句话配置端口，无需写复杂XML。
◦ 依赖"一键整合"：引入一个核心依赖，会自动关联加载相关依赖。例如引入spring-boot-starter-data-redis，会自动带redis客户端、spring-data-redis等，不用手动添加多个jar包。
◦ 自带"实用工具"：内置参数校验（@Valid注解）、应用监控（Actuator组件）、日志框架（默认SLF4J+Logback），无需额外集成第三方工具就能满足基础开发需求。
二、你理解Spring Boot的自动配置原理吗？请讲一讲
• 核心回答：自动配置的核心是@EnableAutoConfiguration注解（启动类上的@SpringBootApplication是包含该注解的复合注解），其功能通过AutoConfigurationImportSelector类实现------该类会读取META-INF/spring.factories文件，加载文件中配置的"自动配置类"（xxxAutoConfiguration），再根据项目依赖、配置参数动态判断哪些配置类生效，最终完成Bean创建和环境配置。
• 通俗理解（类比"点预制套餐"）：
◦ @EnableAutoConfiguration：相当于你在餐厅说"我要一份'家常套餐'"（开启自动配置，告诉Spring"按默认规则适配开发环境"）。
◦ AutoConfigurationImportSelector：相当于餐厅的"配菜员"，负责根据你点的套餐，从"预制菜清单"里挑选对应的菜品。
◦ META-INF/spring.factories：相当于餐厅的"预制菜清单"，上面列了所有可提供的预制菜（比如"米饭AutoConfig""番茄炒蛋AutoConfig"，对应Spring Boot的DispatcherServletAutoConfiguration、DataSourceAutoConfiguration等自动配置类）。
◦ 配置类生效逻辑：比如你点了"家常套餐"（项目引入spring-boot-starter-web依赖），配菜员会从清单里挑"米饭+炒菜+汤"（Web相关的自动配置类，自动创建DispatcherServlet、启动Tomcat容器）；如果你说"不要香菜"（通过@EnableAutoConfiguration(exclude = 某配置类)排除），配菜员会去掉含香菜的预制菜（指定不生效的配置类）。
• 关键步骤简化：点套餐（@EnableAutoConfiguration）→ 配菜员查清单（读spring.factories）→ 按需求挑菜（加载生效的配置类）→ 上菜（配置类生效，自动完成Bean初始化和环境配置）。
三、如何自定义一个Spring Boot Starter？用生活例子说明
• 核心回答：自定义Starter本质是"封装可复用的功能+配置"，让其他项目引入依赖后无需重复写配置就能直接使用。核心步骤分为5步：创建项目并引入基础依赖、编写配置属性类、编写自动配置类、配置spring.factories文件、测试验证。
• 通俗理解（类比"做自定义闹钟插件"）：
-
准备"插件壳"（建项目+加依赖）：先做一个"闹钟插件的外壳"（Maven/Gradle项目），引入"基础芯片"（spring-boot-starter依赖，确保插件能被Spring Boot识别）和"参数说明书生成器"（spring-boot-configuration-processor依赖，让用户配置时能获得参数提示）。
-
定义"闹钟参数"（写配置属性类）：用@ConfigurationProperties(prefix = "my.alarm")注解，定义闹钟的"响铃时间"（my.alarm.time）、"铃声类型"（my.alarm.sound，可选"叮咚""震动"），让用户能根据需求自定义闹钟参数。
-
写"闹钟逻辑"（写自动配置类）：创建AlarmAutoConfiguration类，用@Configuration注解标记为配置类，再用@EnableConfigurationProperties(AlarmProperties.class)关联配置属性类，告诉Spring"按用户配置的参数启动闹钟功能"（比如到点触发响铃逻辑）。
-
贴"插件说明书"（配spring.factories）：在项目resources/META-INF目录下创建spring.factories文件，写入"org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.xxx.AlarmAutoConfiguration"，相当于告诉其他项目"这个闹钟插件的核心逻辑在这里"。
-
测试"插件好用吗"（使用Starter）：其他项目引入你的"闹钟插件依赖"，在application.yml中配置"my.alarm.time=07:00"，就能直接注入AlarmProperties类获取配置，调用闹钟功能，不用自己编写闹钟逻辑。
四、Spring Boot的启动原理是什么？主要做了哪些事？
• 核心回答：Spring Boot启动的核心是SpringApplication类，启动过程分为"基础准备"和"容器初始化启动"两步。基础准备阶段主要做4件事：推断应用类型（Web应用/普通应用）、加载初始化器（Initializer）、查找应用监听器（Listener）、确定主类（main方法所在类）；后续再初始化Spring容器、加载自动配置类、扫描@Component组件，最终完成应用启动。
• 通俗理解（类比"开一家线上服装店"）：
◦ SpringApplication：相当于"店主"，负责统筹"开店前的准备"和"开店后的运营"。
◦ 4件基础准备（开店前）：
-
推断应用类型：确定开"纯线上店"（Web应用，需要服务器=Tomcat容器）还是"线下自提店"（普通应用，无需Web容器）。
-
加载初始化器：找"行政专员"（初始化器），准备营业执照、平台入驻资料（对应初始化Spring容器的环境参数、系统属性）。
-
查找应用监听器：找"客服专员"（监听器），负责监控订单异常、用户咨询（对应监听应用启动、关闭、异常等事件，比如应用启动失败时触发报警）。
-
确定主类：确定"店铺总部地址"（main方法所在类），所有运营指令（启动逻辑）从这里发出。
◦ 后续启动流程（开店）：
◦ 初始化容器：装修店铺（创建Spring容器，扫描项目中的@Controller、@Service等组件）。
◦ 加载自动配置：上架预制商品（加载spring.factories中的自动配置类，比如Web应用自动创建DispatcherServlet）。
◦ 启动应用：店铺开门营业（容器启动，监听端口，接受客户端请求）。
五、请谈谈你对Spring Cloud的理解，包括微服务的定义、核心问题和核心组件
• 核心回答：Spring Cloud是Spring官方推出的"微服务治理框架"，用于解决多个微服务之间的协作、管理与监控问题；微服务是将传统单体应用按业务领域拆分为多个独立、可通信的小服务，每个服务运行在单独进程中，独立部署、维护，且拥有自己的数据库。
• 通俗理解（类比"从'小卖部'到'商业综合体'"）：
- 微服务是什么？
◦ 单体应用：像"社区小卖部"------卖零食、饮料、日用品，所有商品挤在一个小店（一个应用），人多了排队卡顿（高并发时性能下降），修货架要关店（改一点代码需重启整个应用）。
◦ 微服务：像"商业综合体"------里面有"奶茶店""服装店""超市"（按业务拆的微服务），每个店独立开门（独立部署）、自己管库存（独立数据库），顾客逛不同店（调用不同服务）满足需求，奶茶店装修不影响服装店营业（服务解耦合）。
- 微服务要解决的核心问题（综合体运营痛点）：
◦ 顾客怎么找店？：综合体门口放"商户导览屏"（注册中心，如Nacos/Eureka），所有店铺开业前先登记地址（服务注册），顾客查屏就能找到目标店（服务发现）。
◦ 顾客怎么进综合体？：只留一个主入口（网关，如Gateway），门口有导览员（路由请求），拦着无关人员（鉴权），不用找多个入口。
◦ 店铺之间怎么协作？：比如奶茶店缺吸管，直接打电话给超市（服务通信，如Feign用HTTP调用、Dubbo用RPC），不用顾客帮忙转达。
◦ 某店铺人太多怎么办？：奶茶店满座时，门口放"暂停取号"牌（熔断降级，如Sentinel/Hystrix），避免顾客等太久，也防止奶茶店忙到崩溃。
◦ 所有店铺怎么统一改规则？：综合体贴"公告栏"（配置中心，如Nacos），改营业时间、促销活动（配置参数），所有店铺看公告就行（不用重启服务）。
- 主流微服务框架：
◦ Spring Cloud Netflix：早期主流，组件齐全（Eureka注册、Gateway网关、Feign通信、Hystrix熔断），但部分组件已停止更新。
◦ Spring Cloud Alibaba：当前主流，性能优、中文文档全（Nacos注册+配置、Sentinel熔断、Dubbo通信），适配国内场景。
◦ Spring Boot + Dubbo + ZooKeeper：轻量级组合，Dubbo负责高性能RPC通信，ZooKeeper负责服务注册与发现。
- Spring Cloud核心组件（综合体管理工具）：
◦ 注册中心：Nacos/Eureka（商户导览屏）------管理所有服务的地址、在线状态。
◦ 网关：Gateway（主入口导览员）------统一请求入口、路由分发、鉴权限流。
◦ 服务通信：Feign/Dubbo（店铺间电话）------实现服务间的远程调用。
◦ 熔断降级：Sentinel/Hystrix（暂停取号牌）------保护服务免受过载冲击。
◦ 配置中心：Nacos/Config（公告栏）------统一管理所有服务的配置参数。