企业官网建设流程全解析

面试这事儿，尤其大厂Java岗，网上经验帖一抓一大把，但大多数都停留在“背八股文”的层面。背题有没有用？有用，但只背不理解，面试官一追问就露馅。我自己这些年既被面过，也面过别人，一个很深的体会是：大厂面试官真正想考察的，不是你会不会背某个知识点，而是你面对一个具体技术场景时，能不能讲清楚“为什么选这个方案、不选那个方案、底层是怎么运作的”。

这篇文章我不打算给你罗列一份“XX道Java面试题大全”，那东西你随便搜一下就有。我想换个思路，从一条完整的成长路径出发——怎么从Java基础一步步走到能扛住微服务场景的追问。这条路径上的每一站，都是面试高发区，也是你日常工作真正会用到的能力。我会把每一站拆开，讲清楚核心考点、面试官常见的追问方式，以及你应该怎么组织自己的回答体系。

1. Java基础这道门槛：别只背结果，要能讲出“设计者的视角”

很多人在Java基础阶段犯的最大错误，是把知识点当结论背。比如问到HashMap，谁都知道“数组加链表，红黑树优化”，但面试官真正想听的，是为什么JDK 8要引入红黑树？为什么链表转红黑树的阈值是8？为什么加载因子是0.75？这些问题背后全是设计权衡，答得出来才说明你理解了这个数据结构。

1.1 集合类的高频战场：HashMap演变背后的设计逻辑

先从我面过最多的HashMap说起。这套题几乎每次必问，而且面试官的追问路径高度相似：

• 第一层：HashMap的底层结构是什么？
• 第二层：JDK 7和JDK 8有什么区别？为什么？
• 第三层：hash函数怎么设计的？为什么要高16位异或低16位？
• 第四层：扩容机制是怎样的？为什么是2的幂次方？
• 第五层：多线程环境下会出什么问题？

每一层都是一道题，但对面试官来说，前面几层只是热身，真正拉开差距的是第三层之后的问题。比如“为什么加载因子是0.75”，这背后涉及泊松分布的数学原理——当负载因子为0.75时，HashMap数组某个位置出现链表长度超过8的概率极低（大约千万分之六），所以红黑树的引入更多是一种极端情况下的兜底机制，而不是常规操作路径。

再比如说扩容。HashMap的初始容量是16，为什么是16而不是10？因为容量必须是2的幂次方，这样hash & (cap - 1)才能等同于取模运算，而且比取模快得多。如果你把初始容量设为10，HashMap会自动帮你调整为16。这个设计细节，面试官稍微一问就能测出你是真懂还是背过。

实际回答时，我建议你按这个逻辑组织：“HashMap选2的幂次方作为容量，是为了让哈希分布更均匀——通过位运算替代取模，同时减少哈希碰撞。”然后再展开讲扩容的细节，比如扩容后元素的位置要么在原位置，要么在原位置加旧容量——这个规律也是因为容量翻倍后，cap - 1在高位多了一个1，元素的新位置完全取决于原来hash值那个bit是0还是1。

1.2 并发编程的追问链路：从synchronized到AQS

并发是Java基础里最硬的一块骨头，也是大厂面试题里最密集的考点区。这块的面试题有个特点——层级非常分明。初级问法和高级问法完全不同：

• 初级：synchronized和ReentrantLock有什么区别？
• 中级：synchronized锁升级的过程是怎样的？什么是偏向锁、轻量级锁、重量级锁？
• 高级：AQS（AbstractQueuedSynchronizer）的原理是什么？CLH队列是怎么工作的？
• 骨灰级：你能否基于AQS自己实现一个限流器？

我建议你把这块当作一个整体来学，不要孤立地背锁的对比。核心逻辑是这样的：并发问题的本质是资源竞争，锁是用来控制竞争的，而不同的锁有不同的性能和适用场景。

拿synchronized来说，JDK 6做了重大优化，引入了锁升级机制。无锁状态下，线程首次访问时使用偏向锁，让同一个线程重复获取锁时不需要任何CAS操作；一旦有竞争，升级为轻量级锁，通过自旋（spinning）来等待锁释放；自旋超过一定次数或线程数过多，升级为重量级锁，进入操作系统内核的互斥量。这套机制的设计意图，是尽量在用户态解决锁竞争问题，避免频繁进入内核态——因为用户态到内核态的切换代价太大了。

