企业官网建设流程全解析

大厂Java面试实战：Spring Boot与微服务场景深度解析

1. 大厂面试究竟在筛什么：基本功决定下限，工程判断决定上限

这两年帮朋友做了不少模拟面试，也看过几百份简历，一个很明显的感受是：Java面试早就不是"背熟八股文就能过"的阶段了，尤其是Spring Boot和微服务相关的岗位。面试官手里拿到的简历都写着"精通Spring Boot""主导过微服务拆分"，但两三句话一问，很多候选人连自己项目里一个接口从请求进来到响应出去，中间经过了哪些组件、哪些配置在起作用，都说不清楚。

大厂面试的筛选逻辑，本质上是在验证两件事：第一，你的基本功是否扎实到能解决线上问题；第二，你的工程判断是否成熟到能在复杂业务里做取舍。Spring Boot和微服务恰好是这两件事的最佳试金石，因为它们处于"框架封装好了"和"运维必须懂底层"的中间地带。

先说基本功。Spring Boot把SSH时代那些繁琐的XML配置全部干掉了，干掉的直接后果是很多人只会"双击启动、复制粘贴注解"，一旦遇到端口被占用、自动配置没生效、Bean循环依赖这类问题就手足无措。面试官问自动配置原理、问SpringFactoriesLoader机制，不是想考你背诵，而是想确认你在线上排查故障时能不能快速定位到问题源头。

再说工程判断。微服务不是拆得越细越好，也不是什么业务都必须上注册中心、配置中心。面试官问"你这个项目为什么拆成这么几个服务"，想听的是你对业务边界、团队规模、数据一致性成本的综合考量，而不是一句"微服务是趋势"。

这篇文章我会结合自己实际面试和被面试的经历，把Spring Boot和微服务场景下最常被追问的高频考点拆开讲一遍。内容不追求面面俱到，重点放在那些真正能拉开差距的实战细节上，比如自动配置的完整链路、服务拆分的边界判断、网关和接口设计的取舍、监控体系怎么落地。适合准备跳槽的Java工程师、正在带团队做技术选型的同学，以及所有想搞清楚"Spring Boot到底帮我做了什么"的人。

2. 自动配置与启动流程：一道能拉开差距的"基础题"

Spring Boot的自动配置，是面试必问但大多数候选人答不好的一题。很多人能说出"@EnableAutoConfiguration"这个注解，但再往下一层问"它怎么知道要加载哪些配置类""条件注解失效了怎么办"，就卡壳了。这一节我把整条链路拆开，顺便给一个自定义Starter的实战案例。

2.1 先理解Spring Boot启动时到底发生了什么

直接看代码。一个最简单的启动类长这样：

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

很多人不知道，@SpringBootApplication是一个组合注解，它由三个注解拼起来：

• @SpringBootConfiguration：本质上是@Configuration，标记这是一个配置类
• @EnableAutoConfiguration：开启自动配置，这是核心
• @ComponentScan：默认扫描启动类所在包及其子包下的@Component

面试官最喜欢从这里往深处挖。@ComponentScan默认扫描范围是谁？是启动类所在包的子包。很多人踩过这个坑：把启动类放在com.example.root，把业务代码放在com.example.business，结果Bean扫不到，项目启动就报错，或者Autowired直接注入失败。这就是没搞懂扫描范围的代价。

再看@EnableAutoConfiguration，它内部通过@Import引入了一个导入器：

@Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @AutoConfigurationPackage @Import(AutoConfigurationImportSelector.class) public @interface EnableAutoConfiguration { }

AutoConfigurationImportSelector会把所有jar包中META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件里列的配置类全部加载进来。注意，这里是"加载"，不是"生效"。

我面试的时候经常用一个类比：自动配置类就像一堆厨师候选人在厨房门口排队，AutoConfigurationImportSelector把他们都叫进来，但能真正掌勺的，必须符合条件。这个"条件"就是条件注解。

2.2 条件注解：自动配置的"门卫"

Spring Boot中有大量的条件注解，用来判断某个配置类是否生效。最常见的有：

