1. 面试官视角Spring Boot 自动配置到底在考什么大厂 Java 面试里Spring Boot 几乎是必问项但面试官真正想听的不是你能背出SpringBootApplication拆成哪三个注解而是你能不能讲清楚「自动配置」这条链路是怎么跑通的。我见过太多候选人简历上写着「精通 Spring Boot」结果被追问一句「你自己写过 starter 吗」就卡壳了。先说结论Spring Boot 的核心竞争力就是约定优于配置而自动配置是这套约定的发动机。它的本质是框架在启动时扫描 classpath 下所有META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports2.7 之前是spring.factories把符合条件的配置类批量注册进容器。条件从哪来就是那一堆ConditionalOnClass、ConditionalOnMissingBean、ConditionalOnProperty。面试官常追问的三个点你可以这样答第一自动配置的加载顺序。自动配置类通过AutoConfigureBefore、AutoConfigureAfter、AutoConfigureOrder控制相对顺序但用户自己用Bean定义的组件优先级更高因为ConditionalOnMissingBean会先检查容器里有没有。这就是为什么你自定义一个DataSource就能覆盖默认的 HikariCP 配置。第二为什么要有 starter。starter 是一个空 jar只负责把依赖和自动配置类聚合进来。比如spring-boot-starter-web里没有一行业务代码它只是把spring-webmvc、tomcat、jackson拉进来再触发WebMvcAutoConfiguration。面试时如果你能说出「starter 是依赖描述符 自动配置入口」比背注解强得多。第三条件注解的实战意义。举个真实场景你写了一个多数据源 starter希望只有在配置文件里出现multi.datasource.enabledtrue时才生效。这时候ConditionalOnProperty(prefix multi.datasource, name enabled, havingValue true)就是关键。没有它你的 starter 会在所有引入它的项目里强行注入 Bean直接导致启动失败。下面这份自动配置清单是我自己写 starter 时反复用的模板你可以直接复制改// 文件路径src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports com.example.starter.MultiDataSourceAutoConfiguration// 文件路径src/main/java/com/example/starter/MultiDataSourceAutoConfiguration.java package com.example.starter; import org.springframework.boot.autoconfigure.condition.ConditionalOnClass; import org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean; import org.springframework.boot.autoconfigure.condition.ConditionalOnProperty; import org.springframework.boot.context.properties.EnableConfigurationProperties; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import javax.sql.DataSource; Configuration ConditionalOnClass(DataSource.class) EnableConfigurationProperties(MultiDataSourceProperties.class) ConditionalOnProperty(prefix multi.datasource, name enabled, havingValue true) public class MultiDataSourceAutoConfiguration { private final MultiDataSourceProperties properties; public MultiDataSourceAutoConfiguration(MultiDataSourceProperties properties) { this.properties properties; } Bean ConditionalOnMissingBean public MultiDataSourceRouter dataSourceRouter() { MultiDataSourceRouter router new MultiDataSourceRouter(); router.setPrimaryKey(properties.getPrimary()); router.setDataSources(properties.getNodes()); return router; } }# application.yml 中开启 multi: datasource: enabled: true primary: master nodes: master: url: jdbc:mysql://127.0.0.1:3306/demo username: root password: root slave: url: jdbc:mysql://127.0.0.1:3307/demo username: root password: root面试官如果继续问「自动配置和ComponentScan冲突吗」你要能答不冲突但自动配置类不应该被ComponentScan扫到否则条件注解会失效因为扫描是无条件的。正确做法是把自动配置类放在独立的包路径下只通过 imports 文件注册。还有一个高频误区很多人以为ConditionalOnMissingBean能保证「用户没定义才生效」但它在同一个配置类内部的方法之间是有顺序依赖的。如果你在同一个类里定义了两个同类型 Bean第二个方法上的ConditionalOnMissingBean可能因为第一个已经注册而失效。解决办法是把它们拆到不同的自动配置类用AutoConfigureAfter控制顺序。2. Kafka 消费幂等与重试面试官最爱挖的坑Kafka 这块面试官的问题往往从「你怎么保证消息不丢」开始然后一路追问到「重复消费怎么办」「顺序怎么保证」「重试会不会导致乱序」。如果你只答「ack 设为 all、手动提交 offset」基本就停在第一层了。先明确一个事实Kafka 只能保证分区内有序跨分区不保证。而「至少一次」语义下重复消费是必然的。所以幂等不是可选项是必选项。面试时你要主动说出「消费端幂等」这个关键词面试官眼睛会亮。幂等的实现方式按业务场景分三档第一档数据库唯一索引。最土但最可靠。比如订单消息用order_id建唯一索引重复插入直接抛DuplicateKeyException捕获后忽略即可。适合写库场景。第二档Redis 去重表。消息进来先SETNX msgId 1 EX 86400成功才处理失败说明处理过。适合高并发、不想每次查库的场景。注意要设过期时间否则 Redis 会爆。第三档状态机 版本号。适合更新类操作比如「订单状态从待支付改为已支付」用UPDATE orders SET statusPAID WHERE id? AND statusPENDING影响行数为 0 说明已经处理过。下面这份配置片段是我在 Spring Boot 项目里实测可用的幂等消费模板# application.yml spring: kafka: bootstrap-servers: 127.0.0.1:9092 consumer: group-id: order-consumer-group enable-auto-commit: false auto-offset-reset: earliest max-poll-records: 50 key-deserializer: org.apache.kafka.common.serialization.StringDeserializer value-deserializer: org.springframework.kafka.support.serializer.JsonDeserializer properties: spring.json.trusted.packages: com.example.dto isolation.level: read_committed listener: ack-mode: manual_immediate concurrency: 3// 文件路径src/main/java/com/example/consumer/OrderConsumer.java package com.example.consumer; import com.example.dto.OrderMessage; import org.springframework.data.redis.core.StringRedisTemplate; import org.springframework.kafka.annotation.KafkaListener; import org.springframework.kafka.support.Acknowledgment; import org.springframework.stereotype.Component; import java.time.Duration; Component public class OrderConsumer { private final StringRedisTemplate redisTemplate; private final OrderService orderService; public OrderConsumer(StringRedisTemplate redisTemplate, OrderService orderService) { this.redisTemplate redisTemplate; this.orderService orderService; } KafkaListener(topics order_created, groupId order-consumer-group) public void onMessage(OrderMessage message, Acknowledgment ack) { String dedupKey kafka:dedup:order_created: message.getMsgId(); Boolean first redisTemplate.opsForValue() .setIfAbsent(dedupKey, 1, Duration.ofHours(24)); if (Boolean.FALSE.equals(first)) { ack.acknowledge(); return; } try { orderService.handle(message); ack.acknowledge(); } catch (Exception e) { // 不 ack让 Kafka 重投配合死信队列兜底 throw e; } } }重试策略这块面试官会追问「重试几次」「重试间隔」「重试失败怎么办」。标准答案是有限重试 指数退避 死信队列。Spring Kafka 提供了DefaultErrorHandler可以配置重试次数和退避策略// 文件路径src/main/java/com/example/config/KafkaErrorConfig.java package com.example.config; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.kafka.listener.DeadLetterPublishingRecoverer; import org.springframework.kafka.listener.DefaultErrorHandler; import org.springframework.kafka.core.KafkaTemplate; import org.springframework.util.backoff.ExponentialBackOff; Configuration public class KafkaErrorConfig { Bean public DefaultErrorHandler errorHandler(KafkaTemplateString, Object template) { DeadLetterPublishingRecoverer recoverer new DeadLetterPublishingRecoverer(template); ExponentialBackOff backOff new ExponentialBackOff(1000L, 2.0); backOff.setMaxInterval(10000L); backOff.setMaxElapsedTime(30000L); return new DefaultErrorHandler(recoverer, backOff); } }关于乱序你要能说清楚同一 key 的消息会落到同一分区同一分区只会被同一消费组内的一个消费者消费所以只要不跨分区重试顺序就能保证。但如果你用了死信队列再重新投递到原 topic就可能乱序。解决办法是死信消息带上原始 offset消费端按 offset 排序后再处理或者干脆让业务容忍最终一致。还有一个面试官爱问的点enable-auto-commitfalse和ack-modemanual_immediate的区别。前者是关闭自动提交后者是告诉 Spring 什么时候提交。如果你只设了前者没设后者Spring 会在批次处理完后自动提交达不到「处理一条提交一条」的效果。这个细节能答出来说明你真在生产环境踩过。3. RAG 检索链路参数表与本地验证RAG 是这两年面试的新宠但很多候选人只会说「先检索再生成」一追问参数就露馅。面试官想听的是你怎么控制检索质量。检索质量差后面生成再强也是垃圾进垃圾出。先给一张我实际调优时用的参数表你可以直接对照参数含义推荐值调优方向chunk_size文档切分块大小300-500 token太小语义不全太大噪声多chunk_overlap相邻块重叠chunk_size 的 10%-20%防止语义被切断top_k召回条数5-10太大上下文超限太小漏召回score_threshold相似度阈值0.7-0.8cosine低于阈值直接判无结果rerank_top_n重排序后保留数3-5精排后喂给模型temperature生成温度0.1-0.3RAG 场景要低减少幻觉检索链路完整走一遍是这样的用户 query 先做预处理去停用词、纠错、改写然后调用 embedding 模型转成向量去向量库做相似度搜索拿 top_k再用 rerank 模型精排最后把 top_n 个 chunk 拼进 prompt 交给大模型生成。这里有个面试高频追问为什么需要 rerank。因为向量检索用的是双塔模型query 和 doc 分别编码速度快但精度有限。rerank 用的是交叉编码器把 query 和 doc 拼在一起过模型精度高但慢。所以先用向量检索粗筛再用 rerank 精排是精度和性能的平衡。本地验证 RAG 链路我推荐用 Python 快速搭一个最小可跑版本再对照 Java 实现。下面是验证脚本# 文件路径scripts/rag_verify.py import numpy as np from sentence_transformers import SentenceTransformer # 1. 加载本地 embedding 模型首次会下载 model SentenceTransformer(BAAI/bge-small-zh-v1.5) # 2. 模拟文档库 docs [ 猫咪弹钢琴的视频在昨天下午发布作者是宠物博主小王, 用户昨天观看了三条宠物类视频其中两条是猫咪, 钢琴教学视频合集包含入门到进阶的指法练习, 短视频推荐算法会根据用户历史行为做召回, ] # 3. 离线向量化 doc_vectors model.encode(docs, normalize_embeddingsTrue) # 4. 用户查询 query 那天我看过的一个猫咪弹钢琴的视频 query_vector model.encode([query], normalize_embeddingsTrue)[0] # 5. 相似度计算cosine因为已归一化点积即可 scores doc_vectors query_vector ranked np.argsort(-scores) # 6. 阈值过滤 top_k threshold 0.5 top_k 3 results [(docs[i], float(scores[i])) for i in ranked[:top_k] if scores[i] threshold] for text, score in results: print(fscore{score:.4f} | {text})跑出来你会看到第一条「猫咪弹钢琴」得分最高第三条「钢琴教学」得分中等但可能被阈值过滤掉。这就是语义检索和关键词检索的区别关键词检索「猫咪弹钢琴」只能匹配到第一条语义检索能把「宠物类视频」「猫咪」这些语义相近的都召回。在 Java 侧如果你用 Spring AI 接入配置大概是这样# application.yml spring: ai: openai: base-url: https://taotoken.net/api api-key: ${TAOTOKEN_API_KEY} chat: options: model: gpt-4o-mini temperature: 0.2 embedding: options: model: text-embedding-3-small注意base-url这里填的是兼容 OpenAI 协议的地址api-key从环境变量读不要硬编码进代码。模型 ID 要和你实际开通的一致gpt-4o-mini和text-embedding-3-small是两个不同的模型chat 和 embedding 要分别配。减少幻觉这块面试官会追问「除了 prompt 里写『不知道就说不知道』还有什么」。你要答检索侧做阈值过滤生成侧做引用约束监控侧做日志回溯。具体说检索结果低于阈值时直接返回「未找到相关内容」不要让模型硬答生成时要求模型标注答案来自哪个 chunk方便人工核查线上记录每次问答的 query、召回 chunk、生成答案定期抽样评估。4. Agent 工具调用示例与 MCP 标准化Agent 是面试的压轴题也是最容易答飘的。很多人把 Agent 说成「会调工具的 ChatBot」这个理解太浅。面试官想听的是Agent 的决策循环、工具调用的标准化、上下文管理。Agent 和 ChatBot 的本质区别在于ChatBot 是「输入→输出」的单轮映射Agent 是「感知→决策→行动→观察」的循环。用户问「帮我查一下昨天买的订单到哪了」Agent 要先决策「需要调用订单查询工具」拿到订单号后再决策「需要调用物流查询工具」最后综合两个结果生成回答。这个多步决策能力才是 Agent 的核心。工具调用框架的设计关键是统一接口 标准化描述。下面是一个 Java 侧的 Tool 接口示例// 文件路径src/main/java/com/example/agent/tool/Tool.java package com.example.agent.tool; import java.util.Map; public interface Tool { String name(); String description(); MapString, Object parameterSchema(); ToolResult invoke(MapString, Object input); }// 文件路径src/main/java/com/example/agent/tool/OrderQueryTool.java package com.example.agent.tool; import org.springframework.stereotype.Component; import java.util.Map; Component public class OrderQueryTool implements Tool { private final OrderService orderService; public OrderQueryTool(OrderService orderService) { this.orderService orderService; } Override public String name() { return query_order; } Override public String description() { return 根据订单号查询订单状态输入参数 orderId; } Override public MapString, Object parameterSchema() { return Map.of( type, object, properties, Map.of( orderId, Map.of(type, string, description, 订单号) ), required, new String[]{orderId} ); } Override public ToolResult invoke(MapString, Object input) { String orderId (String) input.get(orderId); Order order orderService.getById(orderId); if (order null) { return ToolResult.fail(订单不存在); } return ToolResult.ok(Map.of( orderId, order.getId(), status, order.getStatus(), amount, order.getAmount() )); } }MCP模型上下文协议解决的核心问题是让模型和工具之间的通信有统一标准。在没有 MCP 之前每个模型厂商的 function calling 格式都不一样OpenAI 一套、Anthropic 一套、国内厂商又一套你换个模型就要重写工具适配层。MCP 把这些统一成「工具描述 调用请求 调用结果」三件套模型侧和工具侧解耦。面试时如果被问「MCP 和 function calling 什么关系」你可以答function calling 是模型能力MCP 是协议标准。function calling 解决「模型能不能调工具」MCP 解决「工具怎么描述、怎么被发现、怎么被调用」。两者是互补的不是替代关系。会话内存设计这块面试官会追问「Redis 和向量数据库分别存什么」。标准答案是Redis 存短期记忆最近 N 轮对话向量库存长期记忆用户偏好、历史重要事件。短期记忆要快用 Redis 的 List 或 Stream按 sessionId 存长期记忆要能语义检索把用户历史对话摘要后向量化存进去。Agent 每次决策时既拉最近几轮对话又语义检索相关历史拼成完整上下文。// 文件路径src/main/java/com/example/agent/memory/SessionMemory.java package com.example.agent.memory; import org.springframework.data.redis.core.StringRedisTemplate; import org.springframework.stereotype.Component; import java.time.Duration; import java.util.List; Component public class SessionMemory { private static final String KEY_PREFIX agent:session:; private static final int MAX_TURNS 10; private final StringRedisTemplate redisTemplate; public SessionMemory(StringRedisTemplate redisTemplate) { this.redisTemplate redisTemplate; } public void append(String sessionId, String role, String content) { String key KEY_PREFIX sessionId; redisTemplate.opsForList().rightPush(key, role : content); redisTemplate.opsForList().trim(key, -MAX_TURNS, -1); redisTemplate.expire(key, Duration.ofHours(2)); } public ListString recent(String sessionId) { return redisTemplate.opsForList().range(KEY_PREFIX sessionId, 0, -1); } }这里有个坑trim的-MAX_TURNS到-1是保留最后 10 条如果你写成0到MAX_TURNS-1就是保留最旧的 10 条逻辑完全反了。我见过有人线上把用户最新对话全裁掉只留最早的排查半天才发现是 trim 参数写反。5. 本篇常见报错排查401、proxy failed、choices 为空面试聊得再好真上手跑代码还是会遇到一堆报错。这一节我把接入过程中最常见的四类错误和排查路径列出来你照着对号入座。第一类401 Unauthorized。这个最直接就是 key 不对或没传。排查顺序先确认环境变量有没有生效echo $TAOTOKEN_API_KEY看输出再确认代码里读的是不是这个变量名大小写敏感最后确认 key 有没有多余空格或换行从控制台复制时经常带上。如果用的是 Spring AI检查spring.ai.openai.api-key有没有被其他配置覆盖。还有一种情况是 key 过期或被禁用去控制台重新生成一个。第二类local proxy failed / connection refused。这个报错通常出现在你本地配了代理但代理没启动或者端口不对。排查先curl -v https://taotoken.net/api看能不能通如果 curl 也报错说明网络层有问题如果 curl 通但代码不通检查代码里有没有硬编码 proxy 配置比如System.setProperty(https.proxyHost, ...)。Java 的HttpClient默认会读系统代理如果你之前设过-Dhttps.proxyHost启动参数记得去掉。第三类reading choices 为空 / choices is null。这个报错说明请求发出去了模型也响应了但响应体里没有choices字段。常见原因有三个一是模型 ID 写错了比如把gpt-4o-mini写成gpt-4o-minni服务端返回错误但 HTTP 状态码是 200二是请求体格式不对比如messages字段拼错成message三是流式和非流式混用你按流式解析但请求发的是非流式。排查方法打开 debug 日志把原始响应体打出来看。# application.yml 打开 Spring AI 的 debug 日志 logging: level: org.springframework.ai: DEBUG org.springframework.web.client: DEBUG第四类OAuth / token 过期。如果你用的是需要 OAuth 的模型服务token 有有效期过期后会返回 401 或 403。排查看响应头里的WWW-Authenticate字段会告诉你 token 哪里有问题。解决办法是加自动刷新逻辑或者改用长期有效的 API Key。这里要特别提醒Base URL、Key、Model ID 三件套必须同时正确。我见过太多人只改了 Base URLKey 还是旧的或者 Key 换了但 Model ID 没跟着换。如果你用 Claude Code 或 Cline 这类工具配置项通常长这样{ baseUrl: https://taotoken.net/api, apiKey: sk-xxxxxxxx, model: claude-3-5-sonnet-20241022 }三个字段一个都不能少而且baseUrl结尾不要带/v1具体路径由客户端自己拼。如果你用的是 Codex 的auth.json格式类似注意字段名可能是base_url而不是baseUrl下划线和驼峰要看清。还有一个隐蔽的坑并发请求下的连接池耗尽。报错表现是Connection pool shut down或Timeout waiting for connection。原因是默认连接池太小高并发时请求排队。解决办法是调大连接池# application.yml spring: ai: openai: # 底层用 RestClient可通过 HttpClient 配置连接池或者在代码里自定义RestClient.Builder设置HttpClient的连接超时和最大连接数。这个细节面试时如果主动提出来面试官会觉得你真跑过生产流量。6. 从面试到实战把技术栈串成一条线面试官最后那句「你回去等通知」其实是在判断一件事你能不能把散落的技术点串成完整的业务链路。小Y的问题不是不懂 Spring Boot也不是不懂 Kafka而是每个点都停在「我知道这个名词」的层面没有形成「遇到什么问题、用什么方案、为什么这么选」的闭环。我自己的经验是准备大厂面试时不要按技术栈背要按业务场景串。比如「用户上传短视频」这一个场景就能串起Spring Boot 的 Controller/Service 分层、对象存储的选型、MySQL 事务、Kafka 异步转码、Redis 缓存推荐流、链路追踪。你把这一个场景讲透比背十个知识点管用。具体怎么练我建议你本地搭一个最小可跑的项目把下面这条链路跑通第一步用 Spring Boot 起一个上传接口文件存本地磁盘元数据写 MySQL。第二步接入 Kafka上传成功后发一条消息另起一个消费者打印消息。第三步接入 Redis把视频详情缓存起来设 1 小时过期。第四步接入一个 embedding 模型把视频标题向量化存进本地向量库可以用 Chroma 或 Redis Vector。第五步写一个查询接口用户输入自然语言走「向量化→检索→返回 top_k」链路。这条链路跑通你就同时具备了 Spring Boot、Kafka、Redis、RAG 的实战经验面试时随便面试官从哪个点切入你都能接到业务场景上。关于模型接入如果你本地没有 GPU用 Ollama 跑小模型是个选择但精度和响应速度会打折扣。更省事的做法是用兼容 OpenAI 协议的云端服务把base-url指向https://taotoken.net/apiapi-key从控制台生成模型 ID 按需选。这样你不用折腾本地环境专注在业务逻辑上。需要生成 key 的话去控制台创建就行记得把 key 存进环境变量别提交到 Git。最后留几个自测问题你可以对着镜子答一遍能流畅答出来说明这块过关了Spring Boot 自动配置的加载顺序由什么控制用户自定义 Bean 为什么能覆盖默认配置Kafka 消费幂等有哪三种实现方式分别适合什么场景RAG 里 rerank 的作用是什么为什么不能只用向量检索Agent 的会话内存为什么要分短期和长期分别存在哪MCP 和 function calling 是什么关系这几个问题答顺了面试官再追问细节你也有底气接。技术这东西听懂和讲明白之间差着十遍动手讲明白和做出来之间又差着十遍踩坑。别停在「我知道」往前再走一步。