企业官网建设流程全解析

上周有个准备跳大厂的学弟找我做模拟面试，上来就抛了个问题：“Java基础、Spring Boot、微服务这些我都背了好几轮，为什么一到现场还是被问到卡壳？”我反问他：“那你说说，一个请求从网关进来，到服务把大模型的回答通过SSE流式渲染到浏览器页面，中间到底发生了什么？”他愣住了。这才是现在互联网大厂Java求职面试的真实缩影——面试官不再满足于你背得出“Spring Boot是什么”“微服务有哪些组件”，而是要求你能把Java基础、Spring Boot、微服务、数据一致性、AI技术栈这几个模块串成一条完整链路去思考问题。

这篇文章就围绕这条链路来拆。我会把面试里最容易被追问的Java难点、Spring Boot核心机制、微服务架构落地，以及AI交互逻辑封装、SSE流式输出、abort中断这些近两年越来越高频的新考点，一项项讲清楚，最后附上我实际面试、带人、做项目过程中踩过的坑和排查思路。不管你是准备校招还是社招，都建议按这个框架过一遍，比盲目刷八股文有用得多。

1. 打牢地基：Java基础与并发机制的面试必考点

1.1 JVM内存与类加载机制：动态链接的真相

很多人把“Java基础”理解成背语法、背集合、背面向对象，但在大厂面试里，基础题往往是披着语法外衣的JVM题。面试官特别喜欢问这样一个问题：“new出来的对象放在堆里，那类信息、静态变量、常量池放哪儿？反射凭什么能拿到一个类的方法？”

这个问题的核心考的是运行时常量池和方法区（在HotSpot里通常对应元空间）。Java源文件编译成class字节码后，类信息、字段描述、方法描述、常量池都会加载到元空间。对象实例在堆上，但对象头里有一个指向类元数据的指针，这个指针才是运行时能确认“这个对象属于哪个类”的关键。所以Java本质上是动态链接的——JVM在运行期通过符号引用解析出实际的方法地址，而不是像C/C++那样在编译期就做静态链接。这个点你在面试里主动说出来，会显得基本功很扎实。

类加载的双亲委派模型也是高频题。面试官会追问“为什么JVM要设计成父类加载器优先而不是子类优先”，核心答案是为了避免核心类库被篡改。你自己写一个java.lang.String，正常情况下根本不会被加载，因为引导类加载器会优先加载JDK自带的String。但这里有一个延伸考点：Tomcat为什么打破双亲委派？因为Web容器需要隔离不同应用的类库版本，所以采用本地优先加载。这种“知道标准模型，又能说出打破模型的真实场景”的回答，很容易和只会背概念的人拉开差距。

在JVM调优和内存排查这块，面试往往结合线上问题一起问。比如“服务CPU飙升，你怎么排查”“频繁Full GC是什么原因”。我给出的回答思路是：先通过jstack拿线程栈，看有没有死循环或者锁竞争；再用jstat -gcutil观察各个代的GC次数和时间，确认是不是对象分配速率过高或者内存泄漏；配合jmap导出堆dump，用MAT分析大对象和引用链。这个思路本身比记住一堆JVM参数更有价值，因为面试官想看你是否有完整的故障定位方法论。

还有一个容易被问倒的点：Java对象在内存中的布局。对象头包含Mark Word和类型指针，Mark Word里存了哈希码、GC分代年龄、锁状态标志。讲到锁状态时，顺带引出偏向锁、轻量级锁、重量级锁的升级过程，这就是从JVM基础自然过渡到并发题目的最佳路径。你会发现，面试官其实很少按部就班问“什么是AQS”，更多是从一个对象的状态开始，一步一步把话题引向并发控制。

1.2 并发编程从AQS到锁实战：别只知道八股

并发是Java面试的深水区，其中AQS（AbstractQueuedSynchronizer）几乎是大厂必问。但如果你只是背出“AQS是一个同步框架，通过state和CLH队列实现锁”——这个回答太干，拿不到高分。更好的表达方式是结合你实际用过的锁来讲。