这里有一个高频面试点：@ConditionalOnMissingBean到底是"没有才创建"还是"有就不用管"？答案是前者。Spring Boot设计了大量@ConditionalOnMissingBean，目的就是"给你默认实现，但允许你覆盖"。比如Jackson的ObjectMapper，Spring Boot默认配置了一个，但你完全可以自己定义一个新的，只要你定义了这个Bean，自动配置里的那个就退出了。

但有个细节很多人不知道：自动配置类的加载顺序是有讲究的。@AutoConfigureBefore、@AutoConfigureAfter、@AutoConfigureOrder这三个注解就是用来控制配置类之间顺序的。为什么需要顺序？因为有些自动配置依赖另一些自动配置产生的结果。典型例子是Spring Security的过滤链和Spring MVC的DispatcherServlet，顺序不对就可能导致URL匹配错乱。

2.3 条件注解失效的实战排查

面试官如果觉得前面这些你都答上来了，会追加一个实操题："你遇到自动配置没生效，会怎么排查？"这题答得好不好，直接体现你线上排障的能力。

我自己的排查路径是这样的：

1. 先看启动日志。Spring Boot 2.x以后的版本，启动日志里会打印自动配置报告，Positive matches是生效的，Negative matches是没生效的，Exclusions是被排除的。这是最直接的答案，很多人不知道。

2. 如果日志没开，可以在application.yml里配置开启：

debug: true

开启后控制台会输出自动配置报告。实际工作中这个配置非常管用，尤其是排查"我明明引入了Redis依赖，为什么自动配置没加载"这类问题。

3. 检查类路径。比如你想用Redis的自动配置，但项目的spring.factories或者AutoConfiguration.imports文件里没有对应条目，或者引入的starter版本太老、依赖被传递依赖排除了，都会导致自动配置根本不参与加载。

4. 确认条件注解的判断条件。例如你引入了spring-boot-starter-data-redis，但配置文件里没有spring.redis.host这些配置，大多数情况下Redis的自动配置还是会生效的，因为它走的是默认值。但如果你在启动类上手工排除了RedisAutoConfiguration，那么无论你怎么配置，它都不会加载。

还有一个非常现实的问题：同一个Bean被自动配置创建了，我自己也定义了一个，会发生什么？分两种情况。如果自动配置上标了@ConditionalOnMissingBean，它就不会重复创建。如果没标，那启动时就会抛出BeanDefinitionStoreException，提示bean name冲突。这种问题在引入第三方Starter时经常遇到。

2.4 自定义Starter：把"会背原理"变成"会实践"

面试中如果聊到这里，我建议你主动抛出一个自己做过的自定义Starter。哪怕只是一个公司内部用的小工具，也能让面试官对你的工程化能力刮目相看。

举个例子。假设我们内部有多个微服务都需要对接统一的限流组件，但不希望每个服务都写一套重复代码，就可以做一个限流Starter。

首先定义一个自动配置类：

@Configuration @ConditionalOnClass(RateLimiter.class) @ConditionalOnProperty(prefix = "ratelimit", name = "enabled", havingValue = "true", matchIfMissing = true) public class RateLimitAutoConfiguration { @Bean @ConditionalOnMissingBean public RateLimiter rateLimiter(@Value("${ratelimit.qps:100}") double qps) { return RateLimiter.create(qps); } @Bean public RateLimitInterceptor rateLimitInterceptor(RateLimiter rateLimiter) { return new RateLimitInterceptor(rateLimiter); } }

然后让Spring Boot能够加载它，在META-INF目录下创建AutoConfiguration.imports文件，写入：

com.example.ratelimit.RateLimitAutoConfiguration

这样任何服务只要引入这个Starter依赖，再配置ratelimit.enabled=true和ratelimit.qps=500，就能自动拥有限流能力。自定义Starter的价值在于：你亲手走了一遍Spring Boot"加载配置类-条件判断-创建Bean"的完整流程，这比背十遍原理都有说服力。