而ReentrantLock底层的AQS，是一个更通用的并发工具骨架。它维护了一个volatile的state变量和一个FIFO的等待队列。acquire方法的基本逻辑是：尝试CAS更新state，成功则获取锁；失败则包装成Node节点加入等待队列，然后通过LockSupport.park挂起线程。整个设计把“同步状态的获取与释放”和“线程的阻塞与唤醒”解耦了，所以你可以基于AQS实现各种自定义同步工具——信号量、读写锁、CountDownLatch，全是这么来的。

面试到这一层，光背已经没用了，必须在纸上画一遍AQS的入队流程，把acquire-tryAcquire-addWaiter-acquireQueued这条调用链理清楚。

1.3 线程池与“线程等待都完成”的场景化问题

热搜词里有一条特别典型：java线程等待都完成。这其实是线程池面试的延伸场景。很多人只会背线程池的七大参数，真到了“怎么优雅地等待所有线程执行完”这个问题上就卡住了。

这里至少有四个层次的解决方案，我按从低到高的推荐度排一下：

大厂面试一般会从CountDownLatch问到CompletableFuture，特别爱问一个场景：“如果你有100个任务要并发执行，都完成后统一返回结果，你怎么设计？”这个问题考察的是你对ExecutorService.invokeAll、ForkJoinPool、CompletableFuture的理解深度。实际上，CompletableFuture是现代Java并发编程中最值得掌握的工具，因为它的链式调用和异步编排能力，是处理微服务场景下多个远程调用聚合问题的利器——比如同时调用用户服务、订单服务、商品服务，然后聚合成一个详情页响应返回给前端。

回答这类问题时，别一上来就写代码，先说清楚你的设计思路：用什么线程池、为什么用这个线程池、异常怎么处理、超时怎么兜底。这才是面试官想听的。

2. JVM这条线：从内存布局到线上故障排查的实战本事

JVM这块，很多人的准备方式就是背参数、背垃圾收集器对比。但大厂面试官真正想看的是，你有没有线上排查问题的实际能力。毕竟，JVM知识不是为了面试用的，而是你某天凌晨收到告警、服务OOM或者CPU飙高时用来救命的。

2.1 类加载与内存区域：基础分不能丢

类加载机制这块，常考的点是双亲委派模型——为什么需要这个模型？因为要保证Java核心类库的安全。比如你写了一个java.lang.String，如果不用双亲委派，它可能被随意加载，那JVM整个类型体系就乱套了。面试官会追一个问题：“有没有破坏双亲委派模型的场景？”这是一个经典追问，答案包括JDBC的SPI机制（Service Provider Interface）和Tomcat的Web应用类加载器——JDBC通过Thread.currentThread().getContextClassLoader()绕过了双亲委派，让应用层的驱动实现能被加载进来。

内存区域这块，我建议你用“线程私有 vs 线程共享”这个维度去记忆细分：

• 线程私有：虚拟机栈、本地方法栈、程序计数器
• 线程共享：堆、方法区（JDK 8后元空间替代了永久代）

这里的常见追问是：“为什么JDK 8要把永久代换成元空间？”核心原因是永久代的大小很难预测，而且它放在JVM堆内会导致内存溢出（OutOfMemoryError），换成元空间后，它使用本地内存，默认情况下不会OOM，由操作系统来管理。

2.2 垃圾回收：别再只背分代收集理论

GC的考点，最基础的是“分代收集理论”——新生代对象绝大多数朝生夕灭，老年代对象生命周期长。基于这个理论，JVM把堆分为新生代和老年代，新生代又分为Eden区和两个Survivor区，比例默认是8:1:1。为什么是两个Survivor？因为要解决内存碎片化问题——每次Minor GC后，存活对象从一个Survivor复制到另一个Survivor，然后清空Eden和当前Survivor，这种“复制算法”天然没有碎片。

再往上，G1收集器是面试的重头戏。G1的核心设计是把堆划分为多个大小相等的Region，然后跟踪每个Region的回收价值和回收成本，优先回收价值最大的Region——这就是Garbage First名字的由来。它还引入了RSet（Remembered Set）来处理跨Region引用，避免了全堆扫描。面试官特别爱问：“G1怎么做到可预测的停顿时间？”答案是-XX:MaxGCPauseMillis参数配合回收收益模型，但你要说清楚，这只是一个期望值，不是绝对保证。

