上周帮团队做技术终面，一位候选人简历上写着“精通微服务架构，熟悉AI应用”，结果我问了三个问题——“你们服务拆分的时候，订单和库存的数据一致性怎么保证？”“Sentinel的限流和Hystrix的线程池隔离有什么本质区别？”“你在Java项目里接入AI时，权限控制怎么做？”——他支支吾吾，最后只憋出一句“这些我们项目里其实没用过”。这种落差我见得太多了。
这篇文章不是面试押题，而是我用实际面人和被面经验整理的一套大厂Java面试实战思路，覆盖核心技术基础、微服务架构、AI应用三条主线。适合准备跳槽的Java后端开发、想系统梳理知识体系的校招同学，也适合那些想把手头CRUD项目升级成能拿出手的微服务项目的朋友。我会尽量把每一个知识点都拆到“面试官为什么这样问”的层面，而不是单纯的答案背诵。
1. 大厂面试官真正在考察什么：别把“背题”当“能力”
1.1 简历上的“精通”和现场回答的落差
我面过不少三年经验左右的候选人，简历上的技术栈密密麻麻：Nginx、Redis、Kafka、Dubbo、Sentinel，清一色写着“熟练使用”。但只要我开始深入追问，比如“Redis为什么快”“Kafka的ack机制到底应该选all还是1”“Sentinel和Resilience4j的限流有什么区别”，很多人就只能开始讲概念，一讲概念就露馅，因为概念下面没有真实项目经验的支撑。
这其实不是学习态度问题，而是大多数人的项目确实只停留在“部署过”和“调用过”。Spring Cloud搭起来了，注册中心连上了，OpenFeign能调通了，就认为自己精通微服务。但面试官想看到的不是你会搭脚手架，而是当线上服务出现雪崩、数据不一致、接口超时的时候，你有没有自己的排查套路和方案取舍。这一点决定了你是P5还是P6，也决定了你能不能过终面。
所以第一件事是：把简历里的每一个技术点都准备成“为什么选它”和“线上踩过什么坑”。比如写了“使用Redis缓存”，那就要能回答：缓存和数据库不一致时你怎么处理？缓存穿透怎么解决？布隆过滤器的误判率怎么调？这套追问链才是“深度”，背再多的八股文都替代不了。
1.2 面试的评判框架：深度、广度与工程判断
从面试官的角度，我评价一个候选人通常看三个维度。第一是基础深度：Java语言特性、集合源码、并发、JVM、数据结构、网络，这些决定了一个人能走多远。第二是技术广度：你用过哪些中间件，了解哪些开源方案，能不能在不同的业务场景里做选型。第三是工程判断：面对一个模糊的业务问题，你会怎么拆解、怎么识别风险、怎么给出可落地的方案。很多人前两项不错，第三项基本是空白。
举个例子，我常问一道开放题：“假设你们的支付对账系统每天凌晨跑批，最近经常在高峰期超时，你怎么排查？”如果候选人一上来就说“加机器”，那基本没戏。合理的回答路径是先看监控：超时发生在哪个环节？是数据库慢查询还是下游接口抖动？是CPU内存问题还是锁等待？然后根据现象缩小怀疑面，再谈具体优化。这种“从现象到假设，再到验证”的工程思维，是面试里最稀缺的东西。
另外，面试官还会非常在意候选人的表达方式。清晰的分点、适当的停顿、承认自己不会的坦诚，比强行圆一个错误答案要好得多。面试不是考试，是一次技术对话，你能把面试官聊到点头，这场面试就成了一大半。
2. 核心技术基础：Java语言特性、集合、并发与JVM的追问链条
2.1 语言特性：从静态链接到面向对象的本质
最近热搜里有个说法叫“java是静态链接的”，我看到就有点想笑。如果准备面试，一定要分清楚“静态类型”和“动态链接”这两个概念。Java是静态类型语言，编译期会做类型检查；但Java的类加载过程包括加载、验证、准备、解析、初始化，其中解析阶段是把符号引用替换为直接引用，这个过程是运行时动态完成的。所以严格说，Java在JVM层面是动态链接的，在类型系统层面是静态的。能把这个区别讲明白，已经能超过一大半候选人。
面向对象三大特性也是必问。封装、继承、多态分别解决什么问题？多态的本质是动态绑定，方法分派发生在运行时。如果面试官让你结合Spring AOP讲，你要能说到动态代理和CGLIB的区别：JDK动态代理基于接口，CGLIB基于继承，Spring默认在Bean有接口时用JDK代理，没有接口时用CGLIB。这一串追下去，就是一套完整的“Java语言特性”追问链。
再补一个经典题：写一个线程安全的单例。很多人的标准答案是双重检查锁，但会忽略volatile。为什么需要volatile？因为对象的创建在指令层面不是原子的，可能出现“分配内存、返回引用、初始化字段”被重排，导致另一个线程拿到一个未初始化完成的对象。这个点能讲透，说明你对并发模型是有真实理解的。
2.2 集合源码：HashMap、容器初始化与扩容细节
大厂必问HashMap，几乎不用怀疑。从JDK7到JDK8，最大的变化是当链表长度超过阈值8时转成红黑树。为什么要转？最直接的原因是防哈希碰撞，让查询从O(n)降到O(logn)。但为什么是8？网上流传的泊松分布解释是一个概率依据，实际还要综合考虑节点大小和扩容时的退化成本。面试时能说出“链表和红黑树之间有转换阈值，扩容后有可能会退化成链表”就已经很好了。
HashMap的初始容量为什么是16？扩容为什么是2倍？因为把元素放到数组下标时用的是(n - 1) & hash，这个位运算只有在n是2的幂时才等价于取模hash % n，而且位运算是CPU级操作，性能更高。如果面试官继续问“new HashMap(1000)实际初始容量是多少”，答案是1024，因为JDK会把传入的容量向上取整到最近的2的幂。
ConcurrentHashMap也是必问。JDK8把JDK7的分段锁改成CAS加synchronized锁头节点，锁粒度更细，大多数读操作是CAS，写操作只在头节点加锁。HashTable全程synchronized，并发能力很差，基本被淘汰。顺带把“java容器”这个热词带进来：ArrayList和LinkedList怎么选，ArrayList扩容为什么是1.5倍，迭代时删除元素会抛ConcurrentModificationException的原理——这些都是高频小题。
2.3 并发与线程池：为什么“手写多线程”总是翻车
并发是Java面试的重灾区，线程池又是最常见的切入点。七个参数必须刻在脑子里：corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler。提交任务的执行顺序是：先创建核心线程执行，核心线程满了进队列，队列满了再创建非核心线程，非核心线程也满了才触发拒绝策略。很多人会把队列和最大线程的顺序记反，这题一错基本就告别这个offer了。
阿里规范为什么不建议用Executors.newFixedThreadPool？因为它的workQueue是无界的LinkedBlockingQueue，任务堆积多了会导致OOM。正确的做法是让你自己根据业务选择有界队列，配合明确的拒绝策略。拒绝策略有四种：AbortPolicy直接抛异常，CallerRunsPolicy让提交线程自己执行任务，DiscardPolicy静默丢弃，DiscardOldestPolicy丢弃最老的任务。如果你能补充“CallerRunsPolicy在流量过大时能起到天然背压作用”，面试官大概率会眼前一亮。
volatile和synchronized的区别要能说透。volatile保证可见性和禁止指令重排，但不保证原子性；synchronized是互斥锁，保证原子性和可见性。CAS是什么？比较并交换，属于乐观锁思路，但会有ABA问题，AtomicStampedReference用版本号解决。这一串追下去，足够聊二十分钟，而且每一环都能继续展开。
2.4 JVM与性能调优：Java环境变量与内存模型
JVM问题几乎是终面必聊。先背清楚内存模型：堆、虚拟机栈、本地方法栈、方法区、程序计数器。JDK8以后用元空间代替永久代，把字符串常量和类元数据挪到了本地内存，避免了永久代大小固定导致的老年代OOM。如果面试官问你“元空间为什么移到本地内存”，最核心的答案是永久代大小固定、容易出现 OOM，而元空间受本机物理内存限制，理论上不容易爆。
垃圾收集算法也要熟悉：新生代用标记-复制，老年代用标记-整理或者CMS并发清除。G1的核心思路是把堆分成一个个Region，通过可预测的停顿时间模型来决定回收优先顺序；ZGC的目标是把停顿时间压到毫秒级。实际线上排错时，至少要知道jstat看GC情况、jmap导堆快照、jstack看线程栈。不要只背命令，要说一次真实的OOM排查经历。
环境变量这块，热搜词里有个“java环境变量配置详细教程”，面试其实很少直接考，但工作里特别重要。我给出一个Linux下常用的配置示例：
export JAVA_HOME=/usr/local/java/jdk-17 export PATH=$JAVA_HOME/bin:$PATH export MAVEN_OPTS="-Xms512m -Xmx1024m"很多人配完JAVA_HOME不刷新，或者忘了给Maven和IDEA设置内存参数，导致编译慢、构建OOM。面试时如果能顺口说出“通过设置-XX:+HeapDumpOnOutOfMemoryError在OOM时自动导出堆快照”，这比单纯背JVM分区要务实得多。
3. 微服务架构：从单体拆分到流量治理的完整链路
3.1 服务拆分思路与微服务架构最新开源组件选择
微服务面试的第一步就是“拆”服务。拆分不是纯技术问题，而是业务和团队组织的映射。我做过电商后端，把用户、商品、订单、支付、库存、营销拆成独立服务，每个服务独立数据库，跨服务调用通过OpenFeign或Dubbo。如果面试官问“你们拆的依据是什么”，你可以说按领域驱动设计里的限界上下文拆，按变更频率拆，按团队结构拆，这样一个团队对一段业务的完整生命周期负责，迭代速度才快。
热搜里有个“微服务架构最新2026开源项目”，我虽然不知道2026年会出现什么新玩具，但可以聊聊我近期关注的生态趋势：Spring Cloud Alibaba依然活跃，Nacos做注册和配置中心，Sentinel做流量治理，Seata做分布式事务；云原生这边，Kubernetes加Istio Service Mesh正在成为复杂微服务治理的另一个答案。面试时不需要标榜“最新”，但一定要能表达出你对生态演进的判断：Spring Cloud和Dubbo的对比，k8s和传统微服务框架的边界，这才是积累。
我常用的组件选型可以整理成一张表，面试时直接拿出来讲：
| 关注点 | 可选组件 | 我的选择 |
|---|---|---|
| 注册中心/配置中心 | Nacos、Eureka、Consul | Nacos |
| 服务调用 | OpenFeign、Dubbo、gRPC | Dubbo（性能优先） |
| 流量治理 | Sentinel、Hystrix、Resilience4j | Sentinel |
| 分布式事务 | Seata、RocketMQ事务消息 | Seata |
| 网关 | Spring Cloud Gateway、Zuul | Gateway |
选型没有绝对对错，关键是说出理由。比如我选Nacos，是因为Eureka 2.x停更，Consul在配置中心能力上不如Nacos直接，而Nacos同时支持AP和CP模式切换，社区也活跃。
3.2 注册中心、配置中心与网关的选型逻辑
注册中心的核心是服务发现。Nacos支持临时实例和持久化实例，临时实例用临时节点，下线后自动删除；持久化实例适合需要对外稳定提供的服务。面试官常问“AP和CP的区别”，答案是CAP理论：AP保证可用性，发生网络分区时每个节点仍然可用，但可能出现短时间数据不一致；CP保证一致性，分区时为了保证一致会拒绝写入。分布式系统里没有银弹，Nacos允许你在AP和CP之间切换，注册中心一般选AP，配置中心一般更偏向CP。
网关选型方面，Spring Cloud Gateway底层是Netty，响应式非阻塞，性能比Zuul 1.x好很多。如果面试官问“Gateway和Feign的区别”，你要说清楚：网关是流量入口，处理的是外部请求的路由、认证、限流、灰度；Feign是服务间的声明式HTTP客户端，处理的是内部调用。这是两个层面的事，很多人混在一起，一听就是没踩过真实的坑。
下面是一个Spring Cloud Gateway的路由配置，非常简单，但面试时能讲清楚每个字段的含义很重要：
spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path=/api/order/** filters: - StripPrefix=1lb://order-service的意思是走负载均衡，从注册中心拿到order-service的实例列表，再做转发。StripPrefix=1表示去掉请求路径前缀/api。如果面试官追问“网关怎么做限流”，你还需要答出RequestRateLimiter过滤器里的令牌桶参数配置。
3.3 分布式数据一致性：从CAP到分布式事务方案
“Java怎么保证数据一致性”这个热搜词特别典型，说明很多人在实际项目里被这东西折磨过。一致性其实分为两个层面：一个是缓存和数据库的一致性，另一个是跨服务的分布式事务。
先讲缓存双写。最常用的是Cache Aside模式：读时先读缓存，没有就查库再回填；写时先更新数据库，再删除缓存。为什么不更新缓存而是删除缓存？因为并发场景下更新缓存容易产生脏数据，删除缓存后下一次读会重新回填。另一个细节是“先删缓存再更新DB”会导致缓存击穿，所以更稳妥的顺序是“先更新DB再删缓存”，配合延迟双删来兜底删除失败的情况。
再讲分布式事务。CAP和BASE要能流利回答，然后重点选一种方案讲透。我习惯拿TCC举例：Try阶段锁定库存并创建订单草稿，Confirm阶段确认扣减，Cancel阶段释放库存。如果不想写太多补偿代码，可以用Seata的AT模式，它自动生成undo log，业务侵入小。还有一个思路是RocketMQ事务消息，发送half消息后执行本地事务，再提交commit，利用消息队列完成最终一致性。面试只要能完整讲出一种方案，并说清它的适用场景和限制，就比背一堆方案名字强得多。
3.4 熔断、限流、降级：高并发场景的自我保护
微服务之间调用，最怕的就是雪崩。一个下游节点变慢，上游线程池被占满，然后继续拖垮下一个上游，最后整个系统瘫痪。所以要靠三种手段保护自己：限流、熔断、降级。
限流算法要能说出固定窗口、滑动窗口、令牌桶、漏桶。Sentinel用的是滑动窗口，Guava RateLimiter是令牌桶。令牌桶允许一定程度的突发流量，漏桶强制平滑流量，所以秒杀场景常考虑令牌桶，对抖动敏感的接口可能会选漏桶。如果面试官问“为什么Sentinel比Hystrix好用”，可以从Hystrix的线程池隔离和信号量隔离说起，Sentinel的并发线程数隔离和QPS限流更轻量，而且规则支持动态推送。
我在实际项目里给支付回调接口配了每秒QPS限流和异常比例熔断：当下游服务的错误率超过阈值，就直接返回兜底结果，不再发起远程调用。同时一定要配置超时，Feign和Dubbo都要设置连接超时和读取超时，避免线程被慢接口堵死。以下是一个Feign客户端配置示例：
feign: client: config: default: connectTimeout: 2000 readTimeout: 3000生产环境里这些规则不会写在配置文件里写死，而是通过Sentinel控制台或Nacos做动态规则推送，这样调整限流阈值不需要重新发版。这个点非常加分。
4. AI应用：Java开发者如何搭上AI这趟车
4.1 AI Agent与Java服务的集成方式
现在的面试，已经越来越频繁地问“你在项目中用过AI吗”。Java开发者如果只能答“我用过ChatGPT写代码”，那和一个普通用户没什么区别。更值钱的认知是AI Agent：把大模型当作大脑，配合工具调用、记忆和任务规划，去完成一个具体的业务目标。
比如做一个智能客服：用户问“帮我查订单”，Agent先识别意图，调用订单查询工具，带上用户ID和权限校验参数拿到真实数据，最后让大模型基于这份数据生成回复。这里的关键是工具调用不是大模型直接查数据库，而是Java代码先做鉴权和行级权限控制，再把允许范围内的结果返回给模型。这个思路和微服务网关很一致。
如果项目里已经用了Spring Boot，可以封装一个最简单的AI调用服务。下面是一个基于RestTemplate的示例，生产环境不建议这样直接用，但是理解流程足够了：
@RestController @RequestMapping("/ai") public class ChatController { private final RestTemplate restTemplate; public ChatController(RestTemplate restTemplate) { this.restTemplate = restTemplate; } @PostMapping("/chat") public String chat(@RequestBody ChatRequest request) { // 生产环境必须做：URL白名单、用户鉴权、内容安全过滤、token上限控制 String url = "https://api.example.com/v1/chat/completions"; Map<String, Object> body = new HashMap<>(); body.put("model", "deepseek-chat"); body.put("messages", List.of(Map.of("role", "user", "content", request.getMessage()))); HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); headers.setBearerAuth(apiKey); HttpEntity<Map<String, Object>> entity = new HttpEntity<>(body, headers); ResponseEntity<Map> response = restTemplate.exchange(url, HttpMethod.POST, entity, Map.class); return extractContent(response.getBody()); } }真正的工程化，要封装独立的AIService，统一处理超时、重试、流式输出、token计费和结果结构化。AI调用不能裸奔，否则任何一个模型接口抖动都会拖垮业务。
4.2 AI辅助编程：提示词工程与代码生成实战
提示词工程不是玄学，它是当前Java工程师提升效率最快的杠杆。我日常写单元测试、生成POJO、写SQL都会让AI帮忙，但前提是提示词要给足上下文。一个好用的结构是“角色+任务+约束+示例”。
举个例子，热搜词里有个“java 判断字符串中是否不是字母和数字”，这个需求可以直接交给AI。我给的提示词：
你是资深Java工程师，请写一个方法：判断字符串是否由字母和数字组成。 要求： 1. 入参为null时返回false 2. 使用Character.isLetterOrDigit遍历，不要用正则 3. 给出方法注释和三个测试用例AI生成的代码通常已经不错，但你一定要手工review边界条件，比如空字符串、中文、下划线、emoji。下面是我实际会用到的版本：
public static boolean isLetterOrDigit(String str) { if (str == null || str.isEmpty()) { return false; } for (char c : str.toCharArray()) { if (!Character.isLetterOrDigit(c)) { return false; } } return true; }顺带说一下“常用库函数algorithm java”这个热搜：Java没有C++那种标准algorithm库，但有很多好用的工具类，比如Apache Commons Lang的StringUtils、Guava的Splitter和Joiner、JDK自带的Arrays和Collections。写算法题时，如果面试官允许，这些工具类能省很多时间，但工程里更推荐直接消费Stream API。
4.3 大模型API调用的工程化落地：从结果解析到行级权限控制
AI应用最大坑是权限旁路。你把一个工具暴露给大模型，如果没有Java服务做行级权限控制，大模型可能绕过你的查询限制，返回别人的订单数据。这个热搜词“行级权限java”在AI时代变得更重要：AI只能访问当前用户身份下的数据。
我的做法是，在工具调用层做一层拦截：AI Agent只负责产出“意图参数”，真正执行SQL前，Java服务会将当前登录用户ID拼进查询条件里。比如订单查询工具，最终SQL永远带着WHERE user_id = 当前用户ID，用户无法通过自然语言绕过。大模型说的不算，代码里有的才算。
同时，面向公众的AI应用还要做内容安全过滤。对用户输入和大模型输出都做敏感词拦截，确保最终展示的内容符合标准。这不是“无限制聊天”那种荒诞需求，恰恰相反，负责任的AI应用必须有限制和审核。面试里能主动提到这些合规和安全的细节，会非常加分。
4.4 DeepSeek开源训练方法给Java面试题的启发
最近DeepSeek公开了AI智能体训练的新方法，这对Java工程师来说最大的启发是：AI Agent本身就是一个极好的面试题。它把任务规划、工具调用、上下文管理、异常恢复组合在一起，和我们在微服务里做编排非常像。面试官如果问“你怎么看待AI Agent”，你可以从工程视角回答：Agent等于意图识别加工具注册表加状态机加兜底策略。这比单纯说“我用过AI助手”要高级得多。
“多AI协作”也是新趋势：让一个模型做意图识别，另一个模型做摘要，第三个模型做代码审计，最后由Java服务做路由和结果聚合。这种架构和微服务的服务编排思路几乎一脉相承，你完全可以把服务网格里学到的路由、熔断、降级概念迁移到模型调用层。面试时能说出这套认知，说明你真的“懂AI应用”，而不是只会调接口。
5. 实战演练：一组大厂风格的Java面试题与参考思路
5.1 “静态链接”与Java运行机制
这道题我前面已经拆过。如果面试官真的抛出“Java是静态链接的吗”，你要先纠正概念：Java编译期有静态类型检查，但链接过程是JVM运行时的动态解析，类加载的解析阶段会把符号引用替换为直接引用。能说出这个区别，回答就已经很扎实。如果再补一句“静态链接和动态链接本质是两种程序构建方式，Java选择动态链接是为了支持更灵活的多态和类版本管理”，那就是加分项了。
5.2 手写排序：冒泡排序之外的考察意图
你不理解为什么大厂还让写冒泡排序？因为在最基础的题里，最能考察代码风格、边界处理和优化意识。写一个优化过提前退出的版本：
public void bubbleSort(int[] arr) { int n = arr.length; for (int i = 0; i < n - 1; i++) { boolean swapped = false; for (int j = 0; j < n - 1 - i; j++) { if (arr[j] > arr[j + 1]) { int tmp = arr[j]; arr[j] = arr[j + 1]; arr[j + 1] = tmp; swapped = true; } } if (!swapped) { break; } } }亮点是：如果某一轮都没有发生交换，说明数组已经有序，提前结束。时间复杂度最好情况O(n)，最坏情况O(n^2)，空间复杂度O(1)。面试官可能还会让你比较默认排序Arrays.sort为什么快：基本类型用的是双轴快速排序，引用类型用的是TimSort，因为引用类型要保证稳定性。
5.3 缓存与数据库的数据一致性
这是一道典型的系统设计题。问题背景：扣库存或更新订单，先更新数据库还是先更新缓存？我的回答分三步：
- 更新数据库成功后删除缓存，而不是更新缓存，因为删除缓存可以规避并发写导致的脏数据。
- 删除缓存失败时做延迟双删，一般延迟200到500毫秒再删一次，避免过期读回填的旧数据。
- 如果还要更强的最终一致性，可以用MQ异步重试删除，或者订阅MySQL binlog，通过Canal解析出来更新缓存。
面试官大概率会追问“延迟时间怎么定”。你可以说，这个时间要覆盖主从同步延迟和一次读请求的回填时间，经验值200到500毫秒，但更严谨的方法是统计线上读回填耗时，取P99值再乘个系数。能说出方法比说出数字重要得多。
5.4 字符串处理、文件解析与常见笔试陷阱
“判断字符串中是否不是字母和数字”这种题，笔试里经常以各种变形出现。除了前面贴的遍历方法，还可以用正则^[a-zA-Z0-9]+$，但要说明正则性能比遍历差，在频繁调用场景会有编译开销。还有一个坑：Java的char是16位，如果字符串里有emoji或者生僻字，会存在代理对，最好用codePoints()遍历而不是charAt()。
再补充一个笔试陷阱："1,2,3".split(",")在JDK8时会丢尾部的空字符串，如果你要完整分割，需要传负数参数split(",", -1)。String.join和Collectors.joining的区别也有很多人分不清：一个是拼接字符串集合，一个是Stream流的终止操作。这些看起来琐碎，但笔试里特别容易写错。
6. 备考路线与项目经验：三个月如何从“会写代码”到“能过面试”
6.1 Java学习路线的关键节点
热搜词里那个“java学习路线”我特别有发言权，因为我真的见过太多人收藏了十几种路线图却一步没走。真正有效的顺序应该是：
- Java基础语法加面向对象，能独立写CRUD。
- 集合源码、异常、IO、反射，理解底层。
- 并发编程，线程池、锁、ThreadLocal。
- JVM，内存分区、GC、类加载。
- 数据库与ORM，MySQL索引、事务、MyBatis。
- 缓存与消息，Redis、Kafka。
- 微服务，Spring Cloud、Dubbo、Sentinel、Seata。
- AI应用，调用大模型API、提示词工程、Agent小项目。
每个阶段都要有一个可见的输出，GitHub仓库、博客、或者一份排查笔记都行。面试官不看你收藏了多少资料，只看你能不能用你自己的话把一个项目讲清楚。三个月时间，如果你已经有一定的Java基础，把重心放在并发、JVM、微服务和AI这几个方向上，性价比最高。
6.2 用微服务项目打造可深聊的履历
很多人简历上的“秒杀系统”“仿某商城”千篇一律，项目里的数据库设计、Redis用法基本复制粘贴。想让项目变得可深聊，关键是给项目加入“冲突”和“权衡”。比如：订单服务一开始用MySQL主从，但大促时读库延迟导致库存超卖，于是引入Redis预扣库存加延迟消息回滚，同时用Seata管理跨服务事务。这个项目就有了真实的技术难点和解法。
准备一个30分钟的深聊脚本：先说项目背景和业务指标，再说你负责的模块，然后讲一个技术难点以及解决过程，最后讲一次线上事故复盘。面试官最喜欢追问事故复盘，所以一定要准备真实数据，比如“接口P99从800ms降到200ms，QPS从2000提到了8000”。这些数字能让你的项目立刻变得可信。
6.3 AI方向的加分项与实践建议
如果你想在简历里加一个AI相关项目，我建议做一个基于企业内部文档的问答机器人：Spring Boot加向量检索加RAG。文档先切块、embedding后存储到向量库，用户提问时先做相似度召回，把命中的文档片段拼进Prompt，再调用大模型生成回答。这个项目有足够的技术含量，可以聊文本切分、向量召回、命中率优化、权限过滤，能展示你不仅会调API，还懂一点检索和工程落地。
“多AI协作”可以作为进阶玩法：两个模型分别做意图识别和答案总结，Java做到统一入口和结果聚合。这个架构在面试里会是一个很好的亮点，因为它展示了你在用工程思维看待AI，而不是在追热点。
6.4 面试中的时间管理与追问预案
面试时间有限，如果被一个问题带偏了整个局面，后面就很难翻转。我的建议是：算法题先讲思路再写代码，不要闷头写；系统设计题先问清确认边界再谈方案；完全不熟悉的话题，宁可说“这个我没有在生产环境用过，但我的初步思路是……”，也不要强行编造。
给自己留追问点非常重要。你在简历上写“延迟双删”，那面试官大概率会追问“如果删除失败怎么办”；你写“AI提示词”，就可能会被追问“怎么防止提示词注入”。所以简历里的每一个技术点，都要提前给自己出五个追问，自问自答，直到你无法回答为止。准备得越充分，面试现场就越轻松。
说到底，面试这件事是对真实工程能力的压力测试。我在面了很多候选人之后越来越相信：与其刷几千道题，不如老老实实把一个项目的技术深度做透，再保持对微服务和AI新变化的好奇心。如果你最近也在准备大厂Java面试，建议选一个你最熟悉的业务场景，把核心技术基础、微服务架构、AI应用串成一条线，讲给朋友听一遍。能把这条线讲明白，面试就已经成功了一大半。