面试官接下来大概率会问："你这个限流Starter要处理多个服务共享数据的问题吗？"这就自然过渡到了微服务的分布式场景。要是你能接上"单机限流和分布式限流的区别，我们用了Redis + Lua脚本做分布式限流"，那这道题的深度立刻就出来了。

3. 服务拆分的边界感：以多商户跨境商城为例

微服务面试题里最高频的，就是"你的项目为什么拆成这样"。多数人上来就回答"我们用了微服务架构，有用户服务、订单服务、商品服务"，听起来没毛病，但经不起追问。面试官下一句就是："用户服务和订单服务为什么要分开？订单服务和支付服务之间是什么数据关系？拆完之后你遇到过哪些痛点？"

这一节我以多商户跨境商城这个典型场景为例，把拆分思路和数据一致性问题完整讲一遍。

3.1 按业务域拆是共识，但边界怎么划才是考点

多商户跨境商城，业务天然复杂。从用户端看，有买家端、卖家端、运营平台端。从业务流程看，涉及商户入驻、商品上架、订单交易、跨境支付、海关申报、物流履约、退款售后。如果一开始就并行拆成十几个服务，开发效率会非常低。

我的建议是分三步走。

第一步，先画业务域地图。把商城的完整业务链路梳理出来，按高内聚低耦合的原则划分域：用户域、店铺域、商品域、交易域、支付域、物流域、售后域。注意这里的"域"不是最终的服务，而是边界划分的参考。

第二步，评估域的独立性。看每个域是否有独立的生命周期和存储。比如商品域有商品的上下架节奏，订单域有订单的状态机流转，它们天然应该分开。而用户域虽然也独立，但用户信息和店铺信息经常一起查询，如果拆开，就要考虑join变两次查询的代价。这个时候要做取舍。

第三步，确定服务粒度。我推荐从"中等粒度"起步，比如把用户和店铺合并为"商家服务"，把商品和库存合并为"商品服务"，把订单、支付流程编排放到"交易服务"。项目初期服务数量控制在6到8个左右，等团队规模和技术积累上来之后，再考虑进一步拆分。

这里有一个很多面试候选人容易犯的错：把微服务拆分等同于技术炫技。面试官真正想听的是你有没有成本意识。拆得越细，运维成本、网络开销、数据一致性成本越高。你要能说出来"我们当时评估过，把库存单独拆出来会引入分布式锁的复杂度，所以初期选择放在商品服务内部"这种具体的理由。

3.2 拆分后的库存与订单：分布式事务避坑指南

多商户商城最典型的分布式事务场景，是下单扣库存。单独看下单流程：

1. 用户提交订单
2. 锁定商品库存
3. 创建订单记录
4. 发起支付

如果服务和数据库都在一个单体里，一个本地事务就能搞定。拆成商品服务和交易服务之后，锁库存和创建订单分属两个数据库，就成了分布式事务问题。

我见过太多项目直接上Seata、上消息事务，结果要么引入大量复杂配置，要么在极端场景下数据还是不对。面试里如果聊到这个点，建议按照"先规避、再治理"的思路来说。

规避的思路很简单：尽量让一个服务独立完成一条完整业务链。比如我们可以在交易服务里同时维护一份"可售库存"和"占用库存"，而商品服务只负责管理"总库存"的增量和同步。下单时，交易服务在自己库内事务里扣减可售库存并创建订单，这样本地事务就能保证一致性。至于商品服务里的总库存，通过异步消息去同步。

但这种方案有一个前提：一个商品只能在一个交易服务内售卖。如果未来有渠道拆分，一个商品同时在多个平台售卖，那还是得回到分布式锁和分布式事务的套路上来。

如果必须跨服务强一致，比如"库存必须严格防超卖"，那就要用到分布式锁。我推荐Redis + Lua脚本的方案，而不是直接用Redisson的分布式锁了事。原因在于，Redisson默认的锁是基于可重入的，要考虑锁续期、看门狗机制、Redis主从切换时锁丢失的问题。而Lua脚本可以在单节点上原子地完成"检查库存-扣减库存"两步操作，性能高且逻辑可控：