以ReentrantLock为例，它内部就是基于AQS实现的。AQS维护了一个volatile的int类型state，表示同步状态。加锁时通过CAS去抢state，抢不到就把当前线程封装成Node节点挂到CLH双向队列尾部，然后LockSupport.park()阻塞自己。释放锁时修改state，唤醒队首线程。这里可以对比synchronized：JDK 1.6之后synchronized也做了大量优化，有偏向锁、轻量级锁、锁膨胀的升级路径，而且它是JVM层面的关键字，异常时由监视器指令自动释放锁。而ReentrantLock更灵活，支持公平锁、可中断、超时获取、多个Condition条件队列。实际项目中我通常优先用synchronized，因为它简单不容易出错，只有在需要可中断或超时控制、多个条件队列时才换ReentrantLock。

volatile也是一个高频考点。它的核心是保证可见性和有序性，但不保证原子性。很多人会混淆volatile和synchronized的职责。面试官如果问“双检锁单例为什么要加volatile”，你要能回答出“防止uniqueInstance = new Singleton()这一步发生指令重排导致另一个线程拿到未初始化的半成品对象”。这里最好再补一句：new对象不是原子操作，分为分配内存、初始化对象、设置引用三步，JVM可能把第二步和第三步重排，所以需要一个内存屏障来禁止重排。

线程池相关题目强调实际经验。我给个几乎不会过时的回答模板：核心线程数怎么定要看任务类型。CPU密集型任务通常设置为CPU核数+1，IO密集型任务可以适当调大，比如设置了CPU核数两倍甚至更多，因为线程在等待IO时CPU可以切换处理其他任务。但现代服务往往是混合型任务，更稳妥的办法是压测验证。队列长度也不是越大越好，如果队列太长，任务积压会带来延迟和内存压力。拒绝策略默认是AbortPolicy直接抛异常，但业务上我更喜欢CallerRunsPolicy，让提交任务的线程自己执行，起到天然降速作用。最后一定记得说出“线程池参数不能拍脑袋定，而是根据QPS、响应时间、任务耗时推算，再靠压测修正”这句话，这能帮你在众多背题者中脱颖而出。

1.3 数据一致性：从单机事务到分布式解释

Java程序员普遍容易在数据一致性上栽跟头，尤其是分布式系统经验不多的求职者。面试官经常拿一个最简单的场景切进去：“你的微服务订单接口调用库存服务扣减库存，网络超时了，怎么保证两边数据一致？”

正确思路是先把问题的边界画清楚。单机环境靠数据库事务的ACID特性，具体到隔离级别就要理解MVCC机制。比如MySQL默认的REPEATABLE READ隔离级别下，READ VIEW和回滚段配合，让普通查询不阻塞写操作。这就是为什么InnoDB同时支持高并发和事务能力的原因。

分布式环境下，CAP定理和BASE理论是底层判断依据。如果系统要求强一致性，可以考虑两阶段提交（2PC）或者Seata AT模式。Seata AT模式的思路很巧妙：它通过全局事务管理器协调分支事务，在业务执行前生成“镜像数据”存到undo_log表，事务提交前检查数据冲突，一旦发现冲突就回滚并恢复镜像数据。但AT模式也有代价，需要额外的资源锁定和回滚日志，高并发场景下性能会打折扣。

如果系统能接受最终一致性，我通常会选择基于本地消息表或者MQ事务消息的方案。比如订单创建成功之后写一条“扣减库存”的消息到本地表，和订单事务在同一个数据库事务里提交，再由一个可靠的消息投递组件把这条消息发送给RocketMQ或Kafka，库存服务消费后执行扣减。这种“事务消息+幂等消费”的组合是业界最常用的分布式事务替代方案。面试时你先问清楚对方是强一致还是最终一致，再选择不同的方案，比上来就背Seata高级得多。

