凤凰网2017秋招研发笔试题复盘：数据结构与算法核心考点解析

这套卷子是我整理旧硬盘时翻出来的，一份凤凰网2017年秋招研发工程师的笔试试卷，PDF扫描版，上面还有我当时用铅笔画的草稿。说实话，以今天的视角回头看这套题，很多知识点已经变了，但把题一道一道过完之后我的感觉是：底层考察逻辑几乎没有变。你依然可以用一套清晰的框架去准备绝大多数互联网公司的研发岗笔试——数据结构与算法是核心，计算机网络和操作系统是基础盘，再加上一小部分语言细节和开放性思考题。

这篇文章就是基于这份2017年试卷的完整复盘。我会先拆解试卷结构，再按题型逐个讲清楚考了什么、为什么考、以及我建议的应对方式。文章里涉及的题目我都用自己的话重写过，不是原卷照搬，但考察点和难度保持在同一个水平。不管你是正在准备校招的应届生，还是想查漏补缺的初级工程师，这份复盘应该都能帮你在有限时间内抓到重点。

1. 为什么还在看一份2017年的老卷子——先聊聊它的参考价值

很多人一听到“2017年的笔试题”第一反应是：这都过时多久了，看它有什么意义？我一开始也是这么想的。但真正把题看完之后，我改变了看法。它不是一个“过期题库”，而是一份很好的能力坐标图。

1.1 校招笔试的考察逻辑这几年并没有变

技术面试也好，笔试也好，考察的无非是三件事：第一，你有没有扎实的基础知识；第二，你能不能把知识用在具体问题上；第三，你在压力下怎么组织思路、管理时间。2017年的凤凰网这套卷子，恰好把这三件事都覆盖到了。

当时的互联网公司，尤其是做内容平台和媒体业务的，研发岗笔试普遍采用“选择题 + 简答/设计题 + 编程题”的组合方式。这份卷子也是这个结构。它不会像Google那样全员LeetCode Hard，也不会像某些外包公司那样只考框架API背诵，而是走了一条比较典型的国内互联网公司的路线：广度为主，深度为辅，再加上少量工程实践题。

也正是因为这种“典型性”，这套卷子对整个秋招备考有很强的参照意义。你现在去投字节、百度、阿里、美团这些公司，笔试题的框架其实没有本质变化，变化的主要是题目难度、题库规模、以及在线评测系统对代码格式和运行效率的要求。

1.2 透过试卷反推岗位能力画像

从这套题往回推，可以看到凤凰网当时对研发工程师这个岗位的能力预期。简单来说，他们希望招来的人具备四层能力：

• 第一层：编程基本功。至少熟练掌握一门语言，能写清楚循环、递归、指针或引用、内存管理这些基础概念。
• 第二层：计算机基础。数据结构、算法、网络、操作系统，这些课程里的核心知识得真正理解，而不是考前背概念。
• 第三层：问题拆解能力。遇到一个不熟悉的问题，能不能通过画图、举例、分解子问题来找到解决方案。
• 第四层：工程意识。代码要考虑边界条件、复杂度、可读性，甚至要考虑并发和异常恢复。

这四个层次不是分开考的，而是混在题目里。选择题可能同时考察语言细节和数据结构，简答题可能同时考察网络协议和系统设计，编程题则把它们全部压在一起。你能把哪一层打通，基本就对应你能拿到的薪资区间。

2. 试卷结构拆解：从题型布局看公司到底想要什么人

先看整体结构。这份试卷满分100分，考试时长120分钟，一共包含五种题型。从分数占比上就能看出，公司最看重的是什么。

2.1 题型分布与分数占比

我根据记忆把原卷的结构整理成了表格，每类题的分值和大致题量如下：

从分数占比来看，编程题一家独大，两道题占了40%的分值，这印证了研发岗笔试的核心逻辑：代码能力才是门槛。简答与设计题紧随其后，说明公司不只想招“会写代码的”，还希望你有一定的系统设计能力和文字表达能力。

2.2 为什么“基础题”反而决定你能不能进面试