-- KEYS[1]: stock:1001 -- ARGV[1]: 扣减数量 local stock = tonumber(redis.call('get', KEYS[1])) if not stock or stock < tonumber(ARGV[1]) then return -1 end redis.call('decrby', KEYS[1], ARGV[1]) return stock - tonumber(ARGV[1])

这个脚本的细节很值得在面试中展开：为什么用decrby而不是先get再set？为什么扣减在Redis做而不直接在数据库做？扣减成功之后如果订单没创建怎么补偿？你会说"用逆操作incrby补偿，或者通过定时任务对账把超时未支付的订单库存回滚"，面试官就会觉得你具备完整的闭环思维。

3.3 行级权限：多租户系统里绕不开的设计题

热搜词里出现了"行级权限java"，这让我想起多商户商城里一个真实的痛点。每个商户运营人员只能看到自己店铺的数据，不能看到其他店铺的，这就是行级权限。很多初级工程师把它做成了"查询条件里硬拼where"：

SELECT * FROM order WHERE seller_id = ?

这确实能实现，但风险很大：只要开发人员有一次忘记在SQL里带seller_id，就会造成越权数据泄露。大厂面试对权限这块非常看重，因为这是安全事故高发点。

可落地的方案是MyBatis的拦截器+自定义注解。做一个@TenantIgnore注解，然后在MyBatis的Interceptor里拦截SQL语句，通过JSqlParser解析SQL，自动给所有查询和删除语句追加tenant_id条件：