2. Spring Boot核心机制与实战细节

2.1 自动配置与Starter：第一个Spring Boot程序背后发生了什么

很多初学者从“第一个Spring Boot程序”开始，照着一篇教程把spring-boot-starter-web加上，写一个@RestController，然后main方法一跑，服务就起来了。但你问他“这个starter到底帮你做了什么”，多半答不上来。这就是面试官最爱的切入点。

@SpringBootApplication是一个组合注解，包含@SpringBootConfiguration、@EnableAutoConfiguration和@ComponentScan。其中最关键的是@EnableAutoConfiguration，它会通过Spring工厂加载机制读取META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件，这个文件里列出了所有自动配置类的全限定名。Spring Boot的自动配置类都会配合一系列条件注解，比如@ConditionalOnClass判断classpath下有没有指定类，@ConditionalOnMissingBean判断容器里有没有用户自定义的Bean。所以Spring Boot的“自动配置”本质是“条件化配置”——你要的配置如果是默认的，就不用手写；一旦你写了自定义Bean，框架的自动配置就会自动退让。明白这个关系之后，面试里被问到“怎么实现一个自己的Starter”就不会慌：写一个XxxAutoConfiguration类，加上条件注解，在META-INF/spring下配置好导入文件，一个Yml配置包含开关属性，就完成了一个标准的starter。

很多人还分不清Spring、Spring Boot、Spring Cloud这几个词。用一个最容易理解的类比：Spring是一个全面的编程和配置模型家族，它本身解决的是对象管理问题；Spring Boot是对Spring的再封装，解决了配置繁琐、依赖冲突、启动部署麻烦的问题，像一个傻瓜相机；Spring Cloud则是一套分布式系统工具箱，服务注册发现、负载均衡、配置中心、网关都从这里面来。面试时如果被问“这三者什么区别”，按这个层次去表达基本不会出大问题。

2.2 Bean注入与生命周期管理的关键经验

Spring核心是IoC和AOP，面试必考Bean的生命周期。一个Bean从定义到销毁，经历了实例化、属性填充、初始化、使用、销毁几个阶段。在初始化前后，Spring会调用BeanPostProcessor的postProcessBeforeInitialization和postProcessAfterInitialization方法，AOP代理就是在这时候通过“后置处理器”织入的。所以你可以这么回答：Spring的AOP本质是代理对象，这个代理不是写死在代码里的，而是在Bean初始化阶段通过AbstractAutoProxyCreator动态生成的。

注入方式的选择也是大厂面试的隐形考点。构造器注入、Setter注入、字段注入三选一，最佳实践是强制依赖用构造器注入，可选依赖用Setter。构造器注入的好处是能保证依赖不可变，并且容器启动时就能发现循环依赖，避免运行时才炸。字段注入虽然写起来最省事，但无法在单元测试里直接new一个不依赖Spring的对象，而且比较容易违反单一职责。这里要特别说一下循环依赖：Spring通过三级缓存解决单例Bean的循环依赖，一级缓存放成品，二级缓存放早期暴露的引用，三级缓存放对象工厂。关键的是，构造器注入的循环依赖是解决不了的，因为对象还没实例化出来，缓存里找不到半成品引用。

实际项目里我还遇到过@Configuration类被CGLIB代理导致的一些怪问题。比如你把一个普通方法放在配置类里，却发现每次调用返回的都不是同一个对象。原因就是Spring把配置类变成了CGLIB子类，方法调用会被拦截，确保单例Bean的语义。如果你用@Bean方法内部去调用另一个@Bean方法，得到的始终是容器里那个单例。这个细节面试答出来，会显得你对Spring机制真的理解到了底层，而不是停留在写代码的层面。

2.3 缓存与日志：Caffeine和Logback现场实战

