朋友前两天去面了一家头部互联网公司的 Java 后端岗位回来跟我吐槽说三轮技术面被同一个面试官“谢飞机”从从容容地问了个底朝天。第一轮聊 Spring Boot 线程池第二轮钻 Kafka 幂等性第三轮直接拐到 AI Agent 和 RAG 落地上。他说自己答得七七八八但总觉得哪里差一口气。我把这三轮“灵魂拷问”从头到尾复盘了一遍发现这面试官问得确实刁但每道题背后都能拆出一串值得记下来的硬知识点。这篇文章就把整个实录和我的拆解写出来不管你是准备大厂面试还是单纯想把这几个技术点吃透都应该能从中捞到点干货。1. 第一轮拷问Spring Boot 线程池这题不只是背参数1.1 开场就翻车面试官没让背配置先问“你会在哪里用线程池”谢飞机的第一轮提问没有按套路出牌。大多数面经会从 ThreadPoolExecutor 的七个参数背起但他上来问的是在你负责的系统里哪些场景必须用线程池朋友第一反应是“异步发短信、异步写日志”这个回答本身不算错但只落在“异步”这一个维度上。面试官接着追问如果我现在有 10 万个任务要处理每个任务耗时 200ms你用线程池怎么设计这时候光说“newFixedThreadPool(10)”就明显不够了得把任务类型、队列容量、拒绝策略、监控告警都串起来。这种问法其实在暗示一个关键点大厂面试官不想听你背 API想听你做技术选型时的权衡逻辑。线程池在 Spring Boot 里最常见的落地位置其实有四类一是 Async 注解修饰的业务方法二是消息消费的并发拉取三是定时任务批处理四是外部接口的调用隔离。每个场景对线程池参数的诉求都不一样比如消费消息的线程池更关心吞吐量和堆积水位接口调用隔离的线程池更关心超时和熔断。如果只说“异步”等于没回答“为什么”。我在实际项目里有一个比较典型的用法把第三方接口调用单独拆一个线程池核心线程数按该接口的 TP99 耗时和 QPS 估算队列容量设成有界队列拒绝策略用 CallerRunsPolicy让超过阈值的任务回退到调用线程执行。这样做的目的是保护第三方服务不被突刺流量打垮同时利用调用线程的阻塞天然实现背压。如果只在代码里写 Async 不加线程池配置Spring 默认的 SimpleAsyncTaskExecutor 每次都会新建线程在高并发下基本等于自杀。1.2 线程池参数背后的“为什么”先核心再队列再最大线程既然聊到参数谢飞机自然不会放过计算公式。他问的问题很具体corePoolSize、maxPoolSize、queueCapacity 三个值怎么配合线程池的工作流程到底是怎么走的我建议所有准备面试的人把下面这个流程刻进脑子里新任务到达时先判断当前工作线程数是否小于核心线程数是则创建线程执行否则尝试放入阻塞队列队列满了再尝试创建线程直到 maxPoolSize如果连 maxPoolSize 都满了才走拒绝策略。这个顺序决定了三个参数之间的关系也决定了性能调优的方向。假设一个系统核心线程数设为 10队列容量设为 1000最大线程数设为 20。那么当并发任务超过 10 个时新增任务会先往队列里塞直到队列塞满 1000 个第 1001 个任务才会触发创建新线程达到 20 个线程后第 1021 个任务开始触发拒绝策略。也就是说最大线程数在大量任务到达时可能根本不会被触发因为队列先把流量“吃”掉了。这里面藏着大厂最爱挖的一个坑如果你把队列设置成无界队列比如 LinkedBlockingQueue 不传容量那 maxPoolSize 和拒绝策略就全部失效了。因为队列永远不会满线程数只会停留在 corePoolSize任务全堆在内存里。一旦任务堆积过多轻则 OOM重则拖垮整个应用。所以我在项目里一律使用有界队列并且给队列设置一个合理的水位告警比如队列超过 80% 容量就报警这比事后看日志找问题要高效得多。核心线程数怎么估算我习惯用这个公式核心线程数 单线程吞吐量的倒数 × 目标 QPS × 缓冲系数。举个例子一个任务平均耗时 100ms单线程吞吐就是 10 TPS目标支撑 500 QPS那么理论线程数就是 500 / 10 50再加 20% 缓冲核心线程数可以设在 60 左右。当然这是理想模型真实系统还要结合 CPU 密集型还是 IO 密集型的判断。IO 密集型的线程数可以粗略按“CPU 核数 × 2”起步再压测调整CPU 密集型则按“CPU 核数 1”来。面试时能把这个推导过程讲清楚比单纯背出一个“核数×2”要有说服力得多。1.3 拒绝策略怎么选AbortPolicy 不是唯一答案线程池的拒绝策略是谢飞机追问的第二个细节。JDK 默认的 AbortPolicy 是直接抛 RejectedExecutionException很多人就用默认的被问了才知道有四种策略AbortPolicy抛异常、CallerRunsPolicy调用者执行、DiscardPolicy静默丢弃、DiscardOldestPolicy丢弃队列中最旧的任务。面试官问了一句你线上敢不敢用 DiscardPolicy朋友说不敢因为数据丢了没有感知。面试官追问那 CallerRunsPolicy 就没有问题吗这是一个非常经典的陷阱题。CallerRunsPolicy 的逻辑是让提交任务的线程自己执行被拒绝的任务这样做的好处是任务不会丢同时提交线程被阻塞后会自然降低任务提交速度形成一种简单的背压机制。但它的问题也很明显如果提交任务的线程是 Tomcat 的请求线程那么这些线程会被长时间占用一旦任务积压严重Tomcat 的线程池会被拖垮最终导致接口响应超时甚至拒绝连接。所以在高并发场景下CallerRunsPolicy 不能无脑用它只适合在能接受调用方线程被占用的场景里使用。我个人的落地经验是核心业务任务用 CallerRunsPolicy 或自定义策略比如把拒绝的任务写入 Kafka 或者本地文件做补偿非核心任务用 DiscardPolicy 加监控上报。自定义拒绝策略其实不复杂实现 RejectedExecutionHandler 接口在 rejectedExecution 方法里把任务信息记录下来然后发送到告警通道。面试中如果能讲出“我根据任务的业务属性选择不同策略并配套监控和补偿机制”就能和那些只会背概念的人拉开差距。1.4 Spring Boot 线程池的隐藏考点Async 失效与线程池隔离第一轮面试快结束时谢飞机突然问了一句你项目里的 Async 注解为什么有时候不生效这个问题现场很多人会懵。Async 不生效最常见的原因是 Spring AOP 代理失效也就是同一个类内部方法调用走的是 this 引用而不是代理对象注解自然就拦截不到。解决办法有三种把异步方法拆到另一个 Bean 里、注入 self 引用调用、用 AsyncAspect 手动织入。面试官要听的其实是你对 Spring 动态代理生效机制的理解而不是单纯记一个“同类调用不生效”的结论。另外一个很有分量的追问是关于线程池隔离的。多个业务模块共用一个线程池会出现什么情况答案是互相干扰。比如订单模块的突发流量把线程池占满会导致库存模块的异步任务全部排队甚至被拒绝。所以在大厂的项目里线程池隔离是标配按业务域拆分不同的 ThreadPoolTaskExecutor每个执行器设置独立的 corePoolSize、maxPoolSize、队列容量、拒绝策略、线程名前缀。Spring Boot 里可以通过 Configuration 定义一个 ThreadPoolTaskExecutor Bean再用 Qualifier 指定注入代码上并不复杂但能体现你对线上稳定性设计的理解深度。2. 第二轮拷问Kafka 幂等性从入门到源码级别的追问2.1 先从语义入手为什么消息系统需要幂等第二轮谢飞机把话题转向 Kafka开场问题很直接Kafka 为什么会重复消息朋友的回答是“消费者处理完消息但没提交 offset又发生了重平衡就会重复消费”这个答案只答对了一半。Kafka 消息重复的根本原因有两个方向生产者发送时因为网络超时重试导致 broker 收到重复消息消费者处理成功后提交 offset 失败导致 rebalance 后重复消费。面试官就是想听你把两端的问题都点出来然后引出幂等性这个技术动作。幂等性的本质是同一个操作执行多次结果和执行一次完全一致。放在消息场景里就是消费者重复收到同一条消息时不能把订单创建两次、不能把余额扣两次、不能重复插入同一条记录。理解到这个层面面试官才满意因为他后面每一个问题都是围绕“如何保证这个效果”来展开的。这里我强烈建议大家先建立一套普适的消费幂等设计思路因为后面所有的技术细节都是为它服务的。我常用的设计方法有三层第一层是数据库唯一键约束用业务唯一 ID 做唯一索引重复插入会被数据库挡住第二层是处理前查重用 Redis 的 SETNX 或者数据库查询判断消息是否已经处理过第三层是状态机设计比如订单状态从“待支付”到“已支付”只能流转一次。这三层不是互相替代的关系而是配合使用的因为数据库唯一键只能防重复插入防不了状态流转被重复执行。2.2 生产者幂等enable.idempotence 背后的 PID 机制面试官接着往下问Kafka 生产者怎么开启幂等配置参数是哪个朋友答了 enable.idempotencetrue这个答对了。但谢飞机马上追问这个参数底层是怎么实现的如果没看过源码这题基本就卡住了。Kafka 生产者幂等机制的核心是 PIDProducer ID和 Sequence Number。每个 Producer 在初始化时会分配一个唯一的 PID同时为每个分区维护一个从 0 开始递增的 Sequence Number。生产者每发送一条消息Sequence Number 就加一。Broker 端在内存中会缓存每个 PID 分区最近收到的 5 条消息的序号如果新消息的序号刚好是缓存中最大序号加一就正常接收如果序号小于缓存中的最大序号说明是重复消息直接拒绝如果序号大于最大序号加一说明中间有消息丢失会报 OutOfOrderSequenceException。这套机制通过序号连续性判断重复和乱序不需要额外网络请求性能开销很小。不过面试官没有止步于此。他抛了一个进阶问题幂等生产者能够解决跨分区的事务吗答案是不能。生产者的幂等只保证单个分区内不重复、不丢失如果要跨分区原子性写入需要引入 Kafka 事务。事务机制通过 Transaction Coordinator 协调开启事务时发送 FindCoordinator 请求找到协调者再通过 InitPidRequest 获取 PID读写消息时通过 AddPartitionsToTxnRequest 和 EndTxnRequest 提交或中止事务。面试时能把这个链路讲出来就已经是超过绝大多数候选人的水平了。2.3 消费者幂等才是真正的业务重头戏第二轮的问题在消费者这边才真正进入深水区。谢飞机问假设你用的消息系统不支持生产者幂等消费者怎么保证业务不重复这个问题其实是在考察你能不能脱离框架去思考业务设计。我的建议是把消费幂等的关键压在业务唯一 ID 上而不是压在消息系统的可靠性上。具体操作是这样的业务消息体里带上一个全局唯一的业务主键比如订单号、支付流水号、操作单号。消费者在处理前先用这个主键去 Redis 执行 SETNX如果返回成功说明第一次处理继续业务逻辑如果返回失败说明之前处理过了直接提交 offset 并返回。SETNX 的 key 可以设置一个过期时间比如 24 小时或 48 小时避免 Redis 内存无限增长。如果 Redis 不可用可以退回到数据库唯一键或者本地去重表。这个方案的优点是不依赖 Kafka 的幂等配置对于任意消息队列都适用而且很容易验证。面试官在听到这里时还追加了一个问题如果同一个业务请求因为重试生成了不同的消息 ID但业务主键相同你的去重逻辑还能生效吗答案是能因为去重靠的是业务主键而不是消息 ID。所以请记住这句话消息 ID 的去重不是真正的业务幂等业务主键的去重才是。2.4 面试官埋的一个坑幂等和事务不能混为一谈谢飞机最后在 Kafka 这块收了一个非常刁钻的问题Kafka 开启幂等和开启事务是一回事吗很多人会在这道题上栽跟头。两者确实相关但解决的问题不同幂等解决的是“单分区内不重复、不乱序”事务解决的是“跨分区跨会话的原子可见性”。开启事务时 Kafka 会自动开启幂等但开启幂等不意味着具备事务能力。事务消息在消费端的表现也值得展开说。跨分区事务写入后消费者只有读到 Commit 标志才能看到这条消息未提交的事务消息对消费者不可见。这个机制保证了读的一致性但也可能导致消费延迟因为消费端要等事务提交才能看到消息。面试中如果你能主动讲到“事务性能开销较大对延迟敏感的业务慎用”面试官会认为你有实际线上经验而不只是停留在文档层面。3. 第三轮拷问AI Agent 与 RAG 落地从理论聊到扛并发3.1 RAG 的标准链路从文档入库到检索生成每一环都有坑第三轮开场谢飞机的画风突变从消息中间件直接切到了 AI Agent。他先问了一个非常落地的问题你们做 AI 知识库问答RAG 的完整环节是什么朋友答了“加载文档、切分、向量化、检索、交给大模型生成”。面试官追问文档切分这一步你用什么策略为什么这个问题直接暴露了很多人对 RAG 的理解停留在概念层。文档切分是决定 RAG 效果的第一道关卡。切得太粗一块文本里包含多个主题向量检索时容易被不相关的信息干扰切得太细单块文本语义不完整检索出来也不知道在说什么。我实践下来比较靠谱的做法是分层切分先按文档结构切到章、节、段再对每个段落按语义完整性和最大 token 限制做二次切分。比如一个技术文档可以按 markdown 标题切分一级再对正文做滑动窗口切分窗口大小 500 到 800 字符重叠 100 到 150 字符。重叠区间的目的是避免句子被硬生生切断导致语义断裂。向量化这一步也有很多细节。选 embedding 模型时不能只看 MTEB 榜单分数要看它对你领域文本的适配度。比如做医疗知识库和做法律知识库对术语的语义理解差距非常大。我建议用领域内的真实问题做召回评测而不是拿通用数据集测出来的分数来选型。向量存储方面如果数据量在百万级以下可以用开源的向量数据库比如 Chroma、Milvus、Qdrant如果数据量很大而且后续要做过滤条件组合查询要考虑 ES 加向量插件的方案或者直接选云厂商的向量检索服务。面试时把这些权衡讲清楚比背一套“标准流程”要有说服力得多。还有一个高频疑问也就是热搜里那条“rag知识库能存储图片嘛”很多人搞不清楚。RAG 的向量检索本身处理的是文本向量图片不能直接进向量库参与语义检索。但如果你的场景需要图文混合问答可以采用两级方案文本部分走 RAG 检索图像部分单独走多模态向量模型或者把图片转成文字描述后入库。也就是说图片不是不能存而是要看你用的检索链路是否支持多模态。单纯塞一张图片进文本向量库召回效果基本是灾难。面试时遇到这类问题能够分清楚“向量库存的是什么对象”以及“检索链路支持什么模态”就算答到点子上了。3.2 RAG 的检索瓶颈召回率、重排序与知识冲突谢飞机没有停留在流程层面他直接问了一个让很多人头疼的实际问题检索出来一堆相似文本但大模型回答还是不准问题可能出在哪这个问题的标准演进路径是召回率不够、混入噪声、排序不合理、上下文窗口塞不下。召回率不够的根源通常是分块粒度和向量模型的能力不匹配。你切了 800 字的块但用户问题涉及的内容分散在两个相邻块里单块检索只能命中一半答案自然残缺。解决思路是增加混合检索把向量召回和关键词召回结合起来向量召回负责语义相似BM25 这种关键词召回负责精确匹配然后用重排序模型把两组结果统一打分排序。很多商用 RAG 产品比开源方案的体验好很大程度就赢在重排序这一步。知识冲突是另一个大坑。知识库里可能同时存在“2023 年的产品价格”和“2025 年的新品价格”检索出来的文本自相矛盾大模型不知道信谁。这个问题不能指望大模型自己判断它更倾向于把自己训练语料里的信息掺进来。我的做法是给知识库的文档打时间戳和来源标签在检索结果里强制加入 metadata 过滤并且在拼接 prompt 时明确提示模型优先采用带最新时间戳的信息。如果面试官追问“大模型不听话怎么办”可以回答“RAG 的本质不是让模型更聪明而是把答案的信息源限定在你的知识范围内因此信息源的冲突要在检索层就解决掉不能留给生成层做自由发挥”。3.3 Agent 不是玩具AI Agent 怎么扛住真实并发流量聊完 RAG 的单链路谢飞机抛出了第三轮的压轴题AI Agent 在线上怎么扛并发不同于普通接口调用Agent 的每一次请求可能涉及多轮大模型调用、多步工具调用、多次检索整体耗时会成倍放大。朋友当时愣了一下因为这个话题很多人聊能力、聊 prompt但很少在面试里聊架构层面的并发问题。Agent 服务的并发瓶颈和大模型的推理吞吐强相关。如果直接同步调用大模型一个请求里 5 次模型调用耗时就是 5 倍叠加线程被拖死这就是所谓“ai agent 怎么扛并发”的核心痛点。我拆解过这个问题的可行方案至少可以分四层来打第一层是异步化。把 Agent 的执行链路设计成异步任务用前面第一轮聊的线程池去编排避免请求线程长时间阻塞同时用 Future 或回调来聚合结果。第二层是缓存。对用户问题做语义相似度匹配命中缓存知识库的直接返回不用每次重建回答工具调用结果也可以按参数签名做短时缓存。第三层是降级与限流。Agent 服务必须预设大模型调用成本的熔断阈值比如每分钟 token 消耗超过阈值就拒绝非核心用户请求。第四层是推理层优化比如流式输出、批量推理、小模型先行粗筛、大模型只做关键归纳。这里有一个容易被忽略的细节Agent 的工具调用如果涉及 RAG 检索检索的吞吐会成为隐形瓶颈。一个高并发的 Agent 问答服务RAG 检索可能占到整个链路 50% 以上的延迟。所以检索接口要做并发控制不能因为 Agent 的并发请求进来就直接压垮底层向量数据库。我在实际项目里会给检索服务单独配一个线程池设置队列上限和超时时间检索超时直接走兜底话术不让用户无限等待。面试官对 Agent 这块的最后一个问题是你的 RAG 服务上线后怎么评估效果这个问题很多人以为要答准确率、召回率但这只是离线指标。线上评估更关注最终答案的可接受率、人工反馈、检索命中的置信度分布。你可以设计一个简易的反馈闭环用户对回答点踩时把问题和答案落库定期抽检进入知识库扩充流程从而形成数据飞轮。如果能在面试中把离线评测、在线监控、反馈闭环三层都讲完整就已经是一套很成熟的 RAG 落地解法了我相信大多数面试官到这里都会认可。4. 三轮面试复盘大厂到底在考什么、问法背后的逻辑4.1 从问题看意图这根本不是考察“知识点”是考察“连接力”把三轮问题放在一起看你会发现谢飞机的提问逻辑非常清晰每个领域他都先问场景应用再问底层原理最后追问线上权衡。线程池的问题是“你在哪用、怎么配、拒绝策略怎么选”Kafka 是“重复消息根源、幂等机制、消费端幂等”RAG 是“标准链路、切分策略、检索瓶颈、并发架构”。这些问题的共同点是都不考你背诵能力而是在考察你在一个真实系统里能不能把多个知识模块连接起来。所谓的“连接力”就是能不能把线程池的拒绝策略和消息消费的堆积保护连起来能不能把 Kafka 的幂等机制和业务主键的唯一约束连起来能不能把 RAG 的重排序和大模型生成的上下文窗口连起来。大厂面试官真正想知道的是把你招进来线上出问题时你能不能快速定位、能不能做出合理的架构决策。如果你只会单点知识背得再熟也过不了这三轮。4.2 我的复盘对照答法升级的几个关键点复盘时我把朋友的答案和更优的答案做了对照发现差距主要集中在三个方面。第一朋友习惯“定义先行”面试官问线程池参数他先背参数列表再解释含义。更好的答法是“先讲业务场景再给参数设计再讲怎么验证”。比如他说异步任务多我改成“我们的异步任务分两类一类是用户无感知的日志清洗一类是下单后的积分计算两者对延迟和可靠性的要求不同因此拆了两个线程池”。同样聊线程池这种答法听起来更像在做系统设计而不是在背八股。第二朋友不太敢暴露“不知道”。谢飞机问 Kafka 事务的底层交互时朋友说了“我了解得比较浅”其实完全可以用另一个方式接住把懂的部分讲清楚把不懂的部分缩小范围再提出自己的推测。面试官一般不会因为你某个细节不懂就否定你而是会看你在未知领域是否具备推导能力。第三朋友在 RAG 环节几乎没提数据评估和线上监控一直在说“流程”。这其实暴露了实践深度不足。一个真正做过 RAG 项目的人一定会提到评估数据集的构建、bad case 分析、知识更新流程。这些才是决定一个 AI 功能能不能上线、上线后稳不稳定的关键。后面这块我给他补充了一套完整的内容如果你们平时也有做 AI 应用的需求强烈建议把离线评估和线上监控尽早纳入迭代计划不要等用户反馈出来了才被动应对。4.3 从面试延伸出的通用方法论系统性准备大厂技术面总结这次面试我提炼出三个对任何技术岗位都适用的准备方法。第一个方法是“每个技术点至少要能讲出两层”第一层是它解决什么问题第二层是它引入了什么新问题。比如线程池解决了线程复用问题但引入了参数配置不当导致的任务堆积问题Kafka 幂等解决了重复消息问题但引入了 PID 内存占用和乱序检测问题RAG 解决了大模型幻觉问题但引入了知识时效性和检索冲突问题。能把这两层讲清楚就说明你不是停留在表面。第二个方法是“用业务故事串起技术细节”。面试官不关心你背了多少 API关心你有没有真实的系统思考。准备面试时拿出自己最熟悉的三个项目每个项目分别想清楚为什么用这个技术、不用会怎样、线上的参数是怎么调出来的、出了故障怎么排查。这套故事练熟了不管是面线程池还是 Kafka都能把对话主动权拉到自己熟悉的领域。第三个方法是“主动亮出权衡和取舍”。面试官问你喜欢用什么框架时很多人会说“某个框架很好用”这是非常糟糕的回答。更好的思路是“这个框架在这里很好用但我发现它在另一个场景下存在什么问题所以我在那里换了另一种方案”。敢于做取舍、能讲清楚取舍理由的候选人才是大厂真正想找的人。5. 关键技术点速查表面试前两小时翻这一份就够了写到这里我把这三轮面试涉及的关键技术点按领域整理成了一张速查表方便大家临阵磨枪。表格里每一行都提炼了核心考点和最容易翻车的细节你可以根据自己的薄弱项重点补强。技术领域核心考点一句话记忆高频深挖方向Spring Boot 线程池核心参数与执行流程先核心、再队列、再最大、再拒绝无界队列导致 maxPoolSize 失效线程池拒绝策略四种策略适用场景CallerRuns 适合要背压Discard 会丢任务自定义拒绝策略与补偿机制Async 失效AOP 代理机制同类调用不经过代理注解不生效拆分 Bean 或注入 selfKafka 生产者幂等PID Sequence Number分区内有序可达跨分区不行OutOfOrderSequenceException 含义Kafka 事务事务协调器与原子提交事务开启幂等幂等不一定事务未提交消息不可见导致消费延迟消费端幂等业务主键去重靠业务 ID不靠消息 IDSETNX / 唯一键 / 状态机三件套RAG 文档切分分层切分与窗口重叠粗切失语义细切断上下文500-800 字窗口 100-150 重叠向量化与召回混合检索 重排序向量找语义BM25 找精确重排序模型统一打分RAG 知识冲突时间戳与来源过滤检索层解决别留给生成层metadata 过滤 prompt 约束Agent 并发架构异步化 缓存 降级不能同步阻塞请求线程检索接口单独线程池限流RAG 效果评估离线评测 线上监控不仅看准确率看最终答案可接受度反馈闭环驱动知识库迭代这张表不需要死记。我的建议是对照你已经掌握的内容做快速筛查看见哪一行的“深挖方向”自己不熟悉马上去查一下相关源码或者写个 demo 验证效果远好于把整张表从头到尾背一遍。面试前两个小时过一遍这张表再把自己项目的两个真实案例在脑子里跑一遍基本就可以上场了。6. 最后分享一点个人感受把这三轮面试完整复盘下来我最深的感觉是技术面试正在从“考知识点”变成“考手艺”。线程池、Kafka 幂等性、AI Agent 和 RAG这三个话题看上去风马牛不相及但它们背后都指向同一个能力你能不能在一个复杂系统里把一个看似简单的技术动作放到整个链路上权衡利弊。线程池参数不是背出来的是算出来调出来的Kafka 幂等不是配个参数就完事是跟业务主键一起去兜底的RAG 不是把文档切碎了塞进向量库就上线是要一层一层解决切分、检索、冲突、并发和评估问题的。我建议所有准备面试的朋友平时做技术积累时养成一个习惯每学一个技术点都追问一遍“这个技术带来了什么新问题我的线上系统是怎么解决它的”。长期坚持下去你会发现自己讲出来的技术内容天然就带有实战的分量感这比任何面经都管用。希望这次实录的拆解能帮到正在准备面试的你也欢迎你带着自己的复盘结论来交流碰撞一起把这些问题拆得更透。 大厂Java面试实录：线程池、Kafka幂等与RAG落地拆解
朋友前两天去面了一家头部互联网公司的 Java 后端岗位回来跟我吐槽说三轮技术面被同一个面试官“谢飞机”从从容容地问了个底朝天。第一轮聊 Spring Boot 线程池第二轮钻 Kafka 幂等性第三轮直接拐到 AI Agent 和 RAG 落地上。他说自己答得七七八八但总觉得哪里差一口气。我把这三轮“灵魂拷问”从头到尾复盘了一遍发现这面试官问得确实刁但每道题背后都能拆出一串值得记下来的硬知识点。这篇文章就把整个实录和我的拆解写出来不管你是准备大厂面试还是单纯想把这几个技术点吃透都应该能从中捞到点干货。1. 第一轮拷问Spring Boot 线程池这题不只是背参数1.1 开场就翻车面试官没让背配置先问“你会在哪里用线程池”谢飞机的第一轮提问没有按套路出牌。大多数面经会从 ThreadPoolExecutor 的七个参数背起但他上来问的是在你负责的系统里哪些场景必须用线程池朋友第一反应是“异步发短信、异步写日志”这个回答本身不算错但只落在“异步”这一个维度上。面试官接着追问如果我现在有 10 万个任务要处理每个任务耗时 200ms你用线程池怎么设计这时候光说“newFixedThreadPool(10)”就明显不够了得把任务类型、队列容量、拒绝策略、监控告警都串起来。这种问法其实在暗示一个关键点大厂面试官不想听你背 API想听你做技术选型时的权衡逻辑。线程池在 Spring Boot 里最常见的落地位置其实有四类一是 Async 注解修饰的业务方法二是消息消费的并发拉取三是定时任务批处理四是外部接口的调用隔离。每个场景对线程池参数的诉求都不一样比如消费消息的线程池更关心吞吐量和堆积水位接口调用隔离的线程池更关心超时和熔断。如果只说“异步”等于没回答“为什么”。我在实际项目里有一个比较典型的用法把第三方接口调用单独拆一个线程池核心线程数按该接口的 TP99 耗时和 QPS 估算队列容量设成有界队列拒绝策略用 CallerRunsPolicy让超过阈值的任务回退到调用线程执行。这样做的目的是保护第三方服务不被突刺流量打垮同时利用调用线程的阻塞天然实现背压。如果只在代码里写 Async 不加线程池配置Spring 默认的 SimpleAsyncTaskExecutor 每次都会新建线程在高并发下基本等于自杀。1.2 线程池参数背后的“为什么”先核心再队列再最大线程既然聊到参数谢飞机自然不会放过计算公式。他问的问题很具体corePoolSize、maxPoolSize、queueCapacity 三个值怎么配合线程池的工作流程到底是怎么走的我建议所有准备面试的人把下面这个流程刻进脑子里新任务到达时先判断当前工作线程数是否小于核心线程数是则创建线程执行否则尝试放入阻塞队列队列满了再尝试创建线程直到 maxPoolSize如果连 maxPoolSize 都满了才走拒绝策略。这个顺序决定了三个参数之间的关系也决定了性能调优的方向。假设一个系统核心线程数设为 10队列容量设为 1000最大线程数设为 20。那么当并发任务超过 10 个时新增任务会先往队列里塞直到队列塞满 1000 个第 1001 个任务才会触发创建新线程达到 20 个线程后第 1021 个任务开始触发拒绝策略。也就是说最大线程数在大量任务到达时可能根本不会被触发因为队列先把流量“吃”掉了。这里面藏着大厂最爱挖的一个坑如果你把队列设置成无界队列比如 LinkedBlockingQueue 不传容量那 maxPoolSize 和拒绝策略就全部失效了。因为队列永远不会满线程数只会停留在 corePoolSize任务全堆在内存里。一旦任务堆积过多轻则 OOM重则拖垮整个应用。所以我在项目里一律使用有界队列并且给队列设置一个合理的水位告警比如队列超过 80% 容量就报警这比事后看日志找问题要高效得多。核心线程数怎么估算我习惯用这个公式核心线程数 单线程吞吐量的倒数 × 目标 QPS × 缓冲系数。举个例子一个任务平均耗时 100ms单线程吞吐就是 10 TPS目标支撑 500 QPS那么理论线程数就是 500 / 10 50再加 20% 缓冲核心线程数可以设在 60 左右。当然这是理想模型真实系统还要结合 CPU 密集型还是 IO 密集型的判断。IO 密集型的线程数可以粗略按“CPU 核数 × 2”起步再压测调整CPU 密集型则按“CPU 核数 1”来。面试时能把这个推导过程讲清楚比单纯背出一个“核数×2”要有说服力得多。1.3 拒绝策略怎么选AbortPolicy 不是唯一答案线程池的拒绝策略是谢飞机追问的第二个细节。JDK 默认的 AbortPolicy 是直接抛 RejectedExecutionException很多人就用默认的被问了才知道有四种策略AbortPolicy抛异常、CallerRunsPolicy调用者执行、DiscardPolicy静默丢弃、DiscardOldestPolicy丢弃队列中最旧的任务。面试官问了一句你线上敢不敢用 DiscardPolicy朋友说不敢因为数据丢了没有感知。面试官追问那 CallerRunsPolicy 就没有问题吗这是一个非常经典的陷阱题。CallerRunsPolicy 的逻辑是让提交任务的线程自己执行被拒绝的任务这样做的好处是任务不会丢同时提交线程被阻塞后会自然降低任务提交速度形成一种简单的背压机制。但它的问题也很明显如果提交任务的线程是 Tomcat 的请求线程那么这些线程会被长时间占用一旦任务积压严重Tomcat 的线程池会被拖垮最终导致接口响应超时甚至拒绝连接。所以在高并发场景下CallerRunsPolicy 不能无脑用它只适合在能接受调用方线程被占用的场景里使用。我个人的落地经验是核心业务任务用 CallerRunsPolicy 或自定义策略比如把拒绝的任务写入 Kafka 或者本地文件做补偿非核心任务用 DiscardPolicy 加监控上报。自定义拒绝策略其实不复杂实现 RejectedExecutionHandler 接口在 rejectedExecution 方法里把任务信息记录下来然后发送到告警通道。面试中如果能讲出“我根据任务的业务属性选择不同策略并配套监控和补偿机制”就能和那些只会背概念的人拉开差距。1.4 Spring Boot 线程池的隐藏考点Async 失效与线程池隔离第一轮面试快结束时谢飞机突然问了一句你项目里的 Async 注解为什么有时候不生效这个问题现场很多人会懵。Async 不生效最常见的原因是 Spring AOP 代理失效也就是同一个类内部方法调用走的是 this 引用而不是代理对象注解自然就拦截不到。解决办法有三种把异步方法拆到另一个 Bean 里、注入 self 引用调用、用 AsyncAspect 手动织入。面试官要听的其实是你对 Spring 动态代理生效机制的理解而不是单纯记一个“同类调用不生效”的结论。另外一个很有分量的追问是关于线程池隔离的。多个业务模块共用一个线程池会出现什么情况答案是互相干扰。比如订单模块的突发流量把线程池占满会导致库存模块的异步任务全部排队甚至被拒绝。所以在大厂的项目里线程池隔离是标配按业务域拆分不同的 ThreadPoolTaskExecutor每个执行器设置独立的 corePoolSize、maxPoolSize、队列容量、拒绝策略、线程名前缀。Spring Boot 里可以通过 Configuration 定义一个 ThreadPoolTaskExecutor Bean再用 Qualifier 指定注入代码上并不复杂但能体现你对线上稳定性设计的理解深度。2. 第二轮拷问Kafka 幂等性从入门到源码级别的追问2.1 先从语义入手为什么消息系统需要幂等第二轮谢飞机把话题转向 Kafka开场问题很直接Kafka 为什么会重复消息朋友的回答是“消费者处理完消息但没提交 offset又发生了重平衡就会重复消费”这个答案只答对了一半。Kafka 消息重复的根本原因有两个方向生产者发送时因为网络超时重试导致 broker 收到重复消息消费者处理成功后提交 offset 失败导致 rebalance 后重复消费。面试官就是想听你把两端的问题都点出来然后引出幂等性这个技术动作。幂等性的本质是同一个操作执行多次结果和执行一次完全一致。放在消息场景里就是消费者重复收到同一条消息时不能把订单创建两次、不能把余额扣两次、不能重复插入同一条记录。理解到这个层面面试官才满意因为他后面每一个问题都是围绕“如何保证这个效果”来展开的。这里我强烈建议大家先建立一套普适的消费幂等设计思路因为后面所有的技术细节都是为它服务的。我常用的设计方法有三层第一层是数据库唯一键约束用业务唯一 ID 做唯一索引重复插入会被数据库挡住第二层是处理前查重用 Redis 的 SETNX 或者数据库查询判断消息是否已经处理过第三层是状态机设计比如订单状态从“待支付”到“已支付”只能流转一次。这三层不是互相替代的关系而是配合使用的因为数据库唯一键只能防重复插入防不了状态流转被重复执行。2.2 生产者幂等enable.idempotence 背后的 PID 机制面试官接着往下问Kafka 生产者怎么开启幂等配置参数是哪个朋友答了 enable.idempotencetrue这个答对了。但谢飞机马上追问这个参数底层是怎么实现的如果没看过源码这题基本就卡住了。Kafka 生产者幂等机制的核心是 PIDProducer ID和 Sequence Number。每个 Producer 在初始化时会分配一个唯一的 PID同时为每个分区维护一个从 0 开始递增的 Sequence Number。生产者每发送一条消息Sequence Number 就加一。Broker 端在内存中会缓存每个 PID 分区最近收到的 5 条消息的序号如果新消息的序号刚好是缓存中最大序号加一就正常接收如果序号小于缓存中的最大序号说明是重复消息直接拒绝如果序号大于最大序号加一说明中间有消息丢失会报 OutOfOrderSequenceException。这套机制通过序号连续性判断重复和乱序不需要额外网络请求性能开销很小。不过面试官没有止步于此。他抛了一个进阶问题幂等生产者能够解决跨分区的事务吗答案是不能。生产者的幂等只保证单个分区内不重复、不丢失如果要跨分区原子性写入需要引入 Kafka 事务。事务机制通过 Transaction Coordinator 协调开启事务时发送 FindCoordinator 请求找到协调者再通过 InitPidRequest 获取 PID读写消息时通过 AddPartitionsToTxnRequest 和 EndTxnRequest 提交或中止事务。面试时能把这个链路讲出来就已经是超过绝大多数候选人的水平了。2.3 消费者幂等才是真正的业务重头戏第二轮的问题在消费者这边才真正进入深水区。谢飞机问假设你用的消息系统不支持生产者幂等消费者怎么保证业务不重复这个问题其实是在考察你能不能脱离框架去思考业务设计。我的建议是把消费幂等的关键压在业务唯一 ID 上而不是压在消息系统的可靠性上。具体操作是这样的业务消息体里带上一个全局唯一的业务主键比如订单号、支付流水号、操作单号。消费者在处理前先用这个主键去 Redis 执行 SETNX如果返回成功说明第一次处理继续业务逻辑如果返回失败说明之前处理过了直接提交 offset 并返回。SETNX 的 key 可以设置一个过期时间比如 24 小时或 48 小时避免 Redis 内存无限增长。如果 Redis 不可用可以退回到数据库唯一键或者本地去重表。这个方案的优点是不依赖 Kafka 的幂等配置对于任意消息队列都适用而且很容易验证。面试官在听到这里时还追加了一个问题如果同一个业务请求因为重试生成了不同的消息 ID但业务主键相同你的去重逻辑还能生效吗答案是能因为去重靠的是业务主键而不是消息 ID。所以请记住这句话消息 ID 的去重不是真正的业务幂等业务主键的去重才是。2.4 面试官埋的一个坑幂等和事务不能混为一谈谢飞机最后在 Kafka 这块收了一个非常刁钻的问题Kafka 开启幂等和开启事务是一回事吗很多人会在这道题上栽跟头。两者确实相关但解决的问题不同幂等解决的是“单分区内不重复、不乱序”事务解决的是“跨分区跨会话的原子可见性”。开启事务时 Kafka 会自动开启幂等但开启幂等不意味着具备事务能力。事务消息在消费端的表现也值得展开说。跨分区事务写入后消费者只有读到 Commit 标志才能看到这条消息未提交的事务消息对消费者不可见。这个机制保证了读的一致性但也可能导致消费延迟因为消费端要等事务提交才能看到消息。面试中如果你能主动讲到“事务性能开销较大对延迟敏感的业务慎用”面试官会认为你有实际线上经验而不只是停留在文档层面。3. 第三轮拷问AI Agent 与 RAG 落地从理论聊到扛并发3.1 RAG 的标准链路从文档入库到检索生成每一环都有坑第三轮开场谢飞机的画风突变从消息中间件直接切到了 AI Agent。他先问了一个非常落地的问题你们做 AI 知识库问答RAG 的完整环节是什么朋友答了“加载文档、切分、向量化、检索、交给大模型生成”。面试官追问文档切分这一步你用什么策略为什么这个问题直接暴露了很多人对 RAG 的理解停留在概念层。文档切分是决定 RAG 效果的第一道关卡。切得太粗一块文本里包含多个主题向量检索时容易被不相关的信息干扰切得太细单块文本语义不完整检索出来也不知道在说什么。我实践下来比较靠谱的做法是分层切分先按文档结构切到章、节、段再对每个段落按语义完整性和最大 token 限制做二次切分。比如一个技术文档可以按 markdown 标题切分一级再对正文做滑动窗口切分窗口大小 500 到 800 字符重叠 100 到 150 字符。重叠区间的目的是避免句子被硬生生切断导致语义断裂。向量化这一步也有很多细节。选 embedding 模型时不能只看 MTEB 榜单分数要看它对你领域文本的适配度。比如做医疗知识库和做法律知识库对术语的语义理解差距非常大。我建议用领域内的真实问题做召回评测而不是拿通用数据集测出来的分数来选型。向量存储方面如果数据量在百万级以下可以用开源的向量数据库比如 Chroma、Milvus、Qdrant如果数据量很大而且后续要做过滤条件组合查询要考虑 ES 加向量插件的方案或者直接选云厂商的向量检索服务。面试时把这些权衡讲清楚比背一套“标准流程”要有说服力得多。还有一个高频疑问也就是热搜里那条“rag知识库能存储图片嘛”很多人搞不清楚。RAG 的向量检索本身处理的是文本向量图片不能直接进向量库参与语义检索。但如果你的场景需要图文混合问答可以采用两级方案文本部分走 RAG 检索图像部分单独走多模态向量模型或者把图片转成文字描述后入库。也就是说图片不是不能存而是要看你用的检索链路是否支持多模态。单纯塞一张图片进文本向量库召回效果基本是灾难。面试时遇到这类问题能够分清楚“向量库存的是什么对象”以及“检索链路支持什么模态”就算答到点子上了。3.2 RAG 的检索瓶颈召回率、重排序与知识冲突谢飞机没有停留在流程层面他直接问了一个让很多人头疼的实际问题检索出来一堆相似文本但大模型回答还是不准问题可能出在哪这个问题的标准演进路径是召回率不够、混入噪声、排序不合理、上下文窗口塞不下。召回率不够的根源通常是分块粒度和向量模型的能力不匹配。你切了 800 字的块但用户问题涉及的内容分散在两个相邻块里单块检索只能命中一半答案自然残缺。解决思路是增加混合检索把向量召回和关键词召回结合起来向量召回负责语义相似BM25 这种关键词召回负责精确匹配然后用重排序模型把两组结果统一打分排序。很多商用 RAG 产品比开源方案的体验好很大程度就赢在重排序这一步。知识冲突是另一个大坑。知识库里可能同时存在“2023 年的产品价格”和“2025 年的新品价格”检索出来的文本自相矛盾大模型不知道信谁。这个问题不能指望大模型自己判断它更倾向于把自己训练语料里的信息掺进来。我的做法是给知识库的文档打时间戳和来源标签在检索结果里强制加入 metadata 过滤并且在拼接 prompt 时明确提示模型优先采用带最新时间戳的信息。如果面试官追问“大模型不听话怎么办”可以回答“RAG 的本质不是让模型更聪明而是把答案的信息源限定在你的知识范围内因此信息源的冲突要在检索层就解决掉不能留给生成层做自由发挥”。3.3 Agent 不是玩具AI Agent 怎么扛住真实并发流量聊完 RAG 的单链路谢飞机抛出了第三轮的压轴题AI Agent 在线上怎么扛并发不同于普通接口调用Agent 的每一次请求可能涉及多轮大模型调用、多步工具调用、多次检索整体耗时会成倍放大。朋友当时愣了一下因为这个话题很多人聊能力、聊 prompt但很少在面试里聊架构层面的并发问题。Agent 服务的并发瓶颈和大模型的推理吞吐强相关。如果直接同步调用大模型一个请求里 5 次模型调用耗时就是 5 倍叠加线程被拖死这就是所谓“ai agent 怎么扛并发”的核心痛点。我拆解过这个问题的可行方案至少可以分四层来打第一层是异步化。把 Agent 的执行链路设计成异步任务用前面第一轮聊的线程池去编排避免请求线程长时间阻塞同时用 Future 或回调来聚合结果。第二层是缓存。对用户问题做语义相似度匹配命中缓存知识库的直接返回不用每次重建回答工具调用结果也可以按参数签名做短时缓存。第三层是降级与限流。Agent 服务必须预设大模型调用成本的熔断阈值比如每分钟 token 消耗超过阈值就拒绝非核心用户请求。第四层是推理层优化比如流式输出、批量推理、小模型先行粗筛、大模型只做关键归纳。这里有一个容易被忽略的细节Agent 的工具调用如果涉及 RAG 检索检索的吞吐会成为隐形瓶颈。一个高并发的 Agent 问答服务RAG 检索可能占到整个链路 50% 以上的延迟。所以检索接口要做并发控制不能因为 Agent 的并发请求进来就直接压垮底层向量数据库。我在实际项目里会给检索服务单独配一个线程池设置队列上限和超时时间检索超时直接走兜底话术不让用户无限等待。面试官对 Agent 这块的最后一个问题是你的 RAG 服务上线后怎么评估效果这个问题很多人以为要答准确率、召回率但这只是离线指标。线上评估更关注最终答案的可接受率、人工反馈、检索命中的置信度分布。你可以设计一个简易的反馈闭环用户对回答点踩时把问题和答案落库定期抽检进入知识库扩充流程从而形成数据飞轮。如果能在面试中把离线评测、在线监控、反馈闭环三层都讲完整就已经是一套很成熟的 RAG 落地解法了我相信大多数面试官到这里都会认可。4. 三轮面试复盘大厂到底在考什么、问法背后的逻辑4.1 从问题看意图这根本不是考察“知识点”是考察“连接力”把三轮问题放在一起看你会发现谢飞机的提问逻辑非常清晰每个领域他都先问场景应用再问底层原理最后追问线上权衡。线程池的问题是“你在哪用、怎么配、拒绝策略怎么选”Kafka 是“重复消息根源、幂等机制、消费端幂等”RAG 是“标准链路、切分策略、检索瓶颈、并发架构”。这些问题的共同点是都不考你背诵能力而是在考察你在一个真实系统里能不能把多个知识模块连接起来。所谓的“连接力”就是能不能把线程池的拒绝策略和消息消费的堆积保护连起来能不能把 Kafka 的幂等机制和业务主键的唯一约束连起来能不能把 RAG 的重排序和大模型生成的上下文窗口连起来。大厂面试官真正想知道的是把你招进来线上出问题时你能不能快速定位、能不能做出合理的架构决策。如果你只会单点知识背得再熟也过不了这三轮。4.2 我的复盘对照答法升级的几个关键点复盘时我把朋友的答案和更优的答案做了对照发现差距主要集中在三个方面。第一朋友习惯“定义先行”面试官问线程池参数他先背参数列表再解释含义。更好的答法是“先讲业务场景再给参数设计再讲怎么验证”。比如他说异步任务多我改成“我们的异步任务分两类一类是用户无感知的日志清洗一类是下单后的积分计算两者对延迟和可靠性的要求不同因此拆了两个线程池”。同样聊线程池这种答法听起来更像在做系统设计而不是在背八股。第二朋友不太敢暴露“不知道”。谢飞机问 Kafka 事务的底层交互时朋友说了“我了解得比较浅”其实完全可以用另一个方式接住把懂的部分讲清楚把不懂的部分缩小范围再提出自己的推测。面试官一般不会因为你某个细节不懂就否定你而是会看你在未知领域是否具备推导能力。第三朋友在 RAG 环节几乎没提数据评估和线上监控一直在说“流程”。这其实暴露了实践深度不足。一个真正做过 RAG 项目的人一定会提到评估数据集的构建、bad case 分析、知识更新流程。这些才是决定一个 AI 功能能不能上线、上线后稳不稳定的关键。后面这块我给他补充了一套完整的内容如果你们平时也有做 AI 应用的需求强烈建议把离线评估和线上监控尽早纳入迭代计划不要等用户反馈出来了才被动应对。4.3 从面试延伸出的通用方法论系统性准备大厂技术面总结这次面试我提炼出三个对任何技术岗位都适用的准备方法。第一个方法是“每个技术点至少要能讲出两层”第一层是它解决什么问题第二层是它引入了什么新问题。比如线程池解决了线程复用问题但引入了参数配置不当导致的任务堆积问题Kafka 幂等解决了重复消息问题但引入了 PID 内存占用和乱序检测问题RAG 解决了大模型幻觉问题但引入了知识时效性和检索冲突问题。能把这两层讲清楚就说明你不是停留在表面。第二个方法是“用业务故事串起技术细节”。面试官不关心你背了多少 API关心你有没有真实的系统思考。准备面试时拿出自己最熟悉的三个项目每个项目分别想清楚为什么用这个技术、不用会怎样、线上的参数是怎么调出来的、出了故障怎么排查。这套故事练熟了不管是面线程池还是 Kafka都能把对话主动权拉到自己熟悉的领域。第三个方法是“主动亮出权衡和取舍”。面试官问你喜欢用什么框架时很多人会说“某个框架很好用”这是非常糟糕的回答。更好的思路是“这个框架在这里很好用但我发现它在另一个场景下存在什么问题所以我在那里换了另一种方案”。敢于做取舍、能讲清楚取舍理由的候选人才是大厂真正想找的人。5. 关键技术点速查表面试前两小时翻这一份就够了写到这里我把这三轮面试涉及的关键技术点按领域整理成了一张速查表方便大家临阵磨枪。表格里每一行都提炼了核心考点和最容易翻车的细节你可以根据自己的薄弱项重点补强。技术领域核心考点一句话记忆高频深挖方向Spring Boot 线程池核心参数与执行流程先核心、再队列、再最大、再拒绝无界队列导致 maxPoolSize 失效线程池拒绝策略四种策略适用场景CallerRuns 适合要背压Discard 会丢任务自定义拒绝策略与补偿机制Async 失效AOP 代理机制同类调用不经过代理注解不生效拆分 Bean 或注入 selfKafka 生产者幂等PID Sequence Number分区内有序可达跨分区不行OutOfOrderSequenceException 含义Kafka 事务事务协调器与原子提交事务开启幂等幂等不一定事务未提交消息不可见导致消费延迟消费端幂等业务主键去重靠业务 ID不靠消息 IDSETNX / 唯一键 / 状态机三件套RAG 文档切分分层切分与窗口重叠粗切失语义细切断上下文500-800 字窗口 100-150 重叠向量化与召回混合检索 重排序向量找语义BM25 找精确重排序模型统一打分RAG 知识冲突时间戳与来源过滤检索层解决别留给生成层metadata 过滤 prompt 约束Agent 并发架构异步化 缓存 降级不能同步阻塞请求线程检索接口单独线程池限流RAG 效果评估离线评测 线上监控不仅看准确率看最终答案可接受度反馈闭环驱动知识库迭代这张表不需要死记。我的建议是对照你已经掌握的内容做快速筛查看见哪一行的“深挖方向”自己不熟悉马上去查一下相关源码或者写个 demo 验证效果远好于把整张表从头到尾背一遍。面试前两个小时过一遍这张表再把自己项目的两个真实案例在脑子里跑一遍基本就可以上场了。6. 最后分享一点个人感受把这三轮面试完整复盘下来我最深的感觉是技术面试正在从“考知识点”变成“考手艺”。线程池、Kafka 幂等性、AI Agent 和 RAG这三个话题看上去风马牛不相及但它们背后都指向同一个能力你能不能在一个复杂系统里把一个看似简单的技术动作放到整个链路上权衡利弊。线程池参数不是背出来的是算出来调出来的Kafka 幂等不是配个参数就完事是跟业务主键一起去兜底的RAG 不是把文档切碎了塞进向量库就上线是要一层一层解决切分、检索、冲突、并发和评估问题的。我建议所有准备面试的朋友平时做技术积累时养成一个习惯每学一个技术点都追问一遍“这个技术带来了什么新问题我的线上系统是怎么解决它的”。长期坚持下去你会发现自己讲出来的技术内容天然就带有实战的分量感这比任何面经都管用。希望这次实录的拆解能帮到正在准备面试的你也欢迎你带着自己的复盘结论来交流碰撞一起把这些问题拆得更透。