实战层面的追问，我最常被问到的是：“线上OOM了你怎么排查？”这是一道综合题，我给出一条标准的排查链路：

1. 先看监控，确认OOM发生的容器、时间点，以及对应时间段内的QPS、GC频率等指标；
2. 保留现场，把-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path参数提前配上，OOM时自动导出堆转储文件；
3. 用MAT（Memory Analyzer Tool）分析堆转储，查看Dominator Tree，找出占用内存最大的对象；
4. 通过对象的引用链，定位到是哪段业务代码创建了这些对象；
5. 如果是内存泄漏，修复代码；如果是内存不足，评估是否需要调整堆大小或优化数据缓存策略。

这套链路里，第1步和第5步是最能体现经验的地方——很多人在第3步就找不出问题了，因为他们不知道MAT里Leak Suspects报告怎么看。

3. 从基础到Spring Boot：动态代理与ORM框架的底层解构

面试走到这一步，基础已经过关了，接下来就是看你能不能把它用到实际开发里。Spring Boot是Java后端开发的地基，而它最核心的两个底层支柱——动态代理和反射，恰恰是热搜词里“java动态代理”所指向的考察重点。

3.1 Spring AOP为什么一定要用动态代理

Spring的声明式事务、切面日志、权限校验，全部是AOP（Aspect Oriented Programming）的应用。而AOP的实现机制，就是动态代理。这里有两个分支：JDK动态代理和CGLIB动态代理。

• JDK动态代理：基于接口，通过Proxy.newProxyInstance()生成代理类，代理类实现了目标接口，并在InvocationHandler.invoke()方法中织入切面逻辑；
• CGLIB动态代理：基于继承，通过生成目标类的子类来代理，重写非final的方法并织入逻辑，不需要接口支持。

面试官最爱问的区分点是：“Spring到底什么时候用JDK代理、什么时候用CGLIB？”标准回答是——如果目标对象实现了接口，默认使用JDK动态代理；如果没有实现接口，则用CGLIB。但在Spring Boot 2.x之后，默认的代理策略改成了spring.aop.proxy-target-class=true，也就是即使有接口也优先用CGLIB，因为它避免了强制类型转换时的麻烦。

这里有个特别容易踩的坑，也是面试加分点：如果同一个类里的方法A调用方法B，而方法B上有事务注解或自定义AOP注解，事务会失效。这是因为Spring AOP的代理是外部调用时生效的，类内部this.methodB()调用的是原始对象的方法，根本没有经过代理。解决方式有三种：通过ApplicationContext.getBean()重新获取代理对象、使用AopContext.currentProxy()（需要配置exposeProxy=true）、或者把B方法拆分到另一个Bean里。

3.2 MyBatis与数据库访问：从JDBC到一条SQL的旅程

数据库访问层的面试重点，MyBatis是Java生态最常用的ORM框架之一。面试官爱从一个很基础的问题切入：“以你的经验来看，MyBatis一次SQL查询的完整流程是怎样的？”

完整的回答链是这样的：加载Mapper接口 → 通过JDK动态代理生成MapperProxy → 调用时根据方法签名找到对应的MappedStatement → 从SqlSource获取BoundSql → 通过ParameterHandler设置参数 → 通过StatementHandler执行SQL → 通过ResultSetHandler处理结果集映射 → 返回结果。这个链条里，最值得展开的是“参数设置”和“结果映射”两个环节——MyBatis怎么把Java对象的属性映射到SQL的#{}占位符上，又怎么通过反射把结果集的列值映射回JavaBean的字段。

追问方向通常有这几个：

• 一级缓存和二级缓存怎么工作？缓存失效场景有哪些？
• MyBatis的#{}和${}有什么区别？面试官必考。答案是：#{}是预编译占位符，会生成PreparedStatement的参数占位符?，能防SQL注入；${}是纯字符串替换，直接用值拼接SQL，存在注入风险。动态表名、动态列名这些场景才不得已用${}，而且必须做白名单校验。
• 接口里只有一个方法，为什么MyBatis能把它和XML里的SQL关联上？核心是MapperRegistry和MapperProxyFactory，启动时就扫描并注册了Mapper接口与XML的映射关系。

4. 微服务全景设计：从拆分的“科学”到服务治理的“艺术”

前面讲的基础、JVM、Spring Boot，是所有Java开发者的共同底盘。到了微服务阶段，面试的难度和维度会陡然上升——因为它不再问单个知识点，而是给你一个复杂的业务场景，让你做技术方案设计，然后针对方案中的每个模块层层追问。这就是标题里“从Java基础到微服务场景”的真正含义。