缓存问题几乎每个团队都会遇到。Spring Boot里整合Caffeine非常简洁，引入caffeine依赖后，通过CacheManager定义一个CaffeineCacheManager，再用@Cacheable标注方法就行。我实际推荐先写一个Caffeine配置类，设置最大容量、过期策略和统计信息收集：

@Configuration public class CacheConfig { @Bean public CacheManager cacheManager() { CaffeineCacheManager cacheManager = new CaffeineCacheManager("userCache", "orderCache"); cacheManager.setCaffeine(Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(Duration.ofMinutes(5)) .recordStats()); return cacheManager; } }

Caffeine之所以快，是因为它内部采用了类似ConcurrentHashMap的数据结构，同时结合了Window-TinyLFU淘汰算法，能根据访问频率做细粒度冷热数据分离。面试官追问“本地缓存和Redis缓存该如何选择”时，我的回答是本地缓存快但数据不共享，适合存不常变动的字典数据；Redis适合多实例共享的数据。一个成熟系统通常是两级缓存，先查本地，再查Redis，两级都没有才走数据库。

缓存经典三大问题——穿透、击穿、雪崩——是面试题库的常客。穿透是查了一个不存在的key，请求全部打到数据库，解决办法是缓存空值或者用布隆过滤器挡一层。击穿是某个热点key失效时大量请求同时打到数据库，解决办法是互斥锁重建缓存。雪崩是大批量key同时过期或Redis宕机导致数据库被压垮，解决办法是过期时间加随机值、Redis集群部署、本地缓存兜底。这几个问题我建议你不仅会背，还能结合你们的实际监控数据去说，比如“我们当时双十一大促前检查缓存过期策略，发现一批活动商品key刚好同一刻过期，于是把过期时间分散到5到10分钟区间”，这种真实场景比定义更有说服力。

日志这块容易被忽略，但大厂很看重实战能力。Spring Boot默认用的是Logback，你要会在application.yml里配置日志级别、文件输出、滚动策略。我习惯再把日志格式改成带traceId的输出，配合MDC在入口过滤器里塞一个全局请求ID。这样排查问题时可以按一个请求的完整链路把所有日志捞出来，这在微服务环境尤其重要。面试官如果问“日志打太多影响性能怎么办”，异步日志、日志采样、按级别拆分文件都是可以考虑的方向，优先提异步日志的丢失风险判断，会显得你有真实的性能权衡思考。

2.4 Spring Boot 3中的Spring Security配置迁移

接触过老项目的同学应该都见过WebSecurityConfigurerAdapter。但到了Spring Boot 2.7后这个类被标记废弃，Spring Security 5.7之后官方推荐用SecurityFilterChain的Bean声明方式。Spring Boot 3更是全面转向Jakarta EE规范，集成方式也以Lambda DSL为主。很多人在这个版本升级上栽过跟头，面试里也经常被问“你会不会做Security配置迁移”。

老配置通常长这样：继承WebSecurityConfigurerAdapter，重写configure(HttpSecurity http)，然后放开某些路径、关闭CSRF、配置表单登录。新配置则是写一个@Bean方法返回SecurityFilterChain，并按“先放行再认证”的顺序配置授权规则：

@Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf(csrf -> csrf.disable()) .authorizeHttpRequests(auth -> auth .requestMatchers("/api/auth/**", "/sse/**").permitAll() .anyRequest().authenticated()) .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) .addFilterBefore(jwtAuthFilter, UsernamePasswordAuthenticationFilter.class); return http.build(); }

注意三层关键：第一，新写法里每个配置项都变成了链式Lambda的形式，每一段都返回自身继续配置，这也是官方推动函数式风格的结果；第二，JWT认证场景下要设置STATELESS会话策略，并注册自定义过滤器去解析Token；第三，CORS配置不要和Security授权规则搞混，跨域放行要在Security的CORS配置里做CorsConfigurationSource的注册，否则前端请求会被挡在过滤器链之外。Spring Security的过滤器链执行顺序有一定讲究，加过滤器时一般在UsernamePasswordAuthenticationFilter之前做认证逻辑，因为顺序错误会导致请求还没走到认证过滤器就被后续的授权规则拦截。

