微服务与AI工程化：Java高级岗位面试考点实战复盘

最近帮几个朋友做Java后端面试模拟，连续几轮下来发现一个特别明显的规律：只要话题绕到微服务，大家总能蹦出“注册中心”“配置中心”“熔断降级”这些词；但一旦被追问“你怎么设计服务拆分边界”“线上问题怎么定位”，不少人就开始语焉不详。这两年大模型应用全面渗透进后端系统，AI相关的工程化问题也越来越多地出现在技术面试里，很多Java同学在这块准备明显不足。这篇文章就是我近期面试实战的复盘，核心是把微服务架构的考察逻辑和AI应用技术在Java面试里的新考点一并拆开讲透，适合正在冲刺高级Java岗位的开发者，也适合想系统梳理后端知识体系、搞清楚“面试官到底在考什么”的朋友。

1. 微服务架构面试核心考点：服务拆分、注册中心与网关设计

1.1 服务拆分考察的是工程判断力，不是名词背诵

“把订单系统拆成订单服务和库存服务，你觉得合理吗？”这是我最近模拟面里听到频率最高的开场题。很多人一上来就背微服务优点，独立部署、独立扩展、团队自治，说得很顺，但面试官根本不接话，还会追问一句：“那你有没有拆坏过？”这才是核心——面试官想判断你有没有在复杂分布式环境下做过真实取舍。

一次合理的服务拆分要同时满足三条线：业务边界清晰、团队结构对应、数据模型可解耦。业务边界好理解，但要进一步想，有些业务天然高频协作，硬拆成多个服务只会让一次操作变成跨服务多次调用，线上延迟和故障点都变多。团队边界也很现实，十几人的组维护五个微服务，光是发布、监控、联调就消耗大量精力，更别说出问题的时候人肉定位。数据边界是最容易被忽略的，很多团队服务层拆得很漂亮，底层数据库还是一个大库，表之间外键和join照旧，拆了半天等于没拆。

实践里我的建议是先画一张全链路时序图，把核心流程每个步骤标注出来，找耦合度最低、接口最稳定的切口，而不是照着模块图直接切。如果面试官问“拆分之后怎么查询跨服务数据”，别急着用“调用”两个字打发人，要主动提到数据冗余、读写分离、CQRS或者聚合层，这部分能看出你有没有真正处理过拆库之后的查询难题。

1.2 注册中心选型：AP与CP的博弈

注册中心基本是必考题，但很多人把它答成了背诵题。一说Nacos，二说Eureka，三说“我们现在都用Nacos”，这样等于把送分题变成送命题，因为面试官追问的第一句一定是“为什么选它而不是另一个？你对比过可用性和一致性吗？”。

注册中心最核心的分歧在一致性模型。Eureka是典型的AP风格，服务节点之间互相注册消息，即使部分节点挂了，剩下节点依然能继续返回服务列表，代价是短暂可能出现数据不一致。Nacos默认模式也是AP，同时支持切到CP，启用Raft协议做选主，能保证强一致。Consul则更偏CP，每次写入都要过半节点确认，数据一致性更强，但极端情况下可用性会打折扣。

选型时真正要回答的是业务在可用性和一致性之间的偏好。比如库存扣减这种错了要命的场景，哪怕短暂不可用也不能给错数据，就要偏CP；电商大促期间查询类服务，拿到旧一点的服务列表影响不大，AP就够。能把这个权衡过程讲清楚，哪怕最终只是“我们项目简单，Nacos默认AP”，面试官也知道你理解到位了。怕的就是全程没有“权衡”两个字，像在读产品说明书。

除了集群协议，服务发现机制也值得主动展开。Nacos 2.x支持gRPC长连接，客户端和服务端保持双向流，服务变更能更快推送到客户端；Eureka则主要是客户端定时拉取加心跳续约。这里还有个容易丢分的细节：服务实例下线是不是立刻感知？主动下线会调用逻辑删除接口，心跳超时属于被动剔除，中间有时间差，面试官问“频繁发布时服务列表抖动怎么办”，就是在考察你对注册中心探测机制的理解。

1.3 配置中心考察的是生产环境应对能力

配置中心是另一个高频考点。很多团队用Nacos或Apollo，但只享受了“改配置不用重启”的便利。面试官一旦追问“推送机制是长轮询还是WebSocket？长轮询缺点是什么？”“配置灰度怎么做？”，现场就冷场了。

