企业官网建设流程全解析

2017年秋招，我准备投游戏公司技术岗，翻来覆去研究过好几家厂商的笔试题库。等到真正坐在考场上拿到吉比特这套“技术类笔试卷”时，第一反应是：这题出得确实够“游戏公司”——它不是单纯考你LeetCode刷了多少道，而是每个考点都隐隐指向一个游戏研发岗位的真实工作场景。

时隔几年再复盘这套题，你会发现它考察的维度、题型排布、甚至某些“送分题”的陷阱，放到今天的校招笔试里依然有很强的参考价值。无论你是准备投游戏公司技术岗的在校生，还是想转行做游戏开发、想了解游戏公司技术笔试底细的工程师，这篇复盘都能帮你少走弯路。我会尽量还原当时的题型分布、解题思路，以及我踩过的坑和后来的反思。

1. 吉比特这套卷，和普通互联网公司笔试题差在哪

先说一个很多人会忽略的背景：吉比特在游戏圈里的位置比较特殊。它不像腾讯网易那样体量巨大、岗位划分极细，但作为一家以自研产品起家的A股上市游戏公司，它的技术团队对候选人的要求往往更“全栈”一些。2017年正是移动游戏从粗放增长转向精细化运营的节点，吉比特旗下产品线也在快速扩张，这时候招技术岗，看重的绝不只是刷题能力，而是能不能直接上手解决游戏研发中的实际问题。

所以这套笔试卷有明显的“混合气质”。它包含了互联网公司常见的计算机基础知识选择题，但选择题里会更偏向网络、内存、并发这些游戏服务器和客户端都会用到的底层知识；它也包含算法编程题，但这些题不是简单的“反转链表”或“两数之和”，而是带着场景，比如地图寻路、资源调度、状态同步，需要你先把业务问题抽象成算法问题，再动手写代码。

同样值得注意的，是这套卷子对“经验性知识”的考察。游戏开发领域有很多东西是学校里不教、但项目里天天用的，比如渲染管线、DrawCall、热更新方案、帧同步与状态同步的区别。吉比特这套卷子里就有一部分题目专门考这些，你光会写代码不行，还得真对游戏研发流程有了解。这一点和当年很多互联网大厂的笔试题有本质区别——大厂校招更看重算法底子和学习能力，游戏公司校招则更看重“你来了能不能快速融入项目”。

我当时的感受是：这套卷子的出题人，大概率就是游戏项目组里的技术负责人，而不是HR或专门的笔试出题团队。题目里藏着一股“我们踩过这些坑，所以想看看你知不知道”的气息。这种风格在后来我面试其他游戏公司时也遇到过，但吉比特这套卷算是我见到的第一批把“游戏研发实战”和“计算机基础”融合得比较自然的题目。

2. 还原2017秋招笔试的题型结构：分值、时长与考察权重

网上关于这套卷的回忆版不少，综合整理下来，整体结构大致是这样的（具体细节各年份会有出入，但考察框架相对稳定）：

单看分值分布，编程题是大头，和很多公司一样。但这里有个细节：这套卷子的编程题并不是“一上来就写代码”，而是每一道题前面都有一段不算短的场景描述。比如有一道题会先讲“在MMORPG中，玩家头顶需要显示名字和称号，服务端只下发基础数据，客户端要负责排版和碰撞检测时的遮挡处理”，然后才让你实现某个核心算法。

这种出题方式意味着，读题的时间成本很高。如果你习惯了纯算法题的一句话描述，第一次做这种题时会很不适应。我当时就因为在第一道编程题上反复读题，差点没时间做后面的简答题。这是第一个要记住的经验：拿到卷子先扫一遍全部题目，别陷进某一道题里。

简答题的分值占比不低，而且往往是最能拉开差距的部分。选择题大家都能蒙一蒙，编程题靠平时积累，但简答题完全看你对游戏研发领域的理解深度。比如“帧同步和状态同步各自的优缺点”这种题，如果没有实际做过多人在线游戏或者认真研究过相关方案，很难答到点子上。