我见过不少人在迁移时疯狂爆500错误或403，最后排查半天发现是路径匹配方法写错了。新版本里antMatchers已经被requestMatchers替代，参数既可以传String模式，也可以传RequestMatcher对象。这种“新老API差异”的细节，在面试里提到会非常加分。

3. 微服务架构拆解逻辑与面试真题剖析

3.1 微服务为什么要拆：它不是银弹

微服务是架构演进的结果，不是一件可以“直接引入”的工具。面试官最爱问“你们为什么要把单体拆成微服务”。一个比较有水平的回答是：单体应用在团队规模小、业务简单时交付效率最高，但当团队扩展到几十人、业务模块之间的耦合越来越严重时，每次发布都要全量回归，单点故障范围大，这时候才需要考虑按业务边界拆分。

拆分最重要的依据不是技术而是组织。康威定律说“系统架构等同于组织沟通结构”，你让两个团队共同维护一个用户服务，它们迟早会忍受不了。更常用的做法是参考DDD的限界上下文，把订单、商品、库存、支付这些业务能力划分成独立的域。以商城系统举例，订单服务和库存服务必须分开，因为它们的业务变化频率和团队归属完全不同。但拆分完不是结束，你还要想清楚它们之间的数据一致性、故障隔离、监控运维怎么协作。

这里有一个高频追问：“拆分之后有哪些坑”。你可以大胆踩坑后再分享：跨服务调用链路变长，任何一个服务抖动都会放大延迟；数据一致性更难保证；部署数量和资源消耗急剧增加；日志和监控需要统一平台；联调成本变高，尤其在Java和Go这种跨语言团队之间。把这些问题抛出来，才是面试官想看到的真实架构思考，而不是“微服务就是好”的片面答案。

3.2 服务通信与联调：OpenFeign、gRPC与WebSocket

微服务之间的通信方式主要有两类：同步RPC和异步消息。OpenFeign属于同步HTTP调用，使用起来很简单，声明一个接口、配上注解就能像调本地方法一样调远程服务。但不要轻视Feign的细节：超时时间要单独配置，因为Ribbon默认超时很短；日志级别要设置成FULL才能在联调时看到请求和响应；接口调用失败时要配合降级类返回兜底数据。

联调跨语言团队时，gRPC往往比HTTP更合适。gRPC基于HTTP/2，支持长连接、多路复用，默认使用Protobuf二进制序列化，性能高出JSON不少。Java与Go服务通过protobuf定义好.proto文件后，两端各自生成代码，接口契约清晰且不易偏题。面试官如果问“什么时候用Feign什么时候用gRPC”，最佳回答是：团队内部、对性能敏感的场景优先gRPC，比如实时推送、视频处理服务之间的调用；对外部系统、浏览器端、移动端，HTTP/JSON依然是最通用的选择。

WebSocket在Spring Boot里集成也很常见，主要用于实时双向通信，比如聊天、在线协作、消息推送。yml配置主要涉及STOMP端点注册和Broker配置：

spring: websocket: broker: relay: enabled: false

不过更规范的方式是通过Java配置类@EnableWebSocketMessageBroker注册/ws端点，并配置/topic和/queue前缀。面试被问到“SSE和WebSocket怎么选”时，你可以从语义上区分：WebSocket是全双工双向通信，SSE是单向服务端推送；如果只是服务端把数据推给客户端，SSE够用且实现简单；需要客户端持续向服务端发消息的场景，比如在线聊天室，再考虑WebSocket。

3.3 微服务架构图与开源项目的落地参考