@Intercepts({ @Signature(type = Executor.class, method = "update", args = {MappedStatement.class, Object.class}), @Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}) }) public class TenantInterceptor implements Interceptor { @Override public Object intercept(Invocation invocation) throws Throwable { // 获取当前登录用户上下文，拿到tenantId // 修改BoundSql，追加 where tenant_id = ? // 放行 } }

这个方案的要点是"用户上下文"。你需要在网关或者过滤器里解析token，把商户ID塞到ThreadLocal里，然后拦截器从ThreadLocal取。但要注意线程池的问题——子线程拿不到父线程的ThreadLocal值，那就需要用TransmittableThreadLocal或者把tenantId放到RPC调用的Header里透传。这个细节面试官一定会追问，你提前答出来，印象分直接拉满。

3.4 定时任务框架选型：别忘了分布式锁

多商户商城里的定时任务非常多：订单超时关闭、自动确认收货、跨境结算日切。热搜词里的"java定时任务框架"对应的就是这类场景。

单体时代用Spring的@Scheduled就够了，但微服务下如果多个服务实例同时跑同一个定时任务，就会造成重复执行。解决方案就是让定时任务和分布式锁配合。

我常用的是XXL-JOB。它本身就解决了"同一个任务只能在一个执行器上跑"的问题，自带调度中心、失败重试、任务监控。对中小团队来说，比自己去实现Quartz集群要省心得多。

如果不想引入额外中间件，用Spring @Scheduled + Redis分布式锁也能做，关键是锁的粒度要设置对。比如"订单超时关闭"这个任务，不能只锁一个"orderCloseJob"全局锁然后跑完所有订单，那样当单量大了，锁时间过长，其他服务要一直等。更好的做法是对具体数据加锁，或者用"分片"参数。XXL-JOB支持给每个执行器分配分片序号，每个分片只处理一部分数据，这个设计能很好避免大任务把所有执行器都占满的问题。

面试中能把"定时任务不是写个cron就行，要考虑分布式环境下的重复执行和分片消费"讲清楚，比单纯说"我用过XXL-JOB"有分量得多。

4. 服务间通信与网关：数据通信网络视角下的接口设计

微服务架构里，服务之间怎么通信，本质上是在问"你的数据通信网络是怎么设计的"。这个话题在热搜词里反复出现，可见是面试官关注的重点。面试常见问法有几种：Feign和Dubbo怎么选？HTTP调用和消息队列怎么搭配？网关层应该做什么？对外接口应该放哪。

4.1 同步RPC和异步消息的边界

我建议先把同步调用和异步消息的适用场景想清楚，这是数据通信网络设计的基础。

同步调用（Feign、RestTemplate、Dubbo）适合"需要立即知道结果"的场景。比如查询订单详情时，需要同时查询用户信息、店铺信息、商品信息，这些跨服务的查询用同步调用最自然。但同步调用有个致命问题：链路变长后，任何一个下游服务慢，整个接口都会变慢。我在商城项目里踩过这个坑，一个下单接口，因为调用了支付服务、积分服务、优惠券服务、风控服务，链路串行了，P99延迟从80ms涨到800ms，后来通过超时配置和并行调用才解决。

异步消息（RocketMQ、Kafka）适合"不需要立即知道结果"的场景。比如下单成功后发短信通知、积分累计、数据埋点。这些操作失败不能影响主链路，用MQ削峰填谷再合适不过。

面试官如果问"你们下单后怎么做缓存更新"，标准回答是"用MQ异步通知商品服务刷新缓存"。但你要能接着说"缓存最终一致性的问题怎么兜底——通过定时对账重新拉取"。

还有一点很重要：不要在事务里同步发MQ。如果下单本地事务还没提交，你就把"下单成功"的消息发出去了，消费者去查订单会发现查不到。正确做法有两种：一是事务消息（RocketMQ支持），二是本地消息表，先写一条本地消息记录，事务提交后再由定时任务发送并标记状态。

4.2 网关层：不该只做路由转发

很多同学说起网关就只剩一句话："我们用Spring Cloud Gateway做路由转发"。这远远不够。网关在大厂实践中承担的功能远不止路由，它是整个数据通信网络的门户。

从实际落地来看，网关至少要做这四件事：

1. 认证与鉴权。网关统一解析JWT，校验登录状态和基本权限，避免每个服务都写一遍token解析逻辑。但要注意，RPC调用的内部接口和对外接口要用不同的鉴权力度，别让内部服务暴露到公网上。

2. 动态路由与灰度发布。网关层面的灰度策略，支持按Header、按用户ID、按流量比例把请求打到不同的服务版本上。这是大厂发布过程中必须具备的能力。

3. 限流与熔断。网关层做全局限流，比每个服务单独限流更有效。常用的算法有令牌桶和滑动窗口，落地用Redis + Lua或者Sentinel。网关的限流值要设置好，不能设得太小影响正常业务，也不能设太大起不到保护作用。我一般把网关限流设置为预估峰值流量的1.5倍，同时给每个核心服务设置自己的更严格的限流阈值。

4. 日志与链路追踪。网关是统一的入口，所有请求从这里进出，非常适合记录请求日志、耗时分布、异常率。配合链路追踪，能快速定位是哪个服务拖慢了整条链路。

这里插一句，热搜词里的"数据通信网络与微服务"让我想起一个容易被忽视的点：网关的超时设置一定要大于下游所有服务的最大超时之和。我们线上出过一次事故，网关默认超时配置是30秒，但一个新上线的服务里有个接口因为慢SQL要跑50秒才返回，结果网关把请求掐断了，客户端看到的是网关报错，排查了很久都不知道问题出在服务内部。后来我把网关超时策略改成：网关超时 = 下游服务超时 + 5秒缓冲，并严格控制自定义超时配置。

4.3 对外接口要独立成服务吗：先算账再回答

热搜词里有个很实际的问题："Spring Boot对外提供的接口应该放在哪里？是单独的服务还是放在对应的业务服务里？"这个问题在面试中也很常见，它考的是你能不能跳出技术纯粹从工程成本角度思考。

先说我的结论：小额、低频的对外接口，可以放在原业务服务里，通过网关单独暴露；高频、大流量、需要独立鉴权或者被多个渠道共用的对外接口，建议独立成OpenAPI服务。

举个例子。商户平台对外开放了"查询店铺订单"接口，这个接口主要给商户自己的ERP系统调用，频率不高。放店铺服务里，在网关配一条路由规则就够了。但如果我们要对外开放一个"批量同步商品"的API，面向大量第三方ERP服务商，量非常大，而且每个ERP服务商需要不同的令牌、不同的限流配额、可能需要签名验签，那一定要独立成OpenAPI服务，专门处理接入方管理、密钥管理、调用统计、数据格式转换。

独立的OpenAPI服务还能隔离安全问题。如果有漏洞，攻击者打进来也只能访问OpenAPI服务，不会威胁到核心交易服务。这个思路面试中一定要表达出来，它体现的是风险意识和架构分层能力。

另外，对外接口要非常谨慎地设计版本策略。建议接口路径从一开始就带上版本号，比如/v1/orders、/v2/orders。这样后续升级接口不破坏已有调用方。我在面试中经常问"你手上有老接口，返回字段不够用，但改造会破坏已有客户，怎么办？"，能答出来"加版本号、新老并存、逐步迁移"的候选人，基本能达到P6的水平。

5. 监控体系与线上排障：面试最后四十分钟常考的"实战题"

热搜词里出现了"spring boot admin""spring boot实现监控，都有哪些需求和功能?"，这说明很多人在准备面试时都在关注监控相关的内容。大厂面试最后二十分钟，面试官往往会切换到实战模式，给一个线上故障让你排查，监控就是你说清楚排查思路的前提。

5.1 Spring Boot Admin能做什么，不能做什么

Spring Boot Admin是一套基于Actuator的监控管理UI，能看应用健康状态、内存占用、线程池、日志级别等。它解决的是"应用可见性"的问题。

实际部署时，一般分两步。服务端搭建一个Admin Server：

<dependency> <groupId>de.codecentric</groupId> <artifactId>spring-boot-admin-starter-server</artifactId> </dependency>

客户端引入starter-client，然后在配置文件里注册到Admin Server：

spring: boot: admin: client: url: http://admin-server:8080 management: endpoints: web: exposure: include: "*"

这样监控页面就能实时看到所有服务实例的运行状态。遇到内存告警、健康检查失败，可以快速定位到具体实例。

但说实话，Admin在真正的大规模生产环境里只是一个辅助工具。它的局限性在于：第一，它做不了历史趋势分析，数据是实时的，重启就丢失了；第二，它做不了跨服务的链路追踪，一个请求经过三个服务，它只能看到每个服务各自的指标。所以大厂在Spring Boot Admin之外，一定还会上Prometheus + Grafana做指标采集和可视化，上SkyWalking或者Jaeger做链路追踪，上ELK做日志聚合分析。

面试时如果只答"我们用了Spring Boot Admin"，显得单薄。更好的回答是："我们用Admin做基础健康检查和快速定位，用Prometheus + Grafana做核心指标的长期趋势，用SkyWalking做调用链分析，三个层级互相补充。"这个回答会让面试官觉得你有完整的监控体系思维。

5.2 线上故障排查，从监控指标到根因定位

面试官给一个线上故障：下单接口突然超时率上升，你怎么排查？

我的排查思路是"从整体到局部，从监控到日志，逐层收敛"。

第一步，看全局监控。打开Grafana，看整个网关的QPS、成功率、P99延迟。如果整体成功率下降，说明不是单个用户问题，而是系统级故障。再看是哪个服务的P99飙升。这里要留意：P99和平均耗时都要看，平均耗时可能被极少数超长请求拉高，P99能更好反映大多数用户的真实体验。

第二步，看资源指标。目标服务的CPU、内存、GC频率和耗时。如果YGC频繁并且耗时增大，说明有大量临时对象产生，可能是数据序列化问题。如果FGC频繁，怀疑堆内存不足，需要dump堆转储文件分析大对象。

第三步，看慢查询和日志。数据库层面看慢SQL日志，接口层面看该服务日志里有没有Exception。经常会发现真正的根因是"下游Redis响应慢"，而Redis慢根因往往是"大key的频繁删除导致阻塞"。

第四步，看链路追踪。SkyWalking上找到这一时段下单请求的调用链，逐段看每个Span的耗时。如果发现订单服务调支付服务耗时2秒，而支付服务是正常的，那多半是订单服务自身的问题，比如线程池满了导致排队，或者Feign连接池不够用。

面试中把整个思路讲清楚：监控发现异常 -> 资源指标定位 -> 日志/慢SQL深挖 -> 链路追踪确认。即使没有运维大厂的经验，也会让人觉得你具备系统的排障能力。

5.3 端口号与启动失败：基础问题别丢分

热搜词里有"spring boot修改demo 端口号""java启动失败怎么解决"，这些看起来太基础，但面试中出现的频率意外地高。很多候选人不会当回事，可当面试官让现场改一下端口并启动，好多人反而栽了。

修改端口就一行配置：

server: port: 8081

但如果用打包后的jar启动，想临时换端口：

java -jar app.jar --server.port=8082

启动失败最常见的几个原因：

• 端口被占用。用netstat -ano | findstr 8080（Windows）或lsof -i:8080（Linux）查进程，kill掉或者换端口。
• Bean重复定义或者循环依赖。看异常栈里有没有BeanCurrentlyInCreationException，出现循环依赖要考虑通过@Lazy或者拆分类解决。
• 自动配置加载了不该加载的配置，比如引入了spring-boot-starter-data-redis但Redis服务没启动，启动时连接不到Redis，健康检查失败直接退出。
• 数据库连接池初始化失败。往往是因为数据库地址配错或者密码带特殊字符没转义，启动时初始化数据源报错。

如果你在面试中能把这些场景答出来，并同时说出对应的排查命令，基础分就稳了。不要小看这些"基础问题"，很多人拿到大厂offer，靠的就是最后这些别人不屑于准备的点。

6. 面试最后的反问环节：一个能体现架构思维的问题列表

面试最后，面试官通常会问："你有什么想问我的？"很多人回答说"没有"，浪费了这个加分机会。实际上，这个问题问得好，能直接展示你的技术视野和面对复杂业务的思考方式。

我结合Spring Boot与微服务场景，列几个我自己作为面试官时比较欣赏的反问：

1. "我们这个团队目前微服务拆到什么程度，核心服务的QPS在什么量级，主要是靠什么手段保障稳定性？" 这个问题表明你关心真实业务规模，而不是只关心技术名词。

2. "服务间的数据一致性是怎么处理的？哪些场景用了事务消息，哪些场景用了对账补偿？"这个问题说明你懂分布式事务不会只有一种解法。

3. "监控告警和值班机制是怎样的？线上问题一般多久能发现？"这不仅显示你关心运维体系，也暗示你是一个对线上负责的人。

4. "团队对新人有怎样的Code Review机制？"这个问题体现了你对工程质量的重视。

5. "目前有没有计划升级到Spring Boot 3和JDK 17？遇到过哪些兼容性问题？"这个问题说明你关注技术演进，也懂升级背后的成本。

反问环节把握住一个原则：不要问那些能在官网文档里查到答案的问题，要问那些需要亲历才能回答的问题。好的反问能让你在面评里留下"这个人有主见、有深度"的印象。

最后，聊点个人体会。我在准备面试和参与面试的过程中最大的感受是：Spring Boot和微服务这套技术栈，真正的分水岭不在你知道多少注解，而在于你能不能把"框架帮你做的事"和"你必须自己做的事"分清楚。框架帮你做了自动配置、帮你简化了开发流程，但服务拆分的边界、数据一致性的取舍、监控体系的搭建、线上问题的排查，每一件都需要你自己做判断。面试官要招的不是"熟悉Spring Boot的人"，而是"能用Spring Boot解决实际问题的人"。

所以，与其去背那些抽象的概念，不如把时间花在两件事上：一是把自己项目里的架构画清楚，知道每个请求经过哪些服务、哪些配置在起作用；二是多复盘线上踩过的坑，把每个坑的根因和排查过程记录下来。面试真正考的不是你会的多，而是你踩过的坑、填过的坑、总结出来的经验，能不能变成一套可复用的方法论。把这些想明白，面试就是你展示价值的舞台，而不是被动挨问的考场。