还有一个容易忽略的细节是答题时长。这套卷子一共给了120分钟，题量不算特别大，但加上读题和思考的时间，节奏其实相当紧。我当时身边的同学有人做完了还有人时间不够用，差距主要出在选择题上——有些人会在纠结某道网络题上花了8分钟，结果后面编程题没时间写。所以后面会专门讲一套时间分配策略，这部分在笔试里真的能当隐形的20分用。

3. 编程题复盘：地图寻路、数据解析与状态设计，每一道都打在游戏开发的痛点上

编程题是整个卷子的核心，也是最有“游戏公司特色”的部分。以当年流传的回忆版来看，三道编程题分别指向三个游戏开发里的典型场景：地图寻路、配置数据解析、状态管理。

3.1 地图寻路类题目：不只是BFS/DFS

有一道题非常典型，大致是：给一个二维网格地图，0表示可通行，1表示障碍物，玩家从左上角出发，需要到达右下角，求最短路径长度；如果不可达，返回-1。

这类题在LeetCode上就是“腐烂的橘子”“岛屿数量”那一类问题的变体，核心解法是广度优先搜索（BFS）。但游戏公司的版本会多两个小变化：一是地图规模可能很大，需要你优化内存占用，不能用太大的辅助数组；二是可能会要求输出路径本身，不仅仅是路径长度。

我当时写的解法是标准BFS：

#include <vector> #include <queue> using namespace std; int shortestPath(vector<vector<int>>& grid) { if (grid.empty() || grid[0].empty()) return -1; int rows = grid.size(), cols = grid[0].size(); if (grid[0][0] == 1 || grid[rows-1][cols-1] == 1) return -1; vector<vector<int>> dirs = {{0,1},{0,-1},{1,0},{-1,0}}; vector<vector<int>> dist(rows, vector<int>(cols, -1)); queue<pair<int,int>> q; q.push({0,0}); dist[0][0] = 0; while (!q.empty()) { auto [r, c] = q.front(); q.pop(); if (r == rows-1 && c == cols-1) return dist[r][c]; for (auto& d : dirs) { int nr = r + d[0], nc = c + d[1]; if (nr >= 0 && nr < rows && nc >= 0 && nc < cols && grid[nr][nc] == 0 && dist[nr][nc] == -1) { dist[nr][nc] = dist[r][c] + 1; q.push({nr, nc}); } } } return -1; }

但你光写出这个只能拿基础分。想拿高分，需要在答案里体现两点思考：

第一，解释为什么用BFS而不是DFS。因为网格是等权的，BFS天然保证第一次到达终点时就是最短路径；DFS虽然也能找到路径，但要回溯所有可能才能确定最短，复杂度高很多。

第二，说明状态设计。dist数组里存的不是“是否访问过”，而是“到当前位置的最短步数”，这一步其实就隐含了visited标记的作用，避免走回头路。如果再进一步，可以把dist数组改成原地修改grid值，用2表示已访问，省掉额外的O(m×n)空间。这种优化在游戏地图很大、内存受限的时候是真实需求。

3.2 配置数据解析：字符串处理是游戏开发的日常

第二道编程题是给一段模拟的玩家日志或配置文件，要求解析出指定字段并统计。这种题在LeetCode上对应的就是字符串处理、split、KV解析一类。

我记得类似题是：给一行一行“key=value;key2=value2”的配置文本，要求解析出某个key对应的value，并且值可能是带引号的字符串，可能包含转义字符。

这道题考察的不是算法，而是代码基本功：是否会熟练处理字符串边界、是否知道转义、是否考虑到空值和异常格式。游戏开发里这种场景太常见了——策划配表、服务器日志、热更配置，大部分数据都是这种“不太规范”的文本格式，你要写一个能容忍脏数据的解析器。

我当时的反思是：这类题没有捷径，就是平时多写、注意边界。比如用C++写字符串处理时，getline、find、substr这些API要熟，还要能处理末尾换行符、Windows和Linux换行差异。如果时间紧张，先实现主流程，再补异常分支，比一开始就想把所有边界都覆盖到更稳妥，因为考试时间不允许你写完完美解法。