这个点可能和很多人的直觉相反：编程题占40%，那我把编程题做好不就行了吗？不行。当时我身边有同学就是这个策略，结果笔试挂得很惨。原因很简单：如果选择题和填空题的正确率不够，总分就很难看，哪怕编程题全对也拉不回来。更关键的是，面试官在看简历筛选时，笔试成绩是一个综合指标，编程题高分但基础题大量失分，会给人一种“基础不牢”的印象。

我当时对这套卷子做了一次模拟：只做编程题，不做选择和填空，得分大概在40分左右。然后我完整地做了一遍，最终得分在70分上下，差距非常大。这个差距不是来自某一道难题，而是来自15道单选题里的概念陷阱和5道填空题里的细节推演。

所以，如果你现在还在备考阶段，我的建议是：不要因为编程题分值高就轻视选择题。它们考察的知识点往往是编程题的前置条件。比如，你连哈希表冲突处理方式都分不清，遇到LRU Cache这类题就很难落地；你连TCP四次挥手的状态变化都说不清楚，遇到网络编程相关的题目也会发怵。基础题的真正作用不是拉分，而是帮你暴露知识盲区。

3. 选择题与填空题的“考点解剖”：那些看似简单但失分率很高的坑

这张试卷的选择题和填空题，放在今天来看，考点覆盖面依然有很强的参考性。我挑了几类典型题目，做一个考点复盘。重点不是把答案告诉你，而是把背后的知识链路讲清楚。

3.1 语言细节题：考的是“有没有真正写过代码”

选择题里有一类题是这样的：给定一段C语言代码，问输出结果。这类题看起来特别基础，但失分率很高。原因在于，出题人往往会在几个地方埋坑——运算符优先级、类型转换、指针自增自减、宏定义展开、以及存储类型作用域。

我印象很深的一道题是考察宏定义。题目大致是这样：

#define SQUARE(x) x*x int main() { int a = 5; int b = SQUARE(a + 1); printf("%d", b); return 0; }

如果对宏展开机制不熟悉，很多人会直接算成(a+1)*(a+1)=36。但实际结果是a+1*a+1=5+5+1=11。这就是宏定义的经典坑：它只是纯文本替换，不保证运算优先级。这道题考察的知识点是“预处理阶段发生在编译之前”，本质上是在问：你到底有没有理解编译流程，而不只是背过宏定义的概念。

处理这类题的建议是：在草稿纸上把宏展开的每一步写出来，不要心算。心算在大脑里会默认补上括号，而代码不会。

3.2 数据结构概念题：不能只背定义，要能画出结构

选择题里还有相当比例的题是数据结构相关的。比如：

• 哈希表解决冲突的常见方式有哪些？链地址法和开放定址法各自的适用场景是什么？
• 二叉搜索树的中序遍历结果是什么？如果插入顺序不同，树的形状会怎么变化？
• 快速排序的时间复杂度，最坏情况是什么？什么输入会导致最坏情况？
• 栈和队列在DFS和BFS中的对应关系是什么？

这些题单独看都不难，但出题人喜欢把它们组合起来，制造混淆项。举个例子，有一道多选题同时涉及了二叉树的遍历和栈的使用：已知一棵二叉树的前序遍历结果和中序遍历结果，问能不能唯一确定这棵二叉树，以及如果已知前序和后序，又能不能唯一确定。

答案是：前序+中序可以唯一确定；前序+后序不能唯一确定，除非是满二叉树。这个结论很基础，但很多人会混淆。原因在于他们只记住了“前序+中序可以确定”这个结论，却没有去推导确定的过程。

我当时备考时的做法是：对于每一个数据结构，都亲手画一遍结构图，模拟一次插入、删除、查找、遍历的过程。这个过程看着慢，但对加深理解特别有效。笔试时遇到数据结构题，你在脑海里能快速“播放”数据结构的操作过程，答案自然就出来了。

3.3 网络与操作系统题：考察的是“连接能力”，不是单点记忆

选择题里还经常出现网络和操作系统的内容，比如：

• TCP三次握手过程中，客户端和服务端的状态分别是怎样的？
• TCP和UDP的区别，哪些应用适合用TCP，哪些适合用UDP？
• 进程和线程的区别，哪些资源是共享的，哪些是私有的？
• 死锁产生的必要条件有哪些？如何避免死锁？
• 虚拟内存的作用，页面置换算法有哪些？