“画一张微服务架构图”是高频面试题。一个比较完整的架构图至少包含几个层次的组件：最外层是API网关，比如Spring Cloud Gateway；往下是业务服务层；再往基础设施层看，注册中心用Nacos或Consul，配置中心统管各环境配置，熔断降级组件用Sentinel或Resilience4j，链路追踪用Micrometer Tracing或Sleuth，消息队列用RocketMQ或Kafka，缓存用Redis集群。面试时画图不用追求组件数量多，重点是能说清每个组件解决什么问题、它们之间的流量路径是怎样的。

如果你想动手参考一个现成的开源微服务项目，若依微服务版本（RuoYi-Cloud）是个不错的起点。它有网关、系统服务、认证服务、监控服务，用了Nacos、Sentinel、Spring Security、Redis这些主流组件。看这类项目时不要只盯着代码，你重点要关注的是数据权限如何设计、Token如何校验、服务间调用如何鉴权、异常如何统一处理、分布式事务和幂等怎么做。把这些模块串成自己的理解，面试时才能讲出“这个项目的架构是为什么这样设计”而不只是“我照着一个开源项目改造过”。

3.4 分布式事务：Seata之外还有哪些解法

分布式事务不是只有Seata一个答案。正常面试节奏我会先说Seata的几种模式：AT模式无侵入，适合大多数场景；TCC模式需要你实现Try、Confirm、Cancel三组接口，灵活但编码复杂；Saga模式强调正向下发和逆向补偿，适合长流程事务。然后我一定会说“Seata不是银弹”，尤其高并发场景下AT模式全局锁容易成为瓶颈，TCC需要抗住接口幂等和空回滚问题。

更常用、更简便的是“本地消息表+消息队列”的方案。订单服务和库存服务不需要实时强一致，只要保证最终库存扣减成功即可。订单写入后在同一数据库事务里写入一条待发送消息，定时任务扫表投递MQ，库存服务消费后做幂等更新。这种方案的优点是简单、可控，缺点是需要额外维护一张消息表和一套投递程序。如果追求更轻量，还可以考虑“事务消息”，用RocketMQ直接支持事务消息的发送和回查，本地事务提交后消息才可见。面试讲到“你怎么保证数据一致性”时，能够先区分业务对实时性和一致性的容忍度，再给出对应的方案组合，就已经达到高级岗位的回答标准了。

4. AI技术栈：Java服务如何接入大模型能力

4.1 技术栈选型：Spring AI还是自研封装

最近两年大模型应用突飞猛进，Java后端必然要面对“如何把大模型能力封装到自己的服务里”。面试官问这个问题的时候，一是想看你对新技术的敏感度，二是在考察你设计一个可复用模块的架构能力。

一个比较粗暴但有效的最简方案是直接用HttpClient调用大模型API，把Prompt、温度、最大Token等参数封装成工具类。但项目一复杂，这种方案就不够看：多个模型供应商切换、API Key管理、Token消耗统计、错误重试、流式输出处理，全都要自己实现。用Spring AI可以省去很多重复劳动，它提供了ChatClient接口、Prompt模板、输出解析、模型切换能力，底层还封装了流式调用。类似地，LangChain4j也值得了解，它把Prompt模板、记忆管理、工具调用这些能力集成到了Java生态。

实际项目中，“AI交互逻辑”应该是一个独立的模块，而不要散落在业务代码里。我一般会把它做成一个AiGateway接口，屏蔽底层模型差异。上层业务只需要传入用户消息、上下文和业务类型，返回一个统一的响应对象或流式事件流。内部的模型路由可以根据业务场景选择不同模型，比如客服问答走意图识别模型，内容生成走长文模型，同时记录每个请求的Token消耗用于成本核算。模块一旦抽好了，后续换模型、加模型都只是在网关实现里加一段配置的事，业务层完全不用动。

餐饮SaaS接AI就是一个典型的案例：客户想通过自然语言查询报表，或者让AI根据销售数据生成经营建议。如果用最土的方式写代码，业务逻辑会迅速肿胀；但如果你设计一个“意图识别–插件调用–流式渲染”的管道，后续加新能力只需要扩展插件而不用改主链路，这个设计思路本身就很适合在面试里作为亮点讲出来。