3.3 状态设计题：有限状态机在游戏逻辑里的应用

第三道题比较进阶，和游戏里的角色状态、技能释放、AI行为树有关。场景大致是：一个角色有站立、移动、攻击、受击、死亡等多个状态，不同状态下能响应的事件不同，要求设计一个状态管理器，实现状态切换并限制非法转换。

这道题不是纯粹的算法题，更像“设计题+代码实现题”的结合。核心是有限状态机（FSM）的理解和应用。

我当时给出的示例思路是：

enum class State { Idle, Move, Attack, Hit, Dead }; class FSM { public: void addTransition(State from, State to, bool allowed); bool canTransition(State from, State to) const; void changeState(State next); private: State current; map<pair<State, State>, bool> transitions; };

然后重点解释：用二维状态矩阵或map来存合法的状态转换关系，比在changeState里写一堆if-else清晰得多。而且游戏里的状态管理通常要触发进入/退出回调，比如进入Attack状态时要播放攻击动画，退出时恢复移动速度，这些都可以挂在状态转换函数里。

游戏公司考这种题的目的很清楚：想看你有没有“设计可扩展代码”的意识，而不只是“能跑就行”。写法上如果能提到“状态模式”或“有限状态机”的设计模式，会加分不少。

4. 选择题与基础题：并发、内存、网络协议，想进游戏公司先过这三关

编程题决定你能不能进下一轮，选择题决定你能不能过线。吉比特这套卷子里的选择题，知识点覆盖其实和大部分校招笔试差不多，但侧重点有明显倾斜。出了考场之后我和一起笔试的同学对了对题，发现大家丢分最多的地方出奇一致：并发、内存管理、TCP/UDP相关细节。

4.1 并发与多线程：游戏服务器的基础课

选择题里有多道并发相关题。比如问“多个线程同时读写同一个变量，如何保证线程安全”，选项里有mutex、atomic、volatile、加锁顺序等。

很多校招生只知道加锁，但游戏公司更希望你理解：

• mutex开销大但安全，适合临界区较大的场景
• atomic适合整数、布尔值的简单读写，性能更高
• volatile并不保证线程安全，它只保证编译器不优化掉读取操作，很多新手会在这里踩坑

还有一道经典的死锁题：两个线程各自持有一把锁，然后互相等待对方的锁，问如何避免死锁。解法无非是“按固定顺序加锁”或“使用trylock带超时回退”。但放到游戏场景里，还要联想到服务器在锁玩家数据时，如果不按玩家ID的顺序加锁，就可能出现死锁——这点如果能写出来，会显得你真的思考过。

4.2 内存管理：从“什么是内存泄漏”到“如何排查”

游戏客户端对内存的敏感度远高于普通应用。选择题里就有“以下哪种操作会造成内存泄漏”这类题目。

C++方向会考：

• new了没delete
• 基类析构函数没有声明为virtual，导致删除派生类对象时只调用了基类析构
• 容器中存放了指针，clear之后没有遍历删除指向的对象

还有一道我印象深刻的题：问“栈上分配和堆上分配的最大区别是什么”。答案不是“速度不同”，而是“生命周期不同”。栈上变量作用域结束自动回收，堆上变量需要手动释放，理解这一点是理解后面内存池、GC的基础。

游戏公司考这些是因为3D游戏每一帧都在分配和释放内存，如果写代码不注意内存，性能会变得很难看。我在答题时专门对“内存池”这个选项做了批注式解释，虽然卷子上只是选择题，但面试时考官确实会顺着追问“那你知不知道Unity里的GC Alloc是什么”。这种追问逻辑在笔试题目里其实已经埋下了伏笔。

4.3 网络协议与Socket：MMORPG离不开的底层知识

网络部分的题目风格非常“游戏”。有一道题是问“TCP和UDP的区别，哪些场景用TCP，哪些用UDP”，这题本身不难，但选项里放了好几个游戏场景，比如登录、移动同步、聊天、战斗指令。