4.1 微服务拆分：先回答“要不要拆”，再回答“怎么拆”

微服务面试题的第一个坑，是很多人上来就谈技术组件、谈服务网格，但面试官其实想先听你怎么做服务拆分。拆分决策是架构设计的起点，也是最能体现经验的地方。

拆分的核心原则，我总结为四句话：

1. 以业务域为边界，而不是以技术为边界——按用户、订单、商品这样拆分，而不是按控制器、服务、DAO这样拆；
2. 体现“高内聚、低耦合”——一个服务内部的模块要高度相关，服务之间的依赖要尽量少；
3. 考虑团队组织架构——康威定律在微服务拆分中真实存在，两个团队共同维护一个服务的协作成本远高于拆分成本；
4. 拆分要符合业务演进节奏——不要为拆而拆，一个初期只有几十万用户的项目没必要一上来就搞二十个微服务。

面试官还会追问一个很实际的问题：“拆分时，哪些东西最难处理？”我的回答通常是三个：分布式事务、跨服务的数据一致性、以及分布式会话管理。这三个问题没有银弹，只能根据业务场景做取舍。这就要引出后面的技术组件了。

4.2 注册中心与配置中心：Nacos选型背后的逻辑

微服务架构图是热搜词里的高频词，说明很多人在准备“微服务全家桶”的技术选型。以国内大厂最常用的Spring Cloud Alibaba体系为例，几个核心组件的选型和原理是必考内容：

• 注册中心：Nacos vs Eureka vs Consul，怎么选？
• 配置中心：Nacos Config的配置实时刷新机制是怎么实现的？
• 服务调用：OpenFeign的工作原理？底层是HTTP调用还是RPC？
• 服务治理：Sentinel的限流、熔断、降级规则是怎么实现的？

我挨个说。先讲Nacos，它同时承担了注册中心和配置中心两个角色，在国内使用率极高，面试大概率会围绕它展开。

Nacos作为注册中心，核心是服务注册、服务发现、健康检查、监听通知这四件事。服务实例启动时，通过HTTP或gRPC向Nacos Server注册自身信息；客户端调用时，从Nacos拉取服务列表，本地缓存一份，同时建立长连接监听变更；一旦有服务上下线，Nacos会通过推拉结合的方式通知客户端更新。这里有个非常高频的追问：“注册中心是AP还是CP？”Nacos默认支持AP模式（保证可用性），同时支持切换到CP模式（保证一致性），这取决于你用临时实例还是持久化实例。临时实例走AP模式，心跳检测过期即剔除；持久化实例走CP模式，通过Raft协议保证一致性。

Nacos作为配置中心，核心是一个动态刷新机制。配置存储在服务端，客户端通过长轮询监听配置变更。长轮询的意思是：客户端发起请求后，服务端会持有连接一段时间（默认30秒），等待配置变更事件，在等待期间如果有变更就立即返回新配置，没有变更则等待超时后返回空响应，客户端随即发起下一轮轮询。这个机制看似简单，但@RefreshScope注解配合重写Bean的作用域，实现了运行时刷新配置而不用重启服务，值得你好好研究。

4.3 网关、熔断与链路追踪：微服务场景的经典追问

网关层，大厂面试一般会问Spring Cloud Gateway。它的核心是：WebFlux响应式编程 + Netty异步IO + 过滤器链。一个请求从客户端进来，先经过路由定位（Route），再经过一系列GlobalFilter执行前置过滤（如鉴权、限流、头信息处理），然后转发到下游服务，响应回来再执行后置过滤。考察点在于：网关的过滤器执行顺序怎么控制？订单号之类的公共参数怎么透传？跨域配置怎么做？

这里有一个非常值得注意的细节，也能体现你的实战经验：网关层千万不要做业务逻辑，它只负责路由、鉴权和横切关注点（Cross-Cutting Concerns）。一旦把业务逻辑写在网关里，你会面临巨难调试的问题，因为网关是整个系统的入口，任何故障都会被放大。

