1. 从"B卷"这两个字说起：大厂校招笔试到底在筛什么人
每年八九月份，校招季一开，牛客网、知乎、各大技术社区就会被"XX厂笔试挂了""XX厂B卷第二题怎么做"这类帖子刷屏。唯品会2018校招这套B卷，虽然已经过去几年，但直到现在还被很多人翻出来当复习材料，原因很简单：它太"典型"了。五个岗位方向——前端、Java、运维、测试、数据库——几乎是当时互联网大厂校招笔试的标准配置，而卷子里考的那些知识点，放到今天依然是面试八股文的核心素材。
我之所以想专门聊聊这套卷子，不是因为它有多难，而是因为它非常能说明一件事：校招笔试考的不是你会不会写业务代码，而是你有没有吃透计算机基础功底的潜力。作为过来人，我见过太多基础不错的同学倒在校招笔试上，不是不会做，而是根本不了解这套筛选机制背后的逻辑，复习方向完全跑偏。
那这套B卷到底在筛什么人？我把它拆成三个层面来看。
1.1 为什么校招笔试要分A卷B卷
很多同学第一次参加校招笔试，看到"B卷"两个字会愣一下，甚至怀疑自己是不是拿错了。其实分卷是大厂校招的常规操作，主要目的有两个。
第一个是防作弊。同一个时间段开考的候选人，如果所有人都用同一套题，前面考完的人把答案往外一传，后面开考的人直接躺赢。A/B卷甚至C/D卷的题目顺序、选项顺序、个别数值都会打乱，让"传答案"这件事的性价比降到极低。所以你在笔试平台上看到的"B卷"，很可能和隔壁同学拿到的"A卷"题目范围完全一样，但具体题目细节不同。
第二个目的是难度均衡。不同批次的笔试时间可能隔了好几天，如果后一批的题更难或更简单，对候选人来说就不公平。分卷之后可以通过等值处理，让不同卷子的难度系数保持在一个可比的范围内。这一点很多人不知道，但对你做题策略有直接影响：遇到不会的题不用慌，因为别人拿到的卷子大概率也不会简单到哪去，比的是相对排名，不是绝对分数。
1.2 笔试的打分逻辑：不是"做得越多分越高"这么简单
说到打分，很多人的理解是"笔试就是100分满分，60分及格"。大厂校招笔试的评判逻辑远比这个复杂，尤其是像唯品会这种覆盖多岗位的大厂。
通常来说，一套笔试试卷里会混合三种题型：单选题、多选题、编程题或简答题。每种题型的权重完全不一样。单选题一般是最基础的送分题，考察概念记忆；多选题稍微有点区分度，错选漏选都不得分；编程题和场景简答题才是真正拉开差距的地方。
更关键的是，系统不是只给一个总分，而是按岗位维度分别统计。前端岗看前端部分的得分权重更高，Java岗看Java部分，运维岗看Linux和网络部分。所以哪怕你在前端部分得了满分，Java部分一塌糊涂，如果你投的是前端岗，依然有可能进面试。反过来，如果你投的是Java岗，前端部分的得分权重就很低，不必为了那几道题焦虑到睡不着。
还有一个隐藏规则：笔试成绩通常只是参考线，不是唯一标准。大厂HR会结合你的简历、学校、实习经历、项目经历做综合判断。笔试分数达到一个基准线之后，更重要的其实是简历里有没有亮点。这也是为什么同样一套卷子，有人压线过了，有人拿了高分却连面试通知都没等到。
1.3 从热搜词反推考点：校招笔试的考点一直在悄悄进化
我顺手看了一眼2026年前后的一些热搜词，发现一个很有意思的现象：前端面试题、java八股文、linux常用命令大全、数据库增删改查、appium测试、内存测试、数据库同步工具……这些词恰恰就是当年那套B卷里反复出现的核心知识点。
这说明什么？说明校招笔试的核心考点多年来并没有发生颠覆性的变化。Java还是考集合、JVM、并发；前端还是考JS基础、浏览器原理、框架思想；运维还是考Linux、网络、脚本；测试还是考用例设计、自动化、缺陷管理；数据库还是考SQL、索引、事务。变的是具体的出题形式，比如以前考"手写一个防抖函数"，现在可能改成"实现一个带取消功能的防抖"；以前考HashMap源码，现在可能追问"为什么JDK 1.8要把红黑树引入HashMap"。
但底层的东西就那些。这就是为什么即使这套卷子来自2018年，它依然是很好的复习蓝本——因为它帮你划定了校招笔试的"知识边界"。
2. 前端题：事件循环、原型链、手写代码，这些高频考点背后是同一件事
前端方向在这套B卷里占据的篇幅不小，尤其适合正在准备前端面试的同学拿来练手。我每年都会让团队里的校招生做一遍类似的题，从他们的正确率来看，前端笔试的丢分点高度集中，基本绕不开下面这几个方向。
2.1 基础题里的"陷阱题"：类型转换、作用域、this指向
校招前端笔试题里最阴险的不是算法题，而是那些看似简单的基础题。出题人特别喜欢在选择题里埋一些"JS的语言特性陷阱"，你要是没踩过坑，大概率会选错。
比如最经典的==和===的区别，几乎每套卷子都有。null == undefined返回true，但null === undefined返回false；0 == '0'返回true，但0 === '0'返回false。很多人知道这个区别，但题目稍微变一下，比如[] == ![]，不少人就懵了。实际上![]是false，[]转成number是0，false转成number也是0，所以结果是true。这种题考的不是记忆力，是你有没有真正理解JS的隐式类型转换规则。
然后是作用域和var/let/const的区别，几乎必考。经典的for (var i = 0; i < 5; i++)配合setTimeout输出的结果是什么，就是考察块级作用域理解。let解决了这个问题，但如果你不理解背后的词法环境机制，换个写法照样错。
还有this指向问题，闭包里的this、箭头函数的this、普通函数的this，出题人能把这三个概念玩出花来。核心规律就一条：普通函数的this取决于调用方式，箭头函数的this取决于定义位置。但很多同学在笔试现场一紧张，就把这条铁律忘了。
2.2 事件循环与异步编程：从输出题到手写Promise
前端笔试题里区分度最高的，其实是事件循环的输出顺序题。给你一段包含setTimeout、Promise、async/await、微任务、宏任务的代码，让你写出输出顺序。这类题的正确率往往低得吓人，因为它考察的不只是记忆，而是对整个事件循环机制的理解深度。
我记得有一次模拟面试，我让一个候选人解释这段代码：
async function test() { console.log(1); await Promise.resolve(); console.log(2); } test(); console.log(3);他毫不犹豫地说输出是1、2、3。实际上正确的输出是1、3、2。await后面的代码会被放到微任务队列里，而主线程上的同步代码会先执行完。这个知识点虽然基础，但理解不透彻的人做这类题一定会翻车。
除了事件循环，手写Promise相关API也是高频题。最常考的是Promise.all、Promise.race的手写实现，以及基于Promise实现一个带并发限制的异步调度器。这类题考的是你有没有真正理解Promise的运作机制，而不是只会用。
2.3 框架题考的不是框架，是设计思想
唯品会这套B卷出题时，前端的主流框架还是Vue 2.x和React 15/16。现在再看可能觉得有点过时，但框架题背后考的东西完全不过时——数据响应式原理、组件通信、虚拟DOM diff、生命周期。
我特别想提醒一点：校招笔试里考框架题，很少会问"Vue的指令有哪些"这种API记忆题，而是会问"Vue中computed和watch的区别""React中key的作用是什么""虚拟DOM的优势是什么"。这类题目表面上考框架，实际上是在考你有没有理解设计思想。如果你只停留在"会用"的层面，很难答好这些题。
以"key的作用"为例，大多数人能答出"key用于标识节点，优化diff性能"，但答不出"key在列表更新时决定了节点是复用还是重建，错误的key会导致状态错乱"。后者才是在真实业务中真正会遇到的问题，也是面试官想听到的深度。
2.4 前端笔试的编程题：手写防抖节流、深拷贝、数组去重
编程题部分，校招前端笔试的出题套路非常固定。手写防抖函数、手写节流函数、手写深拷贝、手写数组去重、手写call/apply/bind，这几个题几乎是排列组合轮流出。
这些题难吗？不难。但为什么每年都有大量同学在编程题上丢分？我总结下来有三点原因。
第一，** API记得不牢。** 深拷贝要处理Date、RegExp、Map、Set、循环引用，如果平时没专门整理过，考场上很难写得完整。第二，边界条件考虑不全。防抖函数大家都能写个大概，但第一次触发立即执行、取消、带参数的版本，很多同学写不出来。第三，手写代码的规范性不够。笔试平台的代码编辑器没有IDE提示，很多同学平时太依赖自动补全，一写手写代码就漏洞百出。
我的建议是，这些高频手写题一定要整理成自己的"武器库"，提前默写熟练。不是为了押题，而是通过默写加深对JS语言特性的理解。比如手写bind的时候，你自然就理解了this绑定、柯里化、new优先级这几个概念之间的关联。
3. Java题：集合源码、JVM内存、并发三件套，笔试真正想看见的底层功底
Java方向在校招笔试里永远是报考人数最多、竞争最激烈的岗位之一。唯品会这套B卷里的Java题，和绝大多数大厂一样，牢牢锁定在集合、JVM、并发这三个领域。
3.1 集合源码题：HashMap为什么是必考中的必考
如果有人统计大厂Java笔试的高频考点，HashMap大概率能排进前三。从JDK 7到JDK 8，从数组加链表到数组加链表加红黑树，HashMap这个类的演变史，几乎就是Java集合框架面试题的一个缩影。
笔试里考HashMap，一般从这几个角度切入：
- HashMap的底层数据结构是什么？为什么在JDK 8中引入红黑树？
- put操作的完整流程是怎样的？hash函数是如何设计的？
- 扩容机制是什么？为什么负载因子默认是0.75？
- HashMap为什么是线程不安全的？并发put会发生什么？
这些问题看起来是八股文，但每一个背后都有可以深挖的原理。比如负载因子为什么是0.75，这不是拍脑袋定的，而是空间利用率和时间开销之间的权衡结果。0.75意味着当HashMap的容量达到75%时触发扩容，这个比例经过大量测试验证，在大多数场景下性能表现最优。类似的，"为什么树化的阈值是8"，也不是随便定的，而是基于泊松分布计算的——在理想随机哈希下，链表长度达到8的概率极低，所以树化是为了极端情况兜底，而不是常态。
还有ArrayList和LinkedList的对比，也是选择题常客。很多人能答出"ArrayList基于数组，LinkedList基于双向链表；ArrayList查询快增删慢，LinkedList增删快查询慢"。但如果题目换一种问法，问"在头部插入元素，哪个性能更好"，就会有不少人答错——ArrayList在头部插入需要移动所有元素，LinkedList只需要改指针，所以即使ArrayList有内存局部性优势，头部插入场景下LinkedList通常更优。
3.2 JVM内存与类加载：笔试里的"输出题"怎么出
JVM方向在校招笔试里，最常见的考法是给你一段Java代码，让你写出运行结果或者判断是否会报错。这类题表面考代码，实际上考的是你对JVM内存区域、类加载机制、static代码块执行顺序的理解。
经典题目是父子类静态代码块、实例代码块、构造方法的执行顺序。正确答案是：父类静态代码块 -> 子类静态代码块 -> 父类实例代码块 -> 父类构造方法 -> 子类实例代码块 -> 子类构造方法。这个顺序看起来很死板，但如果你不理解背后的类初始化机制和实例初始化机制，换个场景就容易错。
还有一种高频题是String相关。String a = "abc"; String b = new String("abc"); a == b的结果是什么？这类题考的是字符串常量池的概念。==比较的是引用地址，"abc"在常量池里，new String("abc")在堆内存里，二者地址不同，所以结果是false。但如果你用Intern()方法，结果就会改变。类似的还有Integer缓存，Integer a = 127; Integer b = 127; a == b是true，但Integer a = 128; Integer b = 128; a == b是false。这类题目考的是基础，但也是很多人容易忽略的细节。
JVM内存区域划分、可达性分析、强引用弱引用软引用虚引用的区别，也是选择题和简答题的常客。复习的时候建议画一张完整的内存区域图，把堆、虚拟机栈、本地方法栈、方法区、程序计数器分别存什么、会抛什么异常都写在上面，比单纯背概念要管用得多。
3.3 并发编程：三大特性与线程池参数的含义
并发是校招Java笔试里最让人头疼的部分之一，因为它抽象、难懂、靠死记硬背根本记不住。
笔试里最常见的并发考点是synchronized和ReentrantLock的区别、volatile关键字的作用、线程池的核心参数含义。这些题的核心在于三条性质：原子性、可见性、有序性。volatile保证可见性和有序性，但不保证原子性；synchronized三种性质都能保证，但它让线程阻塞，性能不如volatile轻量。
线程池参数那题，几乎年年考。corePoolSize、maximumPoolSize、keepAliveTime、workQueue、threadFactory、RejectedExecutionHandler，这六个参数的含义必须滚瓜烂熟。更重要的是，你得知道一个任务提交到线程池后，执行的完整流程是什么——先判断核心线程是否已满，再判断队列是否已满，再判断最大线程数是否已满，最后走拒绝策略。面试官很可能会站在这个流程上继续追问：这四种拒绝策略分别是什么？在实际业务中你会选哪种？为什么？
还有一个我从笔试题目中总结出来的规律：大厂Java笔试题越来越喜欢"一题多考"。比如给你一段多线程代码，让你找出问题并修复，表面考并发，实际上还暗含了对单例模式、指令重排、DCL（双重检查锁）的理解。这类题一旦出现，往往会成为整张卷子区分度最高的题。
3.4 Java面试八股文：背还是不背
说到Java准备，绕不开"八股文"这三个字。我在面试别人的时候，最怕遇到的就是那种"背得滚瓜烂熟，但一问细节就支支吾吾"的候选人。
对于校招笔试阶段，我的态度是：八股文可以背，但不能只背。笔试考的是概念和结论，背下来确实能帮你拿到不少分。但如果你只会背结论，不理解结论背后的推导过程，一旦遇到变形题、场景题就会翻车。比如你背了"HashMap线程不安全"，但题目改成"在并发put时发生了什么，为什么会出现死循环"，如果你不理解扩容时链表反转的过程，一样做不对。
所以正确的姿势是：先背一轮"结论性八股"，拿到笔试的基础分数；然后针对每个结论，追一层"为什么"，让自己能应对追问；最后结合源码、画图、手写示例，把知识真正内化。这个过程比较耗时，但对后续的面试环节帮助极大。
4. 运维与测试题：不写业务代码的笔试题，反而最能暴露工程素养
前端和Java方向的题目量大、知识点密集，很多同学会投入大量精力准备。但运维岗和测试岗的笔试题目，往往被低估了。实际上，这两类岗位的笔试题最能暴露一个人的工程素养——因为运维和测试本质上不是"写代码"的岗位，而是"保证系统稳定可靠"的岗位。笔试里考的不是你会写多少代码，而是你有没有一套系统性的排查思路。
4.1 运维方向的考点：Linux命令、网络排查、Shell脚本
运维方向在互联网大厂的校招笔试里，一般三大块：Linux基础、网络基础、脚本能力。
Linux部分，高频考点集中在常用命令的使用和含义上。top看系统负载、free看内存、df看磁盘、ps看进程、grep和awk做文本处理、find和xargs做文件搜索。这些命令看似简单，但题目一旦考到组合用法，比如"找出进程PID为1234的所有子进程并杀掉"，不少同学就会卡壳，因为平时根本没系统练过管道和命令组合。
网络部分，最常见的考点是网络排查思路。给你一个场景：用户反馈网站访问不了，你该怎么排查？正确的思路是分层排查——先从物理层和数据链路层看网络通不通，再ping一下网关看局域网通不通，接着用telnet或nc测目标端口通不通，然后再用curl测试HTTP接口是否正常，最后看应用日志定位问题。整套思路的核心是"从底层到高层、逐层排除"，而不是一上来就猜。
Shell脚本部分，笔试通常会让你写一个简单脚本，比如批量重命名文件、统计日志里某个关键字的出现次数、定时清理过期日志等。这类题难度不大，但非常考察基本功，比如变量赋值、for循环、awk列提取、crontab定时任务。我见过不少同学C语言写得不错，但Shell脚本一塌糊涂，原因很简单——平时没练过。
4.2 测试方向的考点：用例设计、缺陷管理、自动化测试
测试方向的笔试，核心考点是测试用例设计方法和测试理论，偶尔会穿插一些基础编程题和自动化测试相关的概念题。
测试用例设计方法中，"等价类划分""边界值分析""因果图法""场景法"这四个是最常考的。而最经典的笔试题目，莫过于给你一个输入框，让你设计测试用例。比如"一个只能输入6到18位字母或数字的用户名字段，请设计测试用例"。这道题很多人只写了正常的输入，完全忽略了边界值：5位、6位、18位、19位；也忽略了特殊字符、纯数字、中文输入、空值、超长字符串、SQL注入脚本等。好的测试用例设计能力，不是罗列内容，而是覆盖合法输入、非法输入、边界输入、异常场景、安全场景这几个维度。
缺陷管理相关的考点也很常见。缺陷的生命周期（New -> Open -> Fixed -> Verify -> Closed走完全流程，中间的Rejected和Reopen也要知道）、缺陷的等级划分（致命、严重、一般、建议）、以及如何写一份高质量的缺陷报告单——标题、复现步骤、预期结果、实际结果、日志截图、优先级，这些要素一个都不能少。
自动化测试方面，像Selenium、Appium、JMeter这些工具是笔试常考词汇。但校招笔试通常不会让你手写自动化测试框架，而是考概念：什么是Page Object模式？自动化测试的适用场景是什么？哪些用例适合自动化哪些适合手工？说到底是在考你有没有基本的测试思维，而不是工具操作能力。
4.3 场景题如何回答：以"CPU飙高"和"登录功能测试"为例
运维和测试岗位的笔试题里，最让同学头疼的是场景题。这类题没有标准答案，却最能拉开分数差距。我拿两个最常见的例子来拆解一下回答套路。
第一个是运维场景："服务器CPU使用率飙到100%，如何排查？"低分回答是"重启服务器"。高分回答是分步走：先top找到占用CPU最高的进程PID，然后根据PID找到对应的线程，再通过jstack（如果是Java进程）导出线程快照，分析是业务线程死循环、GC频繁、还是出现了CPU密集型的计算任务。如果是非Java进程，用perf等工具进一步分析热点。最后结合监控平台的历史数据，确认是突发流量、代码bug还是硬件问题。整个回答展示的不是单一命令，而是一条完整的排查链路。
第二个是测试场景："一个用户登录功能，你怎么设计测试用例？"低分回答是"输入正确的用户名密码能登录，错误的不能登录"。高分回答会从功能、安全、性能、兼容性四个维度展开。功能上覆盖正常登录、错误密码、账号锁定、记住密码、忘记密码；安全上覆盖SQL注入、密码明文传输、验证码时效、暴力破解防护；性能上覆盖并发登录压力、数据库连接池大小；兼容性上覆盖不同浏览器、不同移动端尺寸。这样的回答让面试官一眼看出你有系统的测试思维，而不是单纯地想到什么写什么。
4.4 运维测试岗备考的独特策略
想在校招笔试中拿下运维或测试方向，我的建议是不要跟开发岗的同学比算法和代码能力，而是要比系统思维和场景覆盖度。
运维岗的复习重点应该放在：Linux常用命令的熟练度（尤其是组合用法和管道通信）、网络协议的基础（TCP三次握手、HTTP状态码、DNS解析流程）、常见的服务部署与排障流程（Nginx、MySQL、Redis这些中间件的基本操作）。测试岗的复习重点应该放在：测试用例设计方法论、缺陷管理流程、接口测试的基本思路（POST/GET请求、鉴权、参数校验）、以及至少一种自动化测试工具的基本使用。
还有一个技巧：做笔试的时候，遇到场景题不要慌，试着把思维过程清晰地写在答案里。很多在线笔试平台有"分步给分"的机制，就算你的最终结论不完美，完整的分析过程也能帮你拿到不少分。
5. 数据库题：索引、事务、SQL手写，经典题为何年年出现
数据库方向在唯品会这套B卷里的地位非常特殊。它不像Java和前端那样动辄手写几百行代码，也不像运维测试那样靠场景题拉分，但几乎所有岗位——无论是后端、测试还是运维——都会在笔试中遇到数据库题。所以把这个模块单独吃透，性价比极高。
5.1 SQL手写题：多表关联、分组、去重，基本功怎么练
校招笔试里的数据库题，通常分两部分：一部分是SQL手写题，一部分是概念和原理题。
SQL手写题是硬功夫，没有任何捷径。最常见的是"给两张表，写一条SQL查出某某数据"这种模式。比如学生表、成绩表，让你查出"每门课成绩最高的学生"。这种题考察的其实是GROUP BY、HAVING、ORDER BY、LIMIT这几个子句的组合使用，以及JOIN（INNER JOIN、LEFT JOIN）的理解。
我特别想提醒一下去重和分组。count是统计所有行，count(distinct)是去重后统计。GROUP BY和DISTINCT有时候能达到同样的结果，但语义不同，性能也不同。笔试中经常故意混淆这两个概念，如果你不清楚它们各自的适用场景，很容易踩坑。
另外，SQL题一定要自己动手敲。我见过太多人笔试前只看不练，觉得自己"会写SQL"，结果真到了笔试环节，连最基本的语法都写不完整——表名写错、别名加不加引号、关键字大小写、分号漏掉、字段没对齐，这些问题在IDE里有提示看不出来，到了笔试平台就全都暴露了。
5.2 索引与执行计划：为什么B+树，什么是索引失效
数据库原理题里，索引绝对是最核心的考点。基本上每套校招笔试题都会问"MySQL为什么用B+树而不是B树、红黑树、哈希表"。这个问题的标准答案分成好几层：B+树非叶子节点不存储数据，所以相同大小的磁盘页能容纳更多索引项，树的高度更低，IO次数更少；B+树的叶节点用链表相连，非常适合范围查询；B+树的数据都在叶节点，查询路径稳定，性能更可控。
索引失效这个问题也是高频。给出一条SQL，问你"这条查询能用上索引吗"或者"怎么优化这条SQL"。最常见的失效场景包括：在索引列上进行函数运算或隐式类型转换、LIKE前置通配符、OR条件中有一个字段没有索引、索引列上使用了!=或NOT IN、组合索引没有遵循最左前缀原则。这些知识点如果只看书不实践，很容易记混。建议你拿到一条SQL后，实际用EXPLAIN看一下执行计划，观察type字段是ALL还是range还是ref，key字段有没有命中索引，然后对比着理解索引失效的原理。
5.3 事务与隔离级别：ACID、脏读幻读、MVCC
事务相关的考点，核心是ACID四性（原子性、一致性、隔离性、持久性）和四种隔离级别（读未提交、读已提交、可重复读、串行化）。每种隔离级别能解决什么问题、会引发什么问题，必须烂熟于心。
最容易搞混的是脏读、不可重复读、幻读的区别。简单来说：脏读是读到别人未提交的数据；不可重复读是在同一个事务里，两次读取同一行数据，结果不一样（重点在"行的内容变了"）；幻读是在同一个事务里，两次执行同一查询，结果集数量不一样（重点在"行数变了"）。把这三个定义记清楚，再做选择题就顺了。
MySQL默认的隔离级别是可重复读，这一点也是问烂了的考点。但真正能拿高分的同学，还会知道InnoDB是如何通过MVCC（多版本并发控制）来实现可重复读的——每条记录背后有隐藏的版本号字段，读操作读取的是快照版本，写操作创建新版本，通过版本链和ReadView实现不同隔离级别下的读写不冲突。这些内容虽然在校招笔试中不一定直接考，但如果你是Java岗或数据库岗，面试官大概率会顺着隔离级别追问到MVCC这一层。
5.4 范式与反范式：从笔试题到真实业务设计
数据库理论题里，范式和反范式是选择题常客。第一范式要求字段原子性，不可再分；第二范式要求非主键字段完全依赖主键，不能部分依赖；第三范式要求非主键字段不能传递依赖。这些定义记住了，题目就能拿分。
但我想多说一句：笔试里让你判断"这个表符合第几范式"只是最基础的考法。真正有区分度的题目是让你设计表结构，或者给你一个不规范的表让你优化。这时候考的就是你有没有"反范式"的思维——在实际的大数据量业务中，完全满足第三范式往往意味着大量的JOIN操作，而JOIN太多会严重影响查询性能。所以很多互联网公司会故意做冗余设计，用空间换时间。如果一个同学只会背范式定义，不知道"范式与性能的权衡"这回事，答这种设计题就非常吃亏。
结合刚才提到的热搜词"数据库增删改查""数据库同步工具"来看，现在的数据库笔试已经不只是考课本概念了，它越来越偏向真实业务场景。主从复制、分库分表、读写分离、数据同步延迟、慢查询优化，这些工程问题正在逐步进入校招笔试的范围。所以复习的时候，除了基础理论，我强烈建议多了解一些真实业务中的数据库优化手段，哪怕只是概念层面的了解，也能在笔试中帮你多拿好几分。
6. 这套卷子的正确打开方式：三轮复盘法与我踩过的复习坑
讲完了具体考点的分析，最后说说更实际的问题：这套题到底怎么刷，才能发挥最大价值？我在带校招生和帮朋友做考前辅导的过程中，积累了一套亲测有效的复习方法，今天完整分享出来。
6.1 我的三轮复盘法
第一轮：限时模拟。找一个完整的时间段，严格按照笔试的时长和要求，把整套卷子做一遍。这个阶段的目的不是做对，而是摸底。做完之后不要马上看答案，先把"蒙的题""不确定的题""完全没思路的题"分别标记出来。这三种题暴露的问题完全不一样：蒙的题说明你见过但没记牢；不确定的题说明你有知识框架但细节缺失；完全没思路的题说明你的知识盲区比较大。
第二轮：逐题溯源。这一步最关键，也是最花时间的。每道题，不管做对做错，都要追问一句"这道题在考什么知识点"。做错的题，回到教材或官方文档里，把这个知识点的来龙去脉搞清楚。做对的题也不要放过，因为很多题你做对只是碰巧，换个角度问同样的知识点你就不会了。这个阶段最好配合笔记，每道题记录下"题目-知识点-我的理解-常见变体"。比如HashMap那题，知识点是"map底层结构和扩容机制"，常见变体是"concurrentHashMap和HashMap的区别""hashTable和HashMap的区别"。
第三轮：讲给别人听。找人听你讲题，或者对着空气讲都行。费曼学习法的核心就是这个——如果你能把一个知识点讲得让一个外行听懂，说明你是真的掌握了。我在辅导校招生的时候，经常采用"让同学讲给我听"的方式，发现一个特别普遍的现象：很多同学自己做题时觉得"我会了"，一开口讲才发现逻辑不通、概念混淆。这一轮就是帮你把隐藏的知识漏洞彻底暴露出来。
6.2 错题知识图谱的搭建
三轮复盘做完，你手头会有一堆错题记录。这时候不要看着一堆散乱的知识点发呆，把它们按照岗位方向归拢，建一张知识图谱。
以Java方向的错题为例，把所有错题贴上标签：集合类、JVM、并发、基础语法、异常处理。然后你会发现，错题集中度非常高——比如"集合类的题错了5道，其中3道都是HashMap的"。这个集中度就是你复习优先级的风向标，说明这个知识点是你的薄弱环节，需要投入更多时间。
不要试图一次性补全所有知识盲区。人的注意力是有限的，校招准备期通常只有2到3个月，把精力集中在正确率最低的2到3个知识点上，把它们彻底吃透，比平均用力效果要好得多。等到下一次限时模拟时，再重新统计错题分布，你会看到这些薄弱环节是否真的被补上了。
6.3 做题顺序与时间分配
很多同学笔试挂科，不是不会做，而是时间不够。校招笔试的时间限制一般很紧，尤其是编程题，有时候一道题就能耗掉半小时。怎么分配做题时间，是有策略的。
我的建议是：先做会做的，再做能做的，最后死磕不会的。单选题和多选题通常占分不大但数量多，如果卡在一道不确定的多选题上超过3分钟，直接跳过，先把后面的简答题和编程题做完。编程题优先选择自己最有把握的题，先拿稳这部分的分，再回头处理难题。
时间分配上，大致可以按7:3的比例来切——70%的时间给编程题和简答题，30%的时间给选择题。因为选择题分值小，即使全对也拉不开太多差距；而编程题和场景简答题虽然是压轴题，但分值大、区分度高，值得你把最多的精力投进去。
还有一个很多人忽略的点：笔试平台一般支持分题保存答案，做完一题就保存一题。我见过有同学在最后几分钟连续点了好几道题的空白提交，就是没有养成"边做边保存"的习惯。这个细节看似不起眼，但在大型校招笔试中，系统异常、页面卡顿、本地网络中断这些意外情况都有可能发生，边做边存是最稳妥的做法。
6.4 给不同基础读者的复习节奏建议
如果你现在是大二、大三，离校招还有一段时间，我建议的路线是：先把基础课程吃透，数据结构、操作系统、网络、数据库这四门课是你笔试的底子，然后在GitHub上找几个高质量的开源项目，精读其中与你岗位方向相关的部分，顺便积累一些可以写进简历的项目经历。这套B卷可以先作为摸底测试，标记出自己的薄弱环节，然后慢慢补。
如果你已经进入校招季，时间紧迫，那策略就完全不同了。此时最重要的是"主攻高频考点，放弃冷门知识点"。Java岗就把集合、JVM、并发三件套过一遍；前端岗就把事件循环、闭包、作用域、手写题过一遍；数据库岗就把SQL、索引、事务过一遍。不要试图面面俱到，把最高频的考点吃透，配合中等偏上的算法能力，笔试过关是有保障的。
如果你已经工作了一段时间，再看这套题不是为了校招，而是为了查漏补缺，那我的建议是重点关注那些"你平时工作里接触不到的知识点"。很多工作三五年的工程师，业务代码写得很溜，但底层基础早就还给老师了。偶尔用这套题自测一下，能帮你发现自己知识体系中的盲区，对后续的成长也有好处。
回到我自己，每年校招季帮同学做笔试复盘的时候，最常感叹的一句话是：这套题其实不难，但每年都有人栽在同样的几个坑里。如果你真的把上面这些内容消化透，再把那套B卷认真做上两三遍，我相信你的校招笔试不会成为短板。最后一个实操小技巧：做题的时候，每道题做完后花10秒钟在草稿纸上写下这道题对应的核心考点，整套卷子做完之后，你就有了一张高价值的"考点频率表"。这张表比任何网上的总结都更贴合你自己的薄弱点，也最能帮你在面试前快速回顾重点。
