上个月面了一家做在线交易平台的头部互联网公司一面开始没多久面试官就对着简历问了一个让我措手不及的问题“你说你的服务是从Spring Boot单体架构起步的那项目启动之后Spring容器里到底按什么顺序把这些Bean装配起来的”我顺着自动装配、条件注解一路往下答他几乎在每个答案后面都跟了一句“还有呢”。那场面试从Spring Boot的starter机制一路聊到了Redis分布式锁的源码边界、MySQL间隙锁的死锁场景最后甚至问我“如果给公司客服系统接入大模型能力RAG链路你怎么设计”。一场两小时的Java面试考察范围横跨了Spring Boot到AI技术这种体验放在三年前根本不敢想。我把整场面试的完整记录和复盘整理成这篇实录把每个环节的问题、现场回答、事后修正的思路都拆开讲清楚。适合正在准备大厂Java后端岗位的开发者尤其是那些已经把面经背得滚瓜烂熟、却总担心被追问到底的朋友。这篇不是面经汇总而是一条一条的真实考察链路看完你会明白面试官到底在挖什么以及该往哪个方向准备。1. 面试实录开场一场面试的三个阶段和真实节奏1.1 一面全景项目深挖、知识考察、手写代码的时间分配一面通常是一个半小时左右不同公司会有差异但我面的这家节奏非常标准。面试官先把我的简历从头到尾过了一遍然后直接从简历里挑了两个项目开始深挖这个环节大概占了20到25分钟。他问的不是“你负责什么”而是“你当时为什么这么设计”“上线之后有没有出过问题”“出了问题你第一反应查什么”。这些问题没有标准答案但答得好不好基本决定了他接下来问知识的深度。紧跟着是技术知识考察Spring Boot、JVM、MySQL、Redis、消息队列轮着来持续30到35分钟。这一步最有意思的地方是面试官的提问不是孤立的而是像剥洋葱一样顺着我的回答往里追。我说Redis分布式锁用Redisson实现他马上问“Redisson的看门狗机制你了解吗如果主节点挂了锁会不会丢”。这种追问方式的压力明显比单纯背诵考点大因为只要有一个环节不够扎实整条链路就会断掉。最后是手写代码环节大概20分钟两道题一道算法题一道SQL题。前面聊得多深这一环节反而显得轻松不少但后来我复盘才发现算法题的重点根本不在算法本身而在如何处理边界条件和并发问题。面试环节时长考察重心典型问题示例项目深挖20-25分钟技术选型逻辑、问题排查思路、复盘能力为什么选Redis做缓存而不是本地缓存技术知识考察30-35分钟基础深度、知识链路完整性自动装配为什么能被条件注解控制手写代码20-25分钟数据结构、并发意识、SQL建模手写LRU缓存、开窗函数统计反问环节5分钟候选人关注点、沟通意愿你对我们团队或者业务有什么想了解的1.2 二面与三面系统设计题与AI技术加试通过一面后二面通常隔几天进行考察重心从“知识点”转到“设计能力”。我这场的二面题目是一个典型的业务场景题设计一个秒杀系统的库存扣减方案。这个问题从数据库层的乐观锁、Redis预扣减到MQ异步削峰一路延伸出去非常考验知识面的广度。当时面试官还特意问了一个变体“库存扣减成功了但订单超时未支付你怎么把库存还回去”这种场景题考的不是你会哪个中间件而是你能不能把一个完整的业务链路串起来。三面的节奏又不一样更偏向技术判断力和沟通方式。面试官先让我介绍自己最有成就感的一件事接着聊了一些技术选型的取舍比如“你对微服务拆分粒度怎么理解”“什么时候不应该用微服务”。这些问题看着宏观实际上还是在挖你有没有扎扎实实写代码的经验因为只有真正维护过复杂系统的人才说得出微服务化之后引入的分布式事务成本和排查链路成本。最让我意外的是三面居然出现了AI技术加试。面试官没有问我会不会机器学习而是直接给了一个落地场景“如果要给公司的智能客服升级让它可以基于内部知识库回答用户问题RAG的整体链路你怎么设计。”我当时愣了一下因为准备面试时完全没想过Java岗位会考察这个。这个问题前面聊的技术积累完全派得上用场向量存储、检索召回、流式返回本质上就是一次新的系统设计。1.3 面试官的提问逻辑为什么现在Java面试考察面这么“杂”面完复盘的时候我仔细想了想为什么大厂Java面试的考察范围会变得这么杂。最直接的原因是业务本身变复杂了。现在一个后端接口后面可能同时依赖Redis集群、消息队列、分库分表的数据源还要对接大模型的流式输出。面试官需要确认的不再是“你会不会某个框架”而是“你有没有在真实业务中解决问题的判断力”。另一个原因和候选人之间的区分度有关。线上到处都能找到面经和八股答案单纯背概念已经很难拉开差距所以面试官会把问题设计成一条“追尾链路”——从一个最基础的概念出发不断向底层原理和落地场景延伸。这种考察方式下真正写过代码、排查过线上问题、思考过方案的候选人会自然突显出来。所以准备大厂Java面试本质上不是在准备一道道孤立的题而是在构建一条能经得起连续追问的知识链路。你对每项技术都要能回答三个层次的问题它是什么它解决了什么问题它在什么场景下会失效、以及失效后怎么办。这也是后面几章我逐项拆解时的核心思路。2. Spring Boot连环追问starter机制与自动装配的深水区2.1 面试官的开场自动装配到底在装配什么面试官针对Spring Boot的第一个问题很收敛“你们项目里哪些依赖是starter如果去掉这个starter的依赖项目还能不能启动”我愣了一下随后意识到他想问的是自动装配机制。Spring Boot的starter本质上是一个依赖描述符它把一组相关依赖聚合到一起同时通过SPI机制告诉Spring容器“我这里有自动配置类可以注册”。这里需要展开讲的底层链路是SpringBootApplication上组合了EnableAutoConfiguration注解它通过Import导入一个AutoConfigurationImportSelector这个类会去读取META-INF下自动配置的导入文件。Spring Boot 3.x之后这个文件路径是META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports里面按顺序列出了所有自动配置类。然后Spring Boot会逐一检查这些类上面的条件注解满足条件才实例化。我当时给了一个更直观的回答自动装配可以理解为“送外卖的时候帮你把餐具都配好”starter是下单SPI是配送清单条件注解是“根据你的口味决定到底给哪种餐具”。面试官明显对这类生活化类比比较认可点点头之后立刻追问“那如果两个starter都定义了同一个名字的Bean谁说了算”这个问题再往后就是ConditionalOnMissingBean的语义和Bean定义的覆盖顺序需要你把条件注解的理解落到具体场景里。2.2 循环依赖与启动流程容易被追问的两个“深水区”项目深挖环节结束后面试官忽然转到了循环依赖。“Spring默认的三级缓存解决循环依赖为什么三级就能解决二级不行吗”这个问题如果在平时看文章很容易觉得自己懂了但被当面一问要讲清楚就得把对象的创建过程完整串一遍。我的回答思路是这样的Spring创建Bean时会先实例化原始对象再把原始对象通过ObjectFactory包装后放到第三级缓存singletonFactories中等属性填充时如果发现A依赖B、B又依赖AB就能从第三级缓存拿到A的提前引用完成注入。如果只有二级缓存直接把原始对象放进earlySingletonObjects那么提前暴露出来的对象无法在BeanPostProcessor阶段被AOP代理替换因为代理是在初始化之后才生成的。三级缓存的巧妙之处在于它对“是否需要代理”做了一次延迟判断。面试官听完之后补了一问“那Spring Boot 2.6之后为什么默认禁止循环依赖”答案是Spring官方认为循环依赖往往是设计问题直接拒绝可以让你早一点看到缺陷而不是让一个说不清依赖关系的系统继续跑下去。这个细节如果不清楚很容易当场卡壳。紧接着他又把问题拉回启动流程让我概括SpringApplication.run()的核心步骤标准的回答链是推断Web应用类型、加载配置类和监听器、准备Environment、创建ApplicationContext、执行refresh、启动Web容器。2.3 自定义starter的实战回答能写出来才算真懂面试官在循环依赖之后给了最后一个机会“如果你要为自己的团队封装一个日志脱敏组件你会怎么设计这个starter”这个问题我在准备阶段刚好实践过所以答得比较流畅。一个自定义starter的核心包括三部分自动配置类、配置属性类、META-INF下的自动配置导入文件。配置属性类通过ConfigurationProperties绑定用户提供的配置项自动配置类通过EnableConfigurationProperties引入属性类同时在需要的情况下通过条件注解控制生效范围。我在白板上写了一个非常简化的骨架AutoConfiguration EnableConfigurationProperties(LogMaskProperties.class) ConditionalOnClass(Filter.class) ConditionalOnProperty(prefix log.mask, name enabled, havingValue true, matchIfMissing true) public class LogMaskAutoConfiguration { Bean ConditionalOnMissingBean public LogMaskFilter logMaskFilter(LogMaskProperties properties) { return new LogMaskFilter(properties.getRules()); } }关键点在于最后一个条件注解如果使用方的项目里已经自己定义了一个LogMaskFilter自动配置应该自动后退把控制权交还给使用者。这段代码写完面试官就直接跳到了下一个问题我后来复盘时觉得这一关能顺利通过靠的不是背结论而是真的自己动手写过一遍。如果你也想准备这个问题我建议花一个下午做一个自己的starter那种把配置文件加载改成代码实现的过程比读十篇源码分析都管用。3. 分布式与中间件考点面试官真正想听的是选型理由3.1 Redis追问从缓存穿透到分布式锁的源码边界Redis是Java面试绕不开的一环这场的考察方式也很有代表性。面试官先给了个高频场景“一个热点商品的详情页缓存失效的瞬间有大量请求打到数据库你怎么处理”标准的回答是缓存击穿的处理互斥锁重建缓存加上逻辑过期兜底。这类方案大家都会背但面试官随即问了一句更实际的“互斥锁是单机的而你服务是多实例部署的这个锁还有用吗”这就自然过渡到了分布式锁。我的回答先提了SETNX配合EXPIRE的经典写法然后马上指出了它的两个坑非原子操作以及锁超时后业务还没执行完会导致误删他人的锁。更好的做法是使用Redisson的RLock或者自己用Lua脚本保证原子性。面试官追问Redisson的看门狗机制我讲了默认30秒租约和自动续期的行为但也坦诚提到主从切换场景下锁可能会丢如果需要强一致得靠RedLock甚至更重的组件来保障。最后面试官抛了一个选型问题“你们这个场景为什么用Redis做分布式锁而不是数据库唯一索引或者ZooKeeper临时节点”我想了想给出了权衡Redis性能高、可用性强适合高吞吐但可接受极小概率锁丢失的场景ZooKeeper一致性更强适合对安全性要求极高的低频操作。面试官点头我知道这个问题答对了。这个环节给我的启发是中间件面试的最后一问永远落在选型上你需要把每个候选方案的代价说清楚。3.2 MySQL考察索引失效与MVCC的实际场景到了MySQL部分面试官没有直接问索引结构而是给出了一个慢SQL“select * from order_info where user_id 20241001 and status 1 order by create_time desc limit 10”让我分析为什么慢、怎么优化。我给出的思路是先看执行计划确认有没有走索引接着考虑建立联合索引(user_id, status, create_time)这样索引覆盖了等值条件和排序字段避免filesort。但如果status的区分度不高把status放进索引里可能意义不大。然后他问了一个我很喜欢的题“一个where条件里写了age 1 30为什么索引会失效”答案是对索引列使用函数或表达式会使优化器放弃走索引因为B树上的有序性被破坏了。这个问题接下来自然延伸到MVCC“RR隔离级别下普通的select和加锁的select在MVCC上的可见性有什么不同”我顺着undo log版本链、ReadView的生成时机讲了一遍最后补充了当前读和快照读的区别。面试官突然又问“你在线上遇到过死锁吗记录一下死锁日志里的Lock wait table exceeded信息。”我讲了一个典型的间隙锁死锁场景事务A先按范围条件锁住了一批不存在的记录事务B想插入其中一条时被间隙锁挡住事务A又去插入另一条于是互相等待。说到这我能感觉到面试官在确认一件事这个人是不是真的遇到过线上事故还是只看了几篇文章。所以我不敢编造太多细节就诚实讲了自己调过的一个死锁案例的日志排查过程。3.3 消息队列“三丢失”与一致性的完整解法聊完MySQL后问题自然过渡到了消息队列。面试官问了一连串关于消息可靠性的问题生产端发送成功之后Broker到底怎么保证不丢消息消费者处理完业务之后才提交offset才是标准的消费语义这里要注意重复消费问题要靠幂等设计来解决。我把三个环节的丢失场景和对应方案列在了一起方便记忆环节消息丢失原因常用方案生产端发送时网络异常、Broker未确认开启生产端确认机制失败重试Broker宕机后内存消息未持久化刷盘策略调整为flush到磁盘配合多副本消费端业务未处理完就提交offset手动ack处理成功后提交面试官又问“如果确保消息不丢消费速度跟不上消息积压怎么处理”我给出的是水平扩容消费者实例、临时关闭重试、以及离线重建索引的常规方案。不过他接下来的一句话让我印象深刻“你前面说的这些方案有没有考虑过order语义”于是我又补充了顺序消息的使用场景比如一个订单的创建、支付、完成必须按顺序处理并不是所有消息都适合并行消费。这个环节让我体会到中间件知识能答到什么程度往往取决于有没有真实处理过业务链路里的异常情况而不是会背多少个名词。4. AI技术新考点从大模型认知到RAG场景设计4.1 为什么Java面试开始穿插AI技术问题三面面试官问出“你怎么设计一个基于大模型的智能客服系统”时我承认第一反应是紧张。但很快我想明白了这个问题并不是要我懂训练模型而是要考察我作为后端工程师能不能把大模型能力当成一个外部服务对接进现有系统。今天的Java后端系统已经越来越多地承接这类需求智能客服、内容摘要、代码助手、知识库问答都需要有人做网关、做上下文管理、做检索优化而这些正是后端工程师的活。所以Java面试里出现AI相关问题本质上不是因为面试官想卷八股而是业务需求已经变了。对候选人来说把“AI技术”当成一种需要对接的高可用外部服务来理解很多问题就能回到你已经熟悉的领域。你需要关注的不是模型内部怎么实现注意力机制而是API怎么调、Token成本和延迟怎么控制、流式输出怎么接、私有数据怎么让模型“知道”。这其实是个好消息。因为这意味着AI题的答案是可以准备的它和系统设计题的备考方式完全一样理解一条完整的调用链路然后把每个环节的可用方案和权衡讲清楚。4.2 RAG场景题的完整回答框架以智能客服系统为例三面的RAG场景题面试官给了足够的时间让我展开我大概按这个顺序回答了他。第一步是文档处理。企业内部知识库里的文档格式五花八门PDF、Word、HTML需要先做解析清洗再按语义相关性做分块。分块大小直接影响检索效果太小了语义不完整太大了向量相似度会被噪声稀释我提到自己实践中的经验是固定字符分块加滑动窗口重叠同时保留段落标题作为补充信息。第二步是向量化与存储。把每个文本块通过Embedding模型转成向量存入向量数据库同时保留原始文本和元数据用于回显和溯源。面试官插问“为什么不用SQL的like查询”我解释说部分场景甚至可以用倒排索引做关键词召回但语义检索能解决“用户换了说法但意思一样”的问题。第三步是关键检索之后不能直接把TopK结果丢给大模型最好加一个重排环节把相关性最高的片段排在前面同时考虑结果里去重。最后是Prompt和流式输出。把用户问题、检索到的片段、回答要求拼装成结构化提示词模型流式返回答案后端通过SSE转发给前端。面试官追问“如果用户问的问题在知识库里根本没有答案怎么办”我的回答是设置兜底策略模型检测到检索结果相关性低于阈值时直接回答“该问题超出我目前的知识范围”而不是强行编造。最后他评价说这道题答得完整我心里才算踏实下来。4.3 Java技术栈接入AI的落地方式从SSE流式输出到Spring AI面试结束后我复盘时发现这道RAG题能答好很大一部分功劳来自我平时真的用Java跑通过一条AI调用链路。如果你也想在面试前快速把这块准备起来我建议这么做先去了解流式输出的实现方式。Java后端给前端推大模型回复最直接的方案是SSESpring MVC的SseEmitter就能实现前端用一个EventSource对象就能接收。然后是AI框架的选型。现在Spring官方已经有Spring AI这样的项目它做的事情和当年Spring Boot对JDBC做的事情很像把对大模型厂商的调用封装成统一接口屏蔽不同厂商API的差异同时提供Prompt模板、向量存储抽象、以及RAG相关的组件。面试官问到的很多概念比如“提示词模板”“Token窗口”“向量检索”在Spring AI里都能找到对应的抽象。不过我的建议是准备面试时先把几个核心概念吃透再去看框架。把一次经过抽象的大模型调用拆成输入、输出、上下文、检索四部分然后思考“这些部分在Java里分别对应什么接口和类”这个思路比背框架文档要管用得多。大模型本身迭代很快但RAG的链路结构已经相当稳定理解链路本身你就能应对各种变体提问。5. 算法与手写代码两道让我印象深刻的上机题5.1 手写LRU缓存并发版本与边界条件算法题环节第一道题是“实现一个基于LRU策略的缓存要求get和put都是O(1)复杂度”。这是一个非常经典的题面试前我练习过好几遍但真正在白板编辑器里写起来还是有很多细节需要小心。我先讲了整体设计一个HashMap负责O(1)查找一个双向链表负责维护访问顺序每次访问节点就把它移到链表头部容量满了就淘汰链表尾部的节点。面试官没让我直接开写而是先问“用Java自带的LinkedHashMap能实现吗”我承认可以并且简单说了通过重写removeEldestEntry方法控制淘汰逻辑但我随后补了一句“如果项目中需要更精细地控制并发行为我会选择自己实现一个双向链表”。这个回答帮我争取到了写完整代码的机会。我花了大概15分钟写完了基础版本但面试官追问“这个缓存能在多线程环境下安全使用吗”于是我又补了ConcurrentHashMap、并在关键路径上加锁的方案也简单提了通过分段锁和读写锁优化竞争的分支思路。核心代码片段大概是这样的public class LRUCacheK, V { static class NodeK, V { K key; V value; NodeK, V prev; NodeK, V next; } private final int capacity; private final MapK, NodeK, V map new ConcurrentHashMap(); private final NodeK, V head new Node(); private final NodeK, V tail new Node(); public LRUCache(int capacity) { this.capacity capacity; head.next tail; tail.prev head; } public V get(K key) { NodeK, V node map.get(key); if (node null) { return null; } moveToHead(node); return node.value; } }这个节选看起来简单但有几个边界条件很容易错空缓存取元素、容量为0、以及同一个key反复put时先删旧节点再插新节点。写完之后我额外做了几个测试用例面试官点头表示认可。整个过程让我意识到算法题环节不只是在考解题能力也在看你的工程意识即写完代码有没有自然想到并发、边界和复用问题。5.2 手写Spring IOC容器精简版框架原理的落地考察第二道手写题更加意外面试官让我“写一个最简化的Spring IOC容器功能包括包扫描、Bean创建和Autowired注入”。看到题目的瞬间我先是紧张但转念一想这正是准备Spring Boot原理时应该掌握的能力。我的实现思路是先定义一个扫描器加载包下所有标注了自定义Component注解的类然后用反射推断构造器并实例化对象最后遍历对象字段给标注了Autowired的字段注入对应实例。我在白板上写了一个大约三十行的demo核心部分是在字段注入循环里进行类型匹配查找。面试官在最后问了个问题“如果两个实现类同时实现了同一个接口你注入的时候按类型找会不会冲突”我回答会这也是Spring中为什么有Primary和Qualifier的原因。我补充说真实框架还会先按类型找再按名字找冲突时报NoUniqueBeanDefinitionException。这一步实际上把框架设计里“怎么从按照类型注入过渡到按照名称注入”的演进过程讲清楚了。这道题对面试准备很有启发如果你只看Spring原理的文章而不动手写是没办法在三五分钟内理出这个逻辑的。哪怕只是把包扫描、反射、类型匹配这几个步骤跑通一次你对面试官后续追问“为什么字段注入不被推荐”“构造器注入和字段注入的区别”都会有了真实的理解基础。5.3 算法题环节的沟通技巧先聊思路再动手两道算法题之后我最大的感悟是沟通比闷头写代码重要得多。面试官给出的题目往往描述不完整比如LRU那道题就没说要不要支持并发。这种情况下先确认需求和边界条件再给出方案本身就是一种工程能力的体现。我开始写代码之前先问清楚了三个问题容量为0时怎么处理、key是否存在时get返回值语义、以及是否要求线程安全。三道题里这些细节都决定了解法的复杂度。我的建议是形成一套固定的算法题答法先复述题目确认理解然后说“我先说我的思路”用两三句话把数据结构、时间复杂度和关键边界点讲出来再动手写。写完代码之后不要马上说“写完了”而是主动走一个简单用例来验证逻辑。这些习惯在面试官眼里是很加分的行为因为它们还原了真实开发中“先设计、再编码、后自测”的工作方式。6. 复盘与补救答错之后如何扭转局面6.1 两个真实的翻车案例与事后分析再顺利的面试也会有翻车点我这场也不例外。第一个翻车出现在JVM部分面试官问“ThreadLocal为什么会有内存泄漏风险”我回答到一半忽然卡住了。我记得ThreadLocalMap的key是弱引用、value是强引用也知道ThreadLocal被回收后value会残留但当时没能把“为什么ThreadLocalMap的key要设计成弱引用”这个问题讲透。我停下来承认自己这里理解得不够完整并尝试从“如果key是强引用会怎样”的方向推理面试官没有打断。事后我想清楚了完整逻辑key设计成弱引用是为了减少ThreadLocal本身无法被GC回收的问题但弱引用也带来key被回收后value还在Map里的残留风险所以ThreadLocal的最佳实践是finally块里调用remove。第二个翻车是缓存一致性方案我脱口而出“延迟双删”面试官直接追问“延迟双删的第二次删除如果失败了怎么办”我当时确实没有很好的即时方案只能承认这里存在缺陷并补充说工业界有基于监听数据库binlog异步删除缓存的更可靠路径。这两个翻车案例都有一个共性我不是完全不会而是知识链路在某个节点断了。面试官并没有因为答错就直接否定反而继续往下给了补救机会这让我后面聊到补偿策略时心态稳住了很多。6.2 答错之后的三种补救策略讲完翻车经历我想把这几次挽救总结成可复用的策略。第一种是“诚实承认加边界重建”。被问到不会的问题时第一时间不要硬编答案而是说“这块我没有深入实践过”然后把问题拆成“我理解的部分”和“我不确定的部分”把面试官引导到你熟悉的知识链路上。我在ThreadLocal那道题上就是这么做的先讲到WeakReference和引用队列再走回合理推论面试官至少能看到你的分析能力。第二种是回到问题本质给一个不同视角的方案。比如被问“延迟双删失败怎么办”我当时补了一句“所以这个方案并不可靠可靠的做法是让删除动作变成一个幂等任务通过重试机制确保最终执行”这让面试官知道我不是只会背方案而是能判断方案的边界。第三种是主动延伸。回答完一个问题后可以主动说“这个问题让我联想到另一个相关设计”把对话带到你有把握的区域。这个策略需要谨慎使用如果延伸内容与问题无关反而会让人觉得你抓不住重点。6.3 面试官真正在看什么基础、思维与沟通整个面试流程走完我最大的收获是重新理解了面试官的角色。他们不是在找一个“什么都会的活体百科”而是在找一个遇到复杂问题能拆解、遇到未知领域能快速建立思路的人。技术基础当然重要但更重要的是基础知识能否被调用来解决新问题。RAG场景题被问到的时候我之前并没有在项目中完整落地过这个系统但因为我理解向量检索、理解API调用、理解流式传输所以能在十分钟内组织出一版可讨论的方案。沟通方式同样关键。回答问题时有清晰的结构比如“这个方案有三步第一步做什么、第二步做什么、为什么最后这样做”比一口气把记忆里的内容倒出来要好得多。面试中有些问题确实答错了但只要你能展示出“修正错误、吸收信息”的能力面试官通常不会揪住一个点不放。这个行业变化太快今天在考察Spring Boot明年可能就在考察AI框架最重要的能力永远是持续学习的态度。我面完之后坐在那里想了很久最大的感触是面试官其实也不是什么都懂但他们一定知道什么样的人能一起合作解决未知问题。Java面试从Spring Boot问到AI技术不是故意刁难而是这个行业已经走到了需要每个后端工程师都有技术敏感度的阶段。如果你正在准备这类面试我的建议很直接不要只看面经去把简历上的每一个技术点重新问一遍“为什么”去写一个自己的starter去调一次大模型的API把一个简单的RAG链路跑通。这些动作做下来比背十份面试题都管用。