长轮询的本质是客户端挂起请求等待配置变化，连接数一多，服务端hold住大量挂起请求，内存和线程压力都很大；WebSocket要维护长连接，网络抖动后还有重连和状态恢复的问题。安全的生产做法是推送与拉取结合，客户端定期拉全量配置做对账，服务端推送变更做实时感知，两边互补。配置灰度是又一个细节考点：先在某个机房的少量节点上应用新配置，观察核心指标稳定后再推全量，配合版本管理和变更记录，出问题能一键回滚。能主动讲出多环境隔离、配置审计、配置权限管理这些点的人，明显更接近真实生产环境的操盘者。

1.4 网关设计：路由、鉴权与限流的一体化方案

网关是微服务面试的常驻区域，Spring Cloud Gateway的出现频率相当高。路由本身不难，用Path断言做转发，YAML里写几行配置就能跑，这部分大多数人都能说出来。真正的分水岭在鉴权和限流。

鉴权方面，最常见的设计是把Token校验收敛到网关层：登录后签发Token，网关统一解析校验，再把用户ID、角色等上下文透传给下游服务，业务服务只需要信任网关透传的Header。但这里有个容易被追问的点——Token过期了怎么处理？我的做法是网关统一拦截返回未认证错误码，刷新Token的链路单独放用户中心，网关不直接操作用户数据，避免它变成“上帝服务”。还有一种思路是网关只做路由转发，鉴权完全下沉到各服务内部，适合安全要求极高、需要服务独立暴露的场景，但一般团队没必要这么做，重复代码和维护成本太高。

限流容易踩的坑是“只谈算法不谈落点”。固定窗口、滑动窗口、漏桶、令牌桶要能说出来，但更重要的是限流维度。分布式限流通常用Redis加Lua脚本做全局计数，比如限制某个AppKey每秒最多QPS；单机限流可以用Semaphore或者并发线程数限制，应对本地突刺。网关层限流面向调用方维度，下层服务的限流更多是保护自身资源。把“哪一层限什么、为什么限”理清楚，比背算法定义有价值得多。

-- 固定窗口限流：每个Key每秒钟最多放行 limit 个请求 local key = KEYS[1] local limit = tonumber(ARGV[1]) local current = redis.call('INCR', key) if current == 1 then redis.call('EXPIRE', key, ARGV[2]) end if current > limit then return 0 end return 1

这段脚本看起来简单，但已经把原子计数、过期时间、超限拦截都做了，是面试里很好用的一个“落地证据”。

1.5 分布式事务：理论模型与线上代价

分布式事务是微服务面试的分水岭。很多人能脱口而出2PC、TCC、Saga、本地消息表，但被问到“你们线上怎么用的”就直接哑火。面试官想听的其实不是名词罗列，而是你对“代价”的理解。

2PC的协调者单点风险大，事务参与者锁定资源后，如果协调者挂了，参与者只能干等，数据库里锁资源迟迟不释放，这种场景放在高并发线上基本不能接受。TCC需要业务方自己实现Try、Confirm、Cancel三段逻辑，人力成本很高，而且Cancel逻辑本身也可能失败，需要重试和幂等防护。Saga把长事务拆成多个本地事务加补偿操作，链路越长，出错概率越高，人工介入和排查恢复的难度指数级上升。

真正加分的回答不是罗列方案，而是先讲清楚“分布式事务能不用就不用”：优先通过合理的服务拆分避免跨服务事务；实在避免不了就用最终一致性方案，比如本地消息表加定时任务，或者事务消息。我真实项目里的组合是：资金核心链路用TCC守住最终一致，非核心场景用本地消息表加定时扫描做异步补偿。这个组合不炫技，但线上长期稳定。面试时把“为什么这么选、出过什么状况、怎么修复”讲出来，比念几十个理论名词都更能留下印象。

2. 微服务深水区：熔断降级、缓存一致性与链路追踪排查

通过服务拆分、注册中心、配置中心、网关、分布式事务这些高频考点，第一轮技术面基本能撑住。但高级工程师的面试不会停在这里，面试官会继续往下试探：线上突发流量时系统怎么保护自己？缓存和数据库之间的数据不一致怎么处理？一个请求跨了五六个服务，出问题你怎么定位？这就是深水区。

2.1 熔断、限流与降级：从算法到落地方案

关于熔断，候选人通常能说出熔断器三个状态：关闭、打开、半开。关闭状态下正常流转，错误率或慢调用达到阈值就打开，打开后快速失败不再调用下游，过一段时间放进来一部分试探请求，成功比例够了再回到关闭状态。能画出这个状态机的人不算少，但面试官更想看的是你实际用过没有。