这些知识点单独背下来不难，但题目往往会设置一个具体场景，考察你能不能把知识用起来。举个例子，有一道题问：一个Web服务器，客户端关闭了浏览器页面，服务器端的TCP连接会发生什么？这个问题的核心在于理解TCP的状态转移：客户端关闭连接时，会发送FIN报文，服务端收到后进入CLOSE_WAIT状态，然后服务端再发送FIN，最后进入TIME_WAIT状态。如果你没理解状态转移，只背了状态名，遇到这种场景题一定会纠结。

我当时复习操作系统和网络的方法是把知识点串成一条线：从输入URL到页面展示，中间涉及哪些计算机基础知识点？DNS解析（网络）→ TCP连接（网络）→ HTTP请求（网络）→ 服务器处理（操作系统/编程语言）→ 磁盘IO（操作系统）→ 数据库查询（数据结构）→ 页面返回（网络）。这套逻辑不仅帮我应付了笔试题，后来面试时也经常用到。

3.4 填空题的隐藏价值：让你暴露“差不多先生”的毛病

填空题在这套卷子里虽然分值不高，但它有一个独特价值：逼你给出精确答案，而不是从选项里猜。我印象里有一道填空题是让写出二分查找在长度为n的有序数组中的时间复杂度，并要求说明最坏情况下需要比较几次。还有一道是给出一段递归代码，要求写出它的输出结果。

这类题失分的原因往往不是不会，而是“差不多”。比如二分查找的时间复杂度是O(log n)，很多人能答上来。但如果题目问的是“最坏情况下需要比较几次”，那就需要你精确算出来：log2(n)向下取整加1。这个时候，记忆模糊和概念不清都会立刻暴露。

填空题的备考方式其实和选择题类似，但现在你在输出答案时，维度上多了一步：你要学会“推演过程”而不是“猜答案”。特别是递归题和复杂度计算题，不要在脑子里想，直接用手在纸上推演一遍。我当时备考时有个习惯：把每道错题的推演过程完整写在笔记本上，包括我踩过的错误步骤。这个习惯帮我在真正的笔试中减少了很多低级失误。

4. 简答与设计题：拉开差距的不是“会不会”，而是“怎么表达”

简答与设计题是这份卷子里含金量最高的部分之一。它没有标准答案，但考察的是你能否用技术方案解决一个相对宏观的问题。这类题往往是很多考生的噩梦，因为它没有现成的“八股文”可背。

4.1 典型题目复盘：一个微型系统设计题的完整思考链路

这套卷子有一道设计题，大致内容是：设计一个短网址服务，要求支持高并发访问，并保证URL转跳的正确性。题目要求画出系统架构图，并解释关键模块的作用。

这个题在2017年算是比较经典的“微型系统设计题”。放在今天依然很流行。我当时做题时的思路是这样的：

第一步，明确核心功能。短网址服务的核心只有两件事：长URL转短URL、短URL还原长URL。第二步，设计数据存储。核心映射关系是短码到长URL的映射，一般用数据库表存储，或者用缓存加速读操作。第三步，生成短码。可以用哈希算法生成，比如MD5，但为了保证短码长度可控，通常取哈希值的前几位，并处理碰撞。第四步，考虑高并发。读操作远多于写操作，所以要用缓存，比如Redis，并且要设计缓存穿透、缓存击穿的应对方案。第五步，考虑负载均衡和扩展。DNS层做负载均衡，应用层做水平扩展，数据库层做读写分离。

这套思路并不是什么高深理论，但它体现了一个工程师的完整思考链路。笔试时，你不一定要把每个模块都写得很细，但一定要展示出“我考虑到了哪些问题”和“我为什么这么设计”。

4.2 简答题的“踩分点”：用结构化表达降低阅卷成本

简答题和设计题本身没有标准答案，但阅卷老师在拿到一份答卷时，内心其实有几个“踩分点”在等着你。我把它们总结成三个关键词：结构、取舍、边界。