服务治理三件套——限流、熔断、降级，最常考Sentinel。我面试别人的时候特别爱问：“Sentinel的滑动窗口限流是怎么实现的？”这是一个很硬核的问题，核心思路是：把时间划分为一个个小的时间窗口，比如1秒钟切成2个500ms的窗口，每个窗口维护一个计数器。当请求进来时，根据当前时间定位到对应窗口，累加计数；同时计算当前时间所在窗口以及之前n-1个窗口的累计值，超过阈值即触发限流。滑动窗口比固定窗口的优势在于：可以避免临界问题——比如你限流100 QPS，固定窗口在第1秒的第1毫秒就来了100个请求，然后全部放行，第2秒还会再放100个，存在毛刺；滑动窗口能更平滑地控制速率，即使请求大量集中在窗口交界处，也能精确统计最近1秒的QPS。

熔断和降级，考察的是对“服务雪崩”的理解。一个服务挂了，调用它的上游服务拿不到响应，大量线程阻塞等待，线程池耗尽，然后上游也挂了，像多米诺骨牌一样连锁反应。熔断器（Circuit Breaker）的三个状态——关闭（Closed）、打开（Open）、半开（Half-Open），你要能画出来并解释清楚转换条件。尤其注意：熔断不是直接判死刑，半开状态下会放少量请求试水，如果成功率达到阈值，则慢慢恢复。

链路追踪，面试一般从日志聚合的角度切入。搜索词里没有直接出现，但“微服务架构”的综合题一定会涉及。你要了解Spring Cloud Sleuth与Zipkin的基本原理：为每个请求生成TraceId，在每个服务间传递，服务内的每个Span带有父子关系，最终通过Zipkin把整个链路串起来。没有这个，微服务环境下的线上排查就是大海捞针。这也是“从Java基础到微服务场景”的终极目的——你不再只是看日志查问题，而是能通过TraceId把一次请求从网关到最底层数据库的全过程串起来定位问题。

5. 微服务实战中的硬骨头：Swagger聚合、分布式事务与权限方案

面试进行到这一步，通常已经进入“场景设计”环节了。搜索引擎给的热搜词里，“微服务 整合 knife4j nacos”和“若依 微服务 使用 swagger”这两条非常具有代表性——看起来像是具体的集成配置问题，但背后折射出一个真实的分布式架构痛点：多个微服务各自有自己的接口文档，怎么在一个地方统一查看和调试？

5.1 Knife4j + Nacos：一个聚合接口文档的真实方案

我在实际项目中用过的方案是：每个微服务集成Knife4j（基于Swagger的增强UI），然后通过Nacos配置中心动态读取所有服务的文档地址，在一个聚合网关/文档中心统一访问。具体来说分为三步：

1. 每个微服务引入knife4j-micro-spring-boot-starter，配置自己的swagger.enabled=true和基础包扫描路径；
2. 在Nacos配置中心维护一份document-config，内容是所有服务的名称和对应的Swagger接口地址；
3. 文档中心服务监听这份配置，动态生成一个聚合页面，前端通过接口拉取所有服务的OpenAPI JSON，用Knife4j的Knife4jOpenApiCustomizer做合并展示。

这个方案的核心价值不是“怎么配”，而是它告诉你一个思路：在多服务环境下，所有需要在全局视角下查看的东西——文档、日志、监控——都应该走一次集中式设计，否则维护成本是服务数量的平方。面试谈到这个点时，你如果能说清楚“为什么要聚合”而不仅仅是“怎么聚合”，会超出面试官预期。

5.2 分布式事务：从两阶段提交到Seata的AT模式

分布式事务是微服务面试的第二道硬菜。经典问题：“一个电商下单流程，涉及订单服务、库存服务、积分服务，如果库存扣减成功但积分添加失败，怎么保证数据一致性？”

最基础的方案是两阶段提交（2PC）——协调者先向所有参与者发送Prepare请求，所有参与者都准备好后，协调者再发送Commit请求。但2PC有致命问题：同步阻塞、协调者单点、极端情况下可能不一致。所以实际业界很少直接用裸的2PC，而是用最终一致性的思路。

Seata的AT模式是目前国内最常用的方案。它的核心思想是：业务SQL执行前，先记录快照（undo log）；业务SQL执行过程中，使用全局锁保证并发安全；如果全局事务需要回滚，则通过undo log反向补偿，恢复原始数据。对比2PC的“预留资源”，AT模式是“执行SQL + 记录补偿日志”，更轻量，对业务代码的侵入性也更低。