以Sentinel为例，它除了基本的QPS、线程数限流，还支持热点参数限流、系统自适应保护和熔断降级规则动态配置。项目里我们最常用的做法是给每个下游依赖配置单独的资源名和规则，慢调用比例和异常比例都设了阈值，降级后执行兜底逻辑返回默认值。这里有个很容易忽略的细节：降级返回值不能是硬编码的空数据，不然调用方拿到空值后下游逻辑可能NPE或者导致业务静默错误。我习惯让兜底逻辑返回带状态标记的空对象，并在日志里打出明确的降级标识，方便线上排查是否大面积降级。

隔离策略也经常被问。线程池隔离让每个下游依赖独享线程池，A依赖耗尽不会拖垮B，但线程池本身消耗内存和切换开销；信号量隔离更轻量，请求在调用方线程内直接执行，适合低延迟场景，但极端情况下也会把调用方线程打满。Hystrix默认用线程池隔离，Sentinel默认是信号量隔离，面试时要把这个差异背后的取舍讲清楚。

2.2 缓存一致性：穿透、击穿、雪崩之外的思考

缓存相关题目几乎每轮面试都会出现，但多数人的准备停留在“缓存穿透用布隆过滤器、缓存击穿用互斥锁、缓存雪崩加随机过期时间”这个层面。这套说法没错，却不完整，面试官更愿意听到的是缓存和数据库双写一致性问题。

Cache Aside模式是实践中最主流的方案：读的时候先查缓存，不命中再查数据库，回填缓存；写的时候先更新数据库，再删除缓存。为什么不更新缓存而删缓存？因为更新缓存存在并发写导致旧值覆盖新值的风险，删除缓存则让下一次读取时重新加载，数据最终一致。这个逻辑讲完，面试官十有八九会追问“先更新数据库再删缓存，如果删缓存失败怎么办”。解决方案要么延迟双删，先删缓存，更新完数据库后再等几百毫秒删一次，兜住中间窗口；要么订阅数据库的变更日志，用数据同步组件异步删缓存，这样即使手动删除失败也有补偿机会。实际生产里我们采用的是“先更新库、再删缓存、失败进消息队列重试”的组合，同时把过期时间加上随机偏移，避免同一时刻大量缓存失效。

布隆过滤器、互斥锁这些基础点当然也要会，但回答时最好绑定具体场景。比如布隆过滤器解决的问题是“大量不存在的数据直接打进数据库”，它的代价是有误判率，要评估好位数组长度和哈希函数数量；互斥锁解决的是“热点Key瞬间失效后并发查库打爆数据库”，可以只允许一个线程重建缓存，其他线程短暂等待。把方案和适用场景绑在一起说，比单纯列名词高级得多。

2.3 链路追踪与故障定位：一个TraceID串起整个排查过程

高级工程师面试经常直接抛线上问题：一个请求很慢，你说怎么排查？如果你只答“看监控、看日志、看数据库慢查询”，基本会被扣分，因为缺少系统性的分析框架。

真正有实战经验的人会从应用层切入：这个请求经过了网关、订单服务、支付服务、消息队列，链路那么长，第一步肯定是拿到全链路TraceID。入口处生成一个TraceID，通过HTTP Header逐层透传，在每个服务里打进日志的MDC，这样所有日志都能按同一个ID聚合。异步线程里要注意透传问题，子线程默认拿不到父线程的上下文，需要手动传递，很多团队在这里埋过坑。

有了TraceID之后，排查顺序可以按“先慢后错”来：先看哪条链路耗时最长，再逐个服务看接口耗时和依赖项耗时，结合Redis和DB的慢查询统计，定位瓶颈。这里要提到采样策略——全量采样成本太高，生产环境一般采10%左右，但出错请求要保证全量记录，所以很多团队会把异常调用强制标记为必采样。这个细节很加分，说明你真实处理过海量日志下的链路数据。

提示：面试时说链路追踪，别只说Spring Cloud Sleuth或者Micrometer Tracing的名字，最好加一句“我们线上TraceID是这么透传的，遇到过异步线程丢上下文的问题”，这才有真实感。

3. AI应用技术面试考察维度：流式输出、RAG与结构化解析

这两年Java面试最大的变化就是AI应用技术开始进入考察范围。“你接触过大模型吗”已经不够了，面试官更想问的是“你能不能把大模型嵌进现有后端系统”。这部分的考点跟Python模型训练完全无关，核心是工程化能力。