4.2 SSE流式输出：大模型回答实时渲染的关键

大模型响应动辄几百上千字，如果等全部生成完再返回，用户会对着一个转圈白屏等十几秒。现在主流方案是SSE（Server-Sent Events），服务端把Token分批推送给前端，浏览器像打字机一样逐字渲染。Java后端实现SSE常用两种方式：Spring MVC的SseEmitter和Spring WebFlux的Flux<ServerSentEvent>。

业内很多AI应用走的是WebFlux方式，因为大模型输出本质是异步流式数据，和Reactive模型天然匹配。一个典型的实现如下：

@GetMapping(value = "/api/chat/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE) public Flux<ServerSentEvent<String>> streamChat(@RequestParam String message) { return chatService.streamReply(message) .map(token -> ServerSentEvent.builder(token) .event("message") .build()); }

前端通过EventSource接口接收即可，但注意EventSource默认只能GET请求。如果你需要POST且要带请求体，建议用fetch加ReadableStream去读取响应流，每次拿到一个数据块就解析并渲染到页面。

SSE和普通的HTTP接口不同，连接是长驻的，所以服务端要处理超时和断连问题。SseEmitter默认超时是30秒，如果大模型生成时间较长，需要显式设置更长的超时时间或者把它放到一个线程池里管理。心跳机制也值得设计，定期发送注释行保持连接活跃，避免中间代理掐断空闲连接。断连后前端要能自动重连，并判断是否需要重新发起请求。

4.3 abort中断：前端中断时后端如何优雅收尾

流式输出里最容易踩坑的是“用户中途点了停止”。如果前端主动关闭连接，后端还傻乎乎地一直把Token发给一个已经不存在的连接，不仅浪费算力，还会导致服务端的线程和内存资源被长时间占用。这里的核心是abort机制正确落地。

前端可以用AbortController发起fetch请求，停止时调用abort()方法。这会触发浏览器断开底层TCP连接，服务端在写入SseEmitter时会抛出IOException。所以后端一定要监听onCompletion和onTimeout回调，在回调里及时释放线程池、关闭相关资源。如果你用的是Flux<ServerSentEvent>，配合doOnCancel做资源释放就能优雅终止生成。注意“终止生成”不只是后端不发了，如果大模型服务还在继续生成，最好把“用户中途停止”的信号同步给模型服务，让上游也停止生成，才能真正省钱省资源。

同时要把“客户端断开”和“网络异常断开”区分开。前者主动取消，后端可以立刻收尾；后者属于被动断开，服务端往往只能通过心跳超时检测。我的做法是维护一个连接管理器，定期检查SSE连接的心跳状态，超过阈值就执行强制回收。这一套逻辑完全可以做成通用组件，多个业务场景复用。如果你能把这个过程完整讲清楚，面试官会认为你确实做过生产级AI功能，而不仅仅是跑通了一个demo。

5. 面试实战：高频追问与避坑记录

5.1 高频追问Top5及答题思路

结合我自己面试和被面的经历，有几个问题是反复出现的，值得先把回答“固化”下来。

第一个问题：“你项目里最难点是什么？”别回答“我都做得挺顺的”。你可以选定一个技术难度适中的场景，例如“我负责的AI报表模块需要把大模型的流式输出实时渲染到网页，同时要支持用户随时中断请求”，然后按“背景–设计–实现–结果”把整个链路讲出来，尤其要强调你是怎么解决abort后的资源回收问题的。

第二个问题：“微服务之间调用超时怎么处理？”回答三个层面：设置合理的超时时间和重试次数；用Sentinel或Resilience4j做熔断降级，让故障服务快速失败而不是拖垮调用方；兜底策略返回默认值或缓存数据，并对调用结果做兜底记录。最好再提一句“要区分超时和失败，超时可能导致请求已经成功处理，这时候重试必须配合幂等设计”。

第三个问题：“你怎么保证数据一致性？”不要一上来就上Seata，而是先给结论“如果是最终一致性场景，并发量高，我用本地消息表+MQ；如果场景必须强一致，再考虑Seata AT”。面试官会顺着问“为什么不用TCC”，这时候你再展开TCC的编码复杂度和空回滚问题，证明你真的做过取舍。

第四个问题：“线程池参数怎么定？”上面已经给过模板，这里强调一点：别只说理论数值，要用你自己的业务做过估算。比如订单下单接口QPS是200，接口平均耗时50毫秒，单个处理线程在高峰期约能处理20个请求每秒，那线程数至少10个，再留一定缓冲并配合压测结果调整，这就是有数据支撑的回答。

第五个问题：“SSE和WebSocket怎么选？”SSE适合服务端单向推送，协议更轻、自动重连更容易；WebSocket适合全双工场景，但客户端逻辑和连接管理成本更高。再加一句实际经验：大模型流式输出优先SSE，因为你的需求是“服务器一直往浏览器推”，而不是“浏览器和服务器互聊”。

5.2 联手实战排查：微服务和AI场景的典型故障

面试后的技术面也会以简历项目为引子，让你说说排障经验。我可以分享几个真实案例。

某次线上商城服务出现偶发超时，排查链路后发现是一个定时任务批量刷缓存，触发了Redis热key的缓存击穿，请求大量穿透到数据库。修复方案是把过期时间打散并加了本地Caffeine缓存兜底，效果非常明显。这是我前面讲的缓存击穿方案的真实验证。

还有一次微服务间调用失败，不是代码问题，而是Nacos注册的服务IP是内网地址，跨机房访问不通。最后在服务配置里强制指定注册IP并调整网络策略解决。这类低级问题在大厂面试里也常被拿来当作场景题，你可以自信地说“我遇到过”。

AI场景的坑也不少。一开始我做的SSE接口没有设置心跳，前端每隔一段时间就会自动重连一次，用户体验很差。后来前端欢迎页面启动了一个重连机制，但只要服务端持续发数据连接就不会断。于是我在服务端加了一个定时任务，每15秒发一个注释行，立刻解决了问题。还有个常见的坑是abort后没有通知模型服务，用户中断后成本依然在计费。后来在网关里统一把取消信号转发给底层模型调用，才把这个窟窿堵上。

5.3 准备建议与个人体会

最后聊点准备上的实操经验。我觉得最有效的复习方式是“把项目里的每一个技术决策都反向问自己三遍为什么”。比如你们用了Caffeine，你就问自己为什么不用Redis；用了Feign，为什么不用RestTemplate；用了SSE，为什么不用轮询？把这些“为什么”答清楚了，面试时候就不怕追问。

另外强烈建议所有准备Java后端面试的人亲手去写一个小项目，把Spring Boot、WebSocket、SSE、大模型调用、abort中断、Redis缓存这几件事串起来。哪怕只是一个AI问答助手页面，你也会实实在在体会到连接管理、线程池资源释放、Token解析这些书上写不到的问题。面试时你能讲出“我当时处理了一个什么问题，后来怎么定位的”，比你背一百道八股都有说服力。

大厂面试越来越看重“链路思维”。不再问单一知识点，而是问一个请求从浏览器到大模型再到渲染的全过程。我自己的体会是：把Java基础、Spring Boot、微服务、AI技术几条线串起来理解，遇到未知问题能迅速在脑海里画出一张调用链路图，再顺着链路去排查和设计，这种能力才是技术面试里真正稀缺的。准备面试的过程辛苦，但当你把这条链路彻底弄懂之后，你会发现面试题其实就那么几种变形。记住，面试是技术债的回报，你现在偷的每一项懒，都会在面试官追问时变成挡在你面前的坑。