所谓“结构”，是指你的回答要有层次，不要一大段文字糊上去。我在当时答题时，习惯用“一、二、三”分点，每个分点下面再用“是什么、为什么、怎么办”来展开。这样阅卷老师扫一眼就能抓到你的思路。所谓“取舍”，是指你要清楚地说明在多个方案之间为什么做这个选择。比如，短码生成可以用哈希，也可以用自增ID，为什么选哈希？因为自增ID会暴露系统规模，且容易被人恶意遍历，所以哈希更合适。能说出这个取舍，分数就不一样。所谓“边界”，是指你要主动指出方案的局限性和异常情况。比如，缓存失效时如何应对，数据库宕机时怎么做容灾，短码冲突了怎么办。这些边界条件是你从“入门工程师”走向“靠谱工程师”的分水岭。

4.3 为什么开放题答得好的人，后期成长往往更快

从这道设计题往回看，我觉得笔试里的开放题和实际工作之间的关联度非常高。校招生入职后的前几个月，做的大部分工作都是“在已有系统上做增量开发”，需要你快速理解现有架构、理解数据流向、理解模块间的依赖关系。而开放题恰好考察的就是这些能力：理解需求、拆解问题、权衡取舍、表达方案。

我见过不少笔试阶段编程题刷得很好的候选人，反而在开放题上栽了跟头。原因是他们习惯了“做题家思维”：题目给了明确的输入输出，我要在限定时间内写出AC代码。但开放题没有明确的输入输出，它需要你自己定义问题、自己划定边界、自己给出判断依据。这种能力光靠刷题是刷不出来的，必须在平时做项目、写代码时有意识地去练习。

5. 编程题实战复盘：两道题背后的算法核心

编程题是这套卷子的重头戏，也是很多备考者的命脉。虽然编程题的题库每年都在更新，但考察的算法核心其实是固定的。我把这套卷子里的两道编程题做了一个复盘，虽然原题细节我已经记不太清了，但核心考法是可以还原的。我当时看到这两道题时的第一印象是：没有特别难的题，但每一道都有陷阱。

5.1 第一道编程题：字符串相关的“伪装难题”

第一道题考察的是字符串处理，大致需求是：给定一个字符串，找出其中最长的不含重复字符的子串长度。这个题在LeetCode上对应的是第3题，属于中等难度。但放到2017年的校招笔试里，已经算得上是比较经典的难题了。

这道题的主要考点有两个：一是滑动窗口思想，二是哈希表/数组优化。

滑动窗口的核心逻辑是：维护一个左指针和一个右指针，右指针不断向右扩展，把字符放入一个集合里；如果遇到重复字符，就移动左指针，直到集合中不再有重复字符。在这个过程中，记录窗口的最大长度。用哈希表（或者直接用一个长度为128/256的数组）来记录每个字符最后一次出现的位置，可以把时间复杂度优化到O(n)。

我当时在这道题上的一个失误是：一开始用了暴力解法，双重循环遍历所有子串，然后逐一检查是否有重复字符。这个解法的时间复杂度是O(n²)，虽然逻辑简单，但肯定不是最优解。在做笔试时，如果题目有时间限制或者要求优化，暴力解基本拿不到满分。后来我调成滑动窗口之后，代码简洁了很多，也更容易验证正确性。

5.2 第二道编程题：二叉树遍历与层级结构的综合

第二道题和二叉树相关，大致需求是：给定一棵二叉树，返回它的层序遍历结果，即按层输出节点的值。这道题在LeetCode上也有对应原题（第102题），难度也不高。

但题目的细节里有一个小坑：它要求每一层的节点值作为一个单独的列表返回，也就是说，你需要知道当前遍历到第几层。如果你只是简单地用队列做BFS，不记录层级信息，最后输出的就是摊平的一维列表，和题目要求不符。当时的做法是：在每次循环开始时，先记录当前队列的长度，这个长度就是当前层的节点数；然后循环处理这长度个节点，把它们的值加入当前层列表，同时把下一层的子节点入队。这样循环结束后，队列里剩下的就是下一层的节点。