但面试官会追问一个问题：“AT模式的全局锁怎么实现？性能损耗怎么样？高并发下不会成为瓶颈吗？”你要能解释：Seata协调者在事务提交前，会持有全局锁（具体是数据库记录上的锁），防止其他分支事务修改同一数据，事务提交后释放。在高并发场景下，全局锁确实是瓶颈，所以很多团队在核心链路会放弃强一致，改用消息队列+TCC（Try-Confirm-Cancel）或本地消息表，实现更平滑的吞吐量。

这里你可以提一句自己的理解：“没有万能的分布式事务方案，只有根据业务特点选型的方案——强一致要求高的走AT或TCC，能容忍短暂不一致的走消息最终一致，把方案和业务绑定起来才是面试官想听的答案。”

5.3 微服务权限：从JWT到Spring Security OAuth2的取舍

权限方案在微服务场景里也是提问率极高的点。单体时代，用Session+cookie就行；微服务时代，服务是无状态的，分发到哪个实例都可能，所以主流方案是JWT（JSON Web Token）。

JWT的核心优势是：服务端不存储会话状态，令牌本身就是身份凭证，验签即可。由于JWT的签名机制，服务端只需要持有密钥，就能验证令牌的完整性和真实性。但致命问题是：令牌签发后无法主动失效，除非设置短过期时间。面临泄露风险时，JWT的吊销非常麻烦。所以生产中常见做法是：JWT短期有效（比如15分钟），另配一个RefreshToken长期刷新，用户无感知地重新获取access token。

更完整的微服务权限方案是Spring Security OAuth2，统一认证中心负责登录和令牌颁发，各业务服务集成资源服务器（Resource Server）校验令牌权限。这个架构下，你只要理解两个关键点：令牌在哪里校验（资源服务器本地校验JWT签名，不远程调用认证中心）以及权限怎么做缓存（把用户的权限列表放进token里，避免每次请求都查数据库），就能应对大多数面试场景。

6. 一套可复制的面试备战节奏：从“知识”到“方案”的升维

最后一个部分，聊点更贴近实战的方法论。我见过太多候选人，技术底子不差，但面试表达没有章法，脑子里一堆知识点串不成体系，结果面试官问一个细节，他就陷在细节里出不来。应对大厂面试，知识点很重要，但组织知识的方式更重要。

6.1 用“场景-方案-原理”三层法组织你的知识简历

我建议把所有高频考题整理成一张表，每个知识点都按“场景-方案-原理”三层来总结。举几个例子：

这个方法的好处在于，面试官问任何一个主题，你都能从“为什么需要它”讲到“我用它解决过什么问题”再讲到“它底层是怎么工作的”，这个回答结构天然有层次感和真实感。

6.2 面试中怎么接住“你不会的问题”

还有一件必须练的事——接住不会的问题。

再厉害的人也会有知识盲区。我见过很多候选人被问倒后直接愣住，或者开始编。但我告诉你一个真相：面试官并不是要问倒你，而是想看你在面对未知问题时，思路是否清晰、能不能有逻辑地展开推理。正确的姿势是，明确告诉对方“这块我了解不多”，然后把自己能想到的相关联的知识讲出来，比如“我对XX不太熟，但我知道它和YY有相似之处，YY的原理是……如果我设计一个XX，我会从……入手。”这种“从已知推导未知”的能力，比背下一百道题更能打动面试官。

6.3 大厂面试最常见的能力盲区：工程化与项目复盘

最后特别提醒一个容易被忽视的盲区：基础题答得飞起，项目复盘却讲不清亮点。大厂面试的第三轮和第四轮，基本都是从你的项目经历出发，考察你的技术判断力和工程落地能力。项目复盘的几个关键问题，你提前想清楚：

• 这个项目的架构是怎么演进的？最开始是什么样，现在什么样，中间经历了什么？
• 你做过最有技术含量的优化是什么？衡量指标是什么？结果怎么样？为什么会想到这个方案？
• 做失败过哪些尝试？怎么发现的问题，怎么调整的？
• 如果要重做一遍，你会推翻哪些设计决策？

这几个问题答好了，比任何八股文都有说服力。它们考察的是你作为工程师的核心素养——问题定位能力、方案选型能力、复盘反思能力，这正是从“Java基础”走向“微服务架构”的路上，最能拉开差距的东西。

从我面试过的候选人情况看，能在这几个问题上讲出细节的人，往往不是背题最多的人，而是平时写代码时就会多问自己一句“为什么”的人。这种习惯，才是面对任何技术面试最稳定的底气。