正确答案方向是：登录、充值等需要可靠传输的用TCP；角色移动、技能释放等对延迟敏感、可容忍丢失的实时操作用UDP，或者用UDP+自定义可靠层。这里有个反向认知：在竞技游戏里，玩家的移动同步很少直接用纯TCP，因为TCP的粘包和拥塞控制会导致延迟增加。

还有一道关于粘包的题：TCP是流式协议，接收方怎么判断一条消息的边界？答案通常是“定义消息头，包含消息长度字段”或“用特殊分隔符”。这几乎是游戏服务器开发最常见的考题。我后来在面试环节还被追问了“Netty的LengthFieldBasedFrameDecoder怎么配置”，所以笔试里看似很基础的知识点，往往是面试深挖的起点。

数据库和操作系统在这套卷子里也会考，但权重不及以上三类。数据库无非是索引失效场景、事务隔离级别；操作系统则是进程线程区别、虚拟内存、进程调度。这些和互联网公司笔试重合度很高，按常规准备即可。

5. 游戏研发特色题：帧同步、渲染优化、资源管理，答出层次才能拉开分

这套卷子最有辨识度的题目，是简答题里那几个只有游戏公司才会考的题目。它们分值不算最高，但区分度极大。不少计算机基础很好的同学，在这一块直接懵了，因为学校里根本没教过。

5.1 帧同步与状态同步，怎么答才完整

有一道比较典型的简答题：解释帧同步和状态同步的区别，并分别给出适用场景。

我当时的答题思路是三层递进：

第一层，说清楚定义。状态同步是服务器计算所有战斗结果，把广播状态给客户端；帧同步是所有客户端一致地执行每帧操作，逻辑在本地跑，服务器只做转发和校验。

第二层，对比优缺点。状态同步防作弊能力更强，逻辑集中在服务端，容易做维护和校验，但开发和带宽成本高；帧同步省带宽、打击感更强、手感更跟手，但反作弊难度大，客户端要求高度一致。

第三层，结合游戏类型。类似MMORPG这种角色属性、掉落、养成很复杂的游戏，更适合状态同步；而“格斗游戏”或“多人竞技塔防”这种强调手感和精确反馈的，帧同步更合适。如果能再补一句“帧同步要处理好浮点数一致性和随机种子问题”，面试官基本就会在心里给你加分了。

这道题没有标准答案，但层次感很重要。只写一个优缺点列表的，和能把知识点联系到实际游戏类型的，得分差距很明显。

5.2 渲染管线与DrawCall优化

还有一道题是问“Unity或游戏中如何减少DrawCall，提升渲染性能”。这题一看就是客户端方向的人出的。

回答要点要覆盖：

• 合批（Batching）：把同材质、同纹理的小物体合并成一次DrawCall
• 纹理图集（Atlas）：把多个小图合并成一张大图
• 减少实时光照和阴影
• 使用LOD（Level of Detail），远处用低模
• 遮挡剔除（Occlusion Culling），不可见的物体不渲染

我当时还在答案里写了“静态合批和动态合批的取舍”，因为静态合批会额外占用内存，动态合批对顶点数有要求。这种细节不是基础知识的堆砌，而是看你对渲染优化的理解有没有到项目层面。游戏客户端岗的面试官通常喜欢顺着这道题追问“UI的DrawCall怎么优化”“图片格式用ETC还是ASTC”，能把这条线串起来的人，笔试分数一般都不低。

5.3 资源加载与热更新

简答题里还出现过类似“游戏热更新方案对比”的题。2017年前后正是Lua热更和AssetBundle（AB包）方案混战的时期，所以这类题很有时代感，但底层思路到现在还在用。

答题时可以分三个维度：更新什么资源、怎么保证更新过程不断线、怎么减少下载体积。对应到技术上就是：资源版本号管理、增量更新、强更与弱更的选择。我提到的是“先下AB包再下Lua脚本，顺序不能反过来，因为脚本可能依赖新资源”，这种项目里踩坑总结出来的经验，比背书有用得多。如果你做过Unity项目，甚至可以画一个简单的资源加载流程图，笔试时用文字描述清楚也一样有效。

6. 答题节奏与手写代码：考场上的隐形分