这道题的整体难度不高，但它考察了一个很重要的能力：在基础算法框架上，根据题目要求调整细节。我见过太多人遇到“层序遍历”就条件反射式地写一个裸BFS，完全不去读题目中“返回层次结构”的附加要求。这种“会但不仔细”的失分，其实比“不会”更可惜。

5.3 编程题的通用答题框架：我笔试时的固定流程

把这两道题放在一起看，我总结了一个笔试编程题的固定答题流程，这个流程在我后续的面试和实际工作中也一直在用：

• 读题后先花1分钟确认输入输出格式。特别要注意边界条件，比如输入为空、只有一个节点、字符串长度极大等。
• 用2分钟在草稿纸上画一画样例，把题目转化成自己熟悉的问题模型。比如“找最长不重复子串”转化的是“滑动窗口”，“层序遍历”转化的是“BFS+层级标记”。
• 想清楚复杂度要求。如果数据规模是10^5，O(n²)基本必挂；如果数据规模是100，O(n²)也可以接受。不要盲目追求最优解，要选一个“写得出来且能过”的解法。
• 写代码时先写核心逻辑，再补边界处理。很多考生会先纠结边界条件，写到一半发现核心逻辑还没出来，最后时间不够用。
• 写完代码后，用自己构造的三个测试用例验证：一个正常用例、一个边界用例、一个极端用例。

这套流程看着简单，但能帮你腾出大量思考时间。我在平时做题时也建议按照这个顺序来训练，形成肌肉记忆之后，笔试时的效率会明显提升。

6. 从这套卷子反推秋招备考路径：时间紧张时抓大放小

很多人备考校招时最大的焦虑是：知识点太多了，永远学不完。然后就开始盲目刷题、背题、看面经，越看越慌。但当你真正吃透一份历年笔试真题之后，你会发现，备考其实可以做减法。

6.1 建立“优先复习矩阵”

这套卷子给我最大的启发是：基础知识和算法永远是重心。你可以花30%的时间在计算机网络、操作系统、数据库等课程上，但一定要用50%以上的时间在数据结构和算法上。剩下20%的时间，用来准备项目复盘和开放题。

我一般会把要复习的知识点分成四个象限：第一象限是“重要且常考”，比如数组、链表、栈、队列、哈希表、二叉树、排序、二分查找、动态规划基础。第二象限是“重要但不常考”，比如红黑树、B+树、KMP算法、图论算法。第三象限是“常考但不重要”，比如特定语言的一些细节题、Linux常用命令、正则表达式。第四象限是“不常考也不重要”，比如汇编语言细节、某些冷门协议。第一象限优先复习，第二象限按需复习，第三象限考前突击，第四象限直接放弃。

这样做的好处是，你能在有限时间内把核心知识复习到位，而不是被“什么都想学”的焦虑拖垮。我当年备考时，有一段时间每遇到一个新知识点就想学，结果今天看Raft协议，明天看布隆过滤器，后天又去刷操作系统大题，最后每个知识点都是“半桶水”。后来按照优先矩阵来分配时间，效率明显提升。

6.2 刷题的正确姿势：少刷一百道，吃透五十道

我见过很多同学用“刷题数量”来标榜自己的努力，比如“我已经在LeetCode上刷了300道题”。但一到真正笔试时，遇到稍微变形一点的题就卡住了。问题出在他们只是“做完了”题，而不是“吃透了”题。

我自己的经验是：每做完一道题，至少花同样多的时间做复盘。复盘内容包括三件事：这道题用了什么数据结构和算法？为什么用这个解法而不是另一个？如果把题目条件稍作调整，解法会怎么变？比如前面提到的“最长不重复子串”问题，它用滑动窗口解决，但滑动窗口还能解决哪些问题？数组里最长连续子数组和？固定长度的子串最大值？如果你能把一套滑动窗口框架迁移到不同题目上，刷题效率会提升好几倍。

另外，我不建议一上来就刷Hard题。校招笔试里，大多数公司出题难度是LeetCode Medium为主，少量Easy和Hard。你先把Easy和Medium的经典题吃透，再去看Hard，这是最稳妥的路径。尤其是二叉树、链表、动态规划基础、字符串处理这四大类，几乎每家公司的笔试都会涉及。