3.1 大模型API接入：SSE流式输出的工程化改造

最典型的场景题是“聊天机器人回复太慢，你怎么优化”。同步调大模型API，整个HTTP响应可能要等几十秒，用户早就走了，所以必须做流式输出。Java后端这边主流方案是基于SSE，服务端拿到大模型流式响应，再通过响应流一段段推给浏览器或App。

Spring MVC项目可以直接返回SseEmitter，把模型返回的每个增量通过emitter.send()转发出去；响应式链路的话，用WebClient发起流式请求，拿到Flux再往SSE里中转，体验最顺。

@GetMapping(value = "/chat/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE) public SseEmitter chatStream(@RequestParam String question) { SseEmitter emitter = new SseEmitter(0L); // 通过 WebClient 调用大模型流式接口，每个增量通过 emitter.send() 推送 return emitter; }

这里有两个特别常见的坑。第一，SSE连接如果长时间没有数据推送，中间反向代理节点可能会把空闲连接掐掉，所以一定要做心跳保活，定期发送注释行或空事件；第二，前端断开连接后服务端还在调模型接口，会造成资源浪费，所以要监听emitter的完成或超时事件，及时取消上游流式请求。这两个细节通常不会被写进教程，但线上必须处理。

除了流式改造，超时和重试策略也常被问。大模型API的响应时间波动很大，一个固定10秒超时可能有时候连第一个token都没返回就掐断了。我的做法是分阶段超时：连接超时短一点，首token等待超时放宽到20到30秒，总超时比模型最坏响应时间略大；失败重试用指数退避加随机抖动，避免重试请求同时打爆服务端。回答到这里，还能顺手提一句Token统计和成本控制，说明你真的是在做生产级接入，而不是写Demo。

3.2 RAG系统的面试重点：切分、向量库与权限过滤

RAG是AI应用面试的大热门。业务背景很顺：大模型的知识截止到训练数据，不知道企业私有文档和最新业务数据，所以先把文档切块、向量化、存进向量库，用户提问时先检索最相关的片段，再塞进Prompt让模型基于材料生成回答。很多候选人能说清这个大框架，但细节一问就露馅。

细节问题大概是这样：文档清洗怎么做？chunk size选多少？相邻区块要不要overlap？Embedding模型用哪个？向量维度多少？向量库怎么选？召回结果怎么处理权限？以切分为例，按固定字符数切虽然简单，但容易把一句话的语义拦腰斩断，检索质量很差。我实际项目里的做法是优先按段落切，段落太长了再按句子进一步拆，同时在相邻块之间保留一部分重叠，比如后一块带上前面几十个字符，这样检索时不会因为截断丢失上下文。切完还要做去重，并把文档ID、来源、更新时间、权限级别都作为元数据一并存入向量记录，这样召回时才能按权限过滤。

向量库选型也经常被问。如果数据量很大、过滤条件复杂，选择专业的向量数据库更合适；如果团队已经重度依赖Redis，先用Redis的搜索模块顶住，运维成本更低；数据量再小一点的，直接拿老关系库的向量检索扩展也不是不行。关键是用数据规模、检索延迟、运维预算来倒推选型，而不是跟风。面试答题时能说出“我用的切分策略是……”“我们评估过……指标”，都是编不出来的内容。

还有隐藏加分项——把“检索质量怎么评估”讲出来。召回率、相关性、命中片段在上下文中的位置，都能影响最终回答质量，能主动提这些，说明你真的做过效果调优。

3.3 结构化输出与提示词工程：Java侧的可靠性保障

很多AI应用不再满足于“能回复就行”，而是希望模型输出直接落到业务系统里，比如从客服对话抽取意图、生成工单，或者从合同文本里抽取关键字段。这就是结构化输出和Function Calling的用武之地。

面试官常问“怎么让大模型输出稳定的JSON”。标准答案是组合拳：System Prompt里明确指定输出结构和示例是第一层；如果服务商支持JSON模式就开启，让解码器强制按JSON输出，这是第二层；再稳一点的路子是Function Calling，让模型把抽取结果映射成工具调用的参数，天然结构化。这里有个工程化细节：解析大模型输出时不能盲目信任JSON字符串，可能出现前后缀文字、字段缺失、JSON截断等问题。我的做法是在解析层做清洗和兜底，核心字段缺失就标记为异常工单走人工审核，不让解析异常打穿整个业务链路。

提示词工程本身也是考点。“你怎么让模型不输出幻觉内容？”回答核心是约束和引用：把回答范围限定在给定材料之内，材料里没有就直接说不知道，这句话必须写进System Prompt；同时给一个Few-shot示例，告诉模型什么算合格回答、什么算编造。我们团队把Prompt模板统一放在配置中心，版本化管理，线上改提示词不用发版，配合日志回放对比效果，这个管理思路在面试里很加分。

3.4 Java AI生态选型：Spring AI与LangChain4j的实际取舍

还有人会问“Java做AI应用是不是不如Python方便”。这个问题本身就是个陷阱。Python在模型训练和实验阶段确实强，但Java在后端集成、稳定性、并发处理、与现有微服务体系打通这些方面有明显优势。现在的Java生态里已经有Spring AI和LangChain4j这类框架，把模型调用、向量存储、Prompt模板、模型对话封装成了Spring风格或链式调用风格，Java工程师可以用熟悉的姿势接入AI。

选型上我倾向于这样判断：如果项目已经重度使用Spring Boot，Spring AI的接入成本更低，对话服务、向量存储、函数调用都有自动配置，用起来像操作一个普通Spring组件；如果更关注Agent编排和工具调用层面的抽象完整度，可以研究一下LangChain4j。但这类框架迭代速度很快，生产落地前必须做小范围验证，确认模型API版本兼容情况、流式接口是否满足要求、超时配置和限流策略能不能在框架上自由定制。面试里能主动说“我们做过一个最小验证项目，评估了两个框架，最后选了某个，原因是……”，比你简历上写十句“精通AI”都管用。

4. 面试实战应对策略：场景题、选型题与项目经验表达

知识点梳理得再细，最终还是要落到“开口答题”上。这段时间我帮人做模拟面试最大的感受是：很多人不是不会，而是不会组织内容，答案零散没主线。所以这一章专门讲答题策略。

4.1 场景题的推演式答法：从表象到本质

微服务面试特别容易出场景题，比如“用户反馈下单特别慢，你怎么办”“某个服务突然OOM，怎么处理”“大促之前要做哪些容量评估”。这类题没有标准答案，考察的是解决问题的思路。

我常用的是四步推演：定义问题、找瓶颈、给方案、聊验证。下单慢先定义是偶发还是持续、是单用户还是全量用户、是下单接口整体慢还是某个环节慢，先通过TraceID把链路拆开，定位到网关、订单、支付还是数据库；找到瓶颈后再谈方案，是缓存没生效、是数据库慢查询、还是下游依赖超时；最后还要说怎么验证，比如灰度上线、对比监控指标。按这个框架答，面试官能跟着你的思路走，就算最终结论不是最优解，考察目的也达到了。最怕的是直接跳结论：“肯定是数据库慢，加索引就行。”这种答案既没有过程也没有验证，基本告别高分。

4.2 技术选型题的“三段式”答题框架

“为什么不直接用XX，而是选YY”是另一类高频题，涉及注册中心、消息队列、缓存、AI框架等各种选型。技术选型题有个万能的“三段式”框架：先说业务约束，再说候选方案对比，最后给决策和理由。

举个具体例子，被问到“为什么用Redis做分布式锁”：先摆约束，我们的场景是抢券，要求高吞吐、低延迟，且对极端情况下的锁失效容忍度高；再对比方案，数据库唯一索引简单但性能上不去，ZooKeeper加临时节点可靠性好但吞吐低、运维成本高，Redis的SETNX配合Lua保证原子性，性能满足；最后决策，选Redis，同时通过设置合理的超时时间、使用看门狗续期机制、配合Redisson客户端的封装来规避锁过期问题。“约束加对比加决策”的结构，让答案有逻辑也有纵深，比直接说“Redis快”强太多。

这个方法适用面极广，AI选型题也一样。比如RAG为什么不用微调，也可以用这套框架：知识更新频繁、数据量大、要求可追溯，所以选RAG；微调则更适合固定风格和技能的沉淀。

4.3 项目经验表达：把“负责了XX模块”讲出含金量

面试到后面，项目经验基本是定胜负的环节。常见的问题是候选人把项目描述成流水账：“我负责订单模块，用了Spring Cloud，搭了Nacos，写了CRUD接口。”面试官听完毫无印象。

我更推荐用“背景、目标、动作、结果、反思”五段式来讲一个项目。背景是业务为什么要做，目标是怎么量化衡量，动作是你个人实际的方案、选型、实施细节，结果是上线后的指标变化和线上表现，反思是这个项目如果再给你一次机会，哪里会改。举个例子，不要说“我做了RAG知识库问答”，而是说“业务背景是客服需要快速查历史工单，目标是人工处理时长降低30%。我负责切分策略和在线检索链路，对比了固定窗口和语义切分，最终选了按段落加重叠的切分，线上平均召回相关度提升了X%，后来发现权限过滤在召回前做比召回后做更高效，如果能重来我会把权限模型提前设计进去。”这种讲法有故事线、有技术细节、有业务指标，面试官很难不被带着走。

提示：项目经验里提到的每一个技术点，你都要准备好被追问。比如你讲了RAG，面试官可能当场问“切分粒度怎么影响生成质量”，所以讲出来的东西一定是你亲自验证过的深水区，不要为了拔高项目强行堆名词。

5. 高频面试错题复盘：微服务与AI应用避坑实战

最后这一章，我把模拟面试和真实面试里出现频率特别高的坑整理一下。这些都是直接影响到面试结果的经验。

5.1 微服务经典题里最容易翻车的三个回答

第一个是“微服务拆分后数据库拆不拆”。很多人张嘴就说“肯定拆啊，每个服务独立库”，被追问“那跨服务查询怎么做”又答不上来。数据库拆分要谨慎，拆完就得面对跨库查询、数据冗余、分布式事务，所以高明的回答会先讨论业务关联度和查询复杂度，再决定哪些表跟服务走、哪些保留共享库或通过数据同步方式拆开。

第二个是“Nacos和Eureka的区别”。很多人只能说出“Nacos国内用得多”，没有对比深度。要从数据一致性、健康检查机制、实例类型、配置中心能力、协议栈这几个维度展开，比如Eureka只有临时实例概念，Nacos有临时实例和持久实例，临时实例走心跳检测，持久实例走健康检查主动探测；再比如Nacos默认是gRPC长连接，服务端变化可以更快推送，Eureka要靠客户端定时拉取。这些维度讲全，证明你真用过。

第三个是“本地事务和分布式事务怎么选”。不少人的回答要么“全上都用分布式事务”要么“根本不用分布式事务”——两个极端都是坑。正确的打开方式是：优先通过业务设计避免跨服务事务，比如把多个写操作合并到一个服务内；避免不了的，评估最终一致性是否可以接受；必须强一致才考虑TCC。简单说，能用本地事务别引分布式事务，能用最终一致别上强一致。

5.2 AI应用面试题的典型错误与修正

AI部分的回答也有一些共性错误。最大的坑就是把“调用过大模型API”包装成“做过AI应用”，被发现后整个面试印象分断崖式下跌。正常的做法是聚焦某一个具体工程问题讲透，比如“我把调用大模型接口从同步改造为SSE流式，解决了用户等待时长问题，过程中踩了连接被掐断、断线未取消请求两个坑”。哪怕只有一个点，也证明你有真实落地经验。

第二个坑是“RAG和微调混为一谈”或“只会二选一”。面试官问到为什么用RAG不用微调，很多人答不上来。RAG适合知识频繁更新、数据量大、需要引用可追溯的场景，微调适合风格迁移、特定任务技能固化，两者甚至能结合。用选型三段式答这个问题，基本不会跑偏。

第三个坑是“结构化输出翻车”。有人说“我加了提示词让模型输出JSON”，这句话暴露的恰恰是没有工程保障意识。面试官期待听到的是一整套可靠性体系：JSON模式、Function Calling、输出校验、清洗兜底、人工审核。越往后说越有含金量。

5.3 高频问题速查表

这部分整理成表格，方便面试前快速过一遍。

表格里这些内容看起来多，但每条都可以用一两分钟讲透。关键是不要背结论，而是背结论背后的理由。

坦白讲，面试准备最怕的就是把知识学成一座孤岛。我自己复习和帮别人做模拟面试的过程中，最强烈的感受是微服务架构和AI应用技术虽然在考点上方向不同，面试官考察的却是同一件事——你能不能在一个复杂工程环境里把一个系统做好。强烈建议面试前找朋友做几轮模拟，把上面这些题逐个口头答一遍，你会发现很多“以为自己会了”的地方，一张嘴就露馅。这种突击比多刷几十道算法题对后端岗位的面试帮助更直接，也是我复盘这么多场面试之后最想强调的一件事。