很多在校生低估了“答题节奏”的重要性。吉比特这套卷子120分钟，题量不算变态，但陷阱不少——尤其是选择题和简答题之间，如果你时间分配不科学，很容易出现“编程题没写完、简答题只写一行”的惨状。

我给的策略是“三轮答题法”：

第一轮最重要的原则是：遇到不会的选择题，先凭第一印象选一个，标记出来，绝不停留超过1分钟。很多多选题是漏选扣分制，如果你没把握，宁可选少不要选多，这是考了无数场笔试总结出来的血泪经验。

编程题的答题顺序也有讲究。我习惯先做“数据解析”那道字符串题，因为它套路固定、边界明确，做完能快速建立信心；地图寻路用BFS也不难；状态设计题放到最后，因为它更开放、容易写偏。如果一上来就死磕状态设计题，后面时间可能就崩了。手写代码时，尽量把变量命名写清楚，哪怕没法运行，也要让阅卷人一眼看懂思路。我认识一位在游戏公司做过校招笔试阅卷的工程师朋友，他说批卷时最怕看到一大坨“a、b、c”变量名，就算逻辑对也很难给高分，因为“代码是给人读的，不是只给机器跑的”。

另外一个小技巧：编程题如果一时间没有完整思路，先写一个能过部分测试用例的暴力解法，并在注释里注明“此处可优化为XX算法”。这比留白强很多，因为笔试阅卷通常是按点给分，暴力解法能拿到基础分，优化方向说明能拿到一部分思路分。在“只能看纸质代码”的笔试模式下，把思路写出来本身就是一种能力展示。

7. 把笔试当情报站：考后复盘如何反哺后面的面试

笔试结束不是扔下笔就走，而是把卷子当成一次“技术情报收集”。我在复盘吉比特这套卷子时，最大的收获不是分数，而是通过题目反推了目标公司技术栈和项目方向。

举个例子：卷子里出现了大量帧同步、状态同步相关的题目，说明这家公司当时正在做或者准备做强实时性、强竞技性的游戏；出现了不少Unity和渲染优化相关题目，说明客户端岗位很可能以Unity为主。这些信息在后来的面试自我介绍时非常有用——你可以主动提“我了解你们在战斗同步上的技术选型，也研究过帧同步的一些注意点”，面试官很难不对你多一分好感。

具体复盘方法建议分三步：

第一步，整理错题和蒙对的题。蒙对的题比错题更有价值，因为那说明你的知识有盲区，只是运气好没被抓住。把每一道题逆向回溯到一个知识点，不要停留在“我会了这道题”，而是问自己“这道题背后的知识网络我还有哪里没打通”。

第二步，根据题目反推岗位技能树。吉比特这套卷基本覆盖了游戏服务端、客户端、引擎底层三个方向的基础知识。你面试的是客户端，那就重点补渲染管线和资源优化；面试的是服务端，那就深挖网络多线程和数据库设计。同一套试卷，不同岗位的复习重点完全可以不同。

第三步，把题目改造成面试问答。很多笔试选择题，面试时会被考官挖成“说下你对这个知识点的理解”。比如笔试考了TCP粘包，面试就可能让你手写一个拆包函数。所以复盘时要把选择题“为什么对”和“为什么错”都理清楚，不要只看答案。

最后说点个人体会。这套2017年的吉比特笔试试卷，放在今天看，算法题的难度并不算高，甚至比很多大厂的通用笔试要温和；但它的行业特色题和场景化编程题，恰恰是普通刷题训练很难覆盖的。它考的不是“你有多聪明”，而是“你有没有真的想过游戏是怎么做出来的”。

如果你正在准备游戏公司校招，我的建议是不要只刷LeetCode，花点时间去理解一套完整游戏项目的运行机制：客户端怎么渲染一帧画面，服务端怎么处理玩家并发操作，客户端和服务端怎么同步状态。这些东西不是一门课能教完的，但一套笔试卷会帮你把知识碎片串起来。这也是吉比特这套卷子留给我最大的启发——笔试不仅是筛选，更是一次关于游戏研发的系统性提示。