6.3 开放题和设计题：平时多问自己“如果是我设计，我会怎么做”

前面说开放题是拉开差距的关键，但很多人不知道怎么准备。我的建议是：把日常写代码时接触到的系统，都当成一个设计题来思考。比如你每天用的短网址服务、新闻客户端的信息流、电商系统的购物车、微信的聊天记录存储，这些你都可以问自己几个问题：数据存在哪里？用什么数据结构？如何保证性能？如果某个环节挂了，怎么办？

这些问题不需要你很深入地研究，只需要形成一个思考习惯。笔试时遇到开放题，你至少能说出几个模块、几个注意点、几个方案。这种“说得出东西”的状态，比憋半天憋不出一个字的状况强太多。我当年准备校招时，会把这类思考记录下来，形成自己的“设计题素材库”。后来很多面试中的系统设计题，我都能从素材库里快速找到类似案例。

7. 这套卷子的年代感与传承：为什么我不建议直接背题

说句实话，拿2025年的眼光去看2017年的试卷，有些题确实带有一点“年代感”。比如，卷子里对移动端开发、大数据处理、推荐算法这些内容的考察比重都很低，这在今天的内容平台公司校招里是不可想象的。但反过来，这也说明了一个问题：直接背题是没用的，你需要理解题目背后的底层能力。

7.1 技术栈会变，能力模型不会变

2017年那会儿，校招笔试里还经常考Linux基础命令，比如查看进程、查看端口占用、文件权限修改这类题目。现在这些内容依然会考，但更多地变成了“基于实际场景的排错题”，比如给你一个线上服务CPU飙升的情况，让你给出排查思路。题型变得更综合了，但考察的核心能力还是操作系统知识、命令行熟练度、以及问题定位思路。

再比如，2017年那会儿，JVM内存模型、GC机制、线程池原理是后端开发的高频考点。现在这些内容依旧是Java后端岗位的核心考点，只是考察形式可能变成“你们项目里遇到OOM怎么排查”这种开放题。知识点本身没有变，但出题方式更贴近工程实践了。

所以我的建议是：不要执着于找一份“原题”，然后反复背诵答案。你应该做的是，通过历年真题把握考察范围，然后针对每个知识点去理解它的底层逻辑。

7.2 拿到一份笔试真题后，最正确的打开方式

我身边经常有朋友问我：我拿到一份真题，是先完整做一遍，还是先看答案？我的建议是：先限时做一遍，再对答案，再复盘。具体步骤如下：

第一步，找一个完整的时间段，模拟笔试环境。用手机计时，中间不允许看资料，不允许暂停。这一步的目的是让你真实感受一下自己的节奏。第二步，做完之后，先不要急着看答案，而是自己对照笔记和资料，把不确定的题再查一查。这一步叫“主动回忆”，效果比直接看答案好得多。第三步，把错题和蒙对的题整理出来，按照知识点分类，写进错题本。第四步，针对错题背后的知识点，找3到5道同类题目进行强化训练。只有把一个知识点的不同变形都见过了，你才算真正掌握它。

这个过程看着费时间，但非常值得。我当时在备考时，每套卷子至少花一个下午来复盘，有时候甚至是一整天。但我清晰地感觉到，每复盘完一套卷子，我的知识网络就完整一圈。

7.3 笔试不是终点，而是起点

最后说一点个人感触。笔试通过之后，后面还有一轮又一轮的面试。但回头看，笔试的意义不仅仅是一张通关券。它给你划定了知识边界，也给你建立了系统性的知识框架。当你顺利入职、开始接触实际业务时，你会发现，面试和笔试中考过的那些知识，都会以另一种形式重新出现。

比如，你负责的服务在高峰期QPS增长了几倍，你会发现这不就是笔试里的系统设计题吗？你在排查线上问题时，各种命令和工具用起来，这不就是笔试里的操作系统和网络题吗？你写业务代码时，选择一个合适的数据结构来优化接口耗时，这不就是笔试里的数据结构题吗？所以，认真准备笔试，其实是在为接下来的工程实践打底子。