企业官网建设流程全解析

雷火每轮笔试通知发出来之后，准备室里最多的两个问题就是：第二批跟第一批是不是同一套题？我要不要去搜第一批的回忆版来刷？我的回答通常是：题大概率不会重复，但知识点范围几乎是锁死的，你真正该做的不是赌题，而是把雷火游戏研发这个岗位的技术栈底子摸透。这篇文章就按我自己的备考经验，把这类笔试的命题逻辑、章节重点、现场应对和考后复盘全部梳理一遍，希望能给准备下场的朋友一个可执行的参考。

先说说我为什么对雷火的笔试印象这么深。早几年我准备进游戏行业的时候，也刷过很多大厂笔试，发现一个现象：同样是考察算法，互联网后端笔试更偏爱“设计一个LRU”“实现一个线程池”这类贴近业务中间件的题，而到了雷火这边，题目往往会裹上一层游戏场景的外衣，比如寻路、碰撞、状态同步、对象管理。你以为在考算法，实际上它同时还在考你“能不能在游戏代码里用起来”。这个差异，就是准备阶段最大的方向标。

1.1 岗位定位：游戏研发工程师要的是什么样的人

网易互娱雷火事业群的产品线覆盖了大型MMO、多人竞技、开放世界等多个品类，这些项目对研发的要求不是“能写通一个LeetCode Medium”就够的，更看重几个底层能力：

• C++功底扎实，对内存布局、对象生命周期、虚函数机制有真实理解，而不是背概念。
• 算法能力可落地，树、图、搜索、动态规划这些基础结构能快速写对，并且理解它们在游戏系统里的映射。
• 具备实时系统意识，多人同屏、战斗同步、资源加载这些场景下，能意识到性能、延迟、内存开销的问题。
• 有游戏逻辑的体感，哪怕没做过完整游戏，也要能说出战斗逻辑框架、技能状态机、碰撞处理这些基本模块的常见做法。

笔试筛的就是这几项中的硬功底。因为面试官一天要面很多人，笔试成绩是简历之外最客观的第一道筛选。所以笔试内容通常不会出偏题怪题，而是把游戏研发日常真正用得到的知识点翻来覆去地考。

1.2 “第二批”到底意味着什么

同一招聘批次分成两批甚至多批笔试，最直接的原因是报名人数多、机位资源有限，需要分流。对候选人来说，分批意味着出题组会准备多套等价的试卷，题目不同，但考察的知识点和难度梯度基本对齐。所以如果你在等第二批，最聪明的做法不是到处找第一批的真题，而是按“同一知识地图、多题型变换”的思路来准备。

我见过有人为了搜回忆版题目熬夜到三点，结果考场上发现一道原题都没有，崩溃得影响心态。反过来，把时间花在梳理知识体系上的人，就算题型变了，照样能应对。

2. 知识点地图：五类必考模块的权重与典型出题手法

我自己备考时做了一张清单，把雷火这类游戏研发笔试的考点分成了五个模块。虽然批次不同、题目不同，但这张清单基本覆盖了所有可能出现的方向，这里直接分享出来。

这五个模块的权重不是我拍脑袋估的，是我结合自己笔试经历和后来带人复盘时总结出来的常见分布。后面几节分别展开说每个模块到底怎么考、怎么答才算答到点子上。

2.1 C++语言特性：不考语法，考你把对象当成内存看的能力

市面上很多笔试对C++的考察停留在“这个代码输出什么”的层面，但雷火这类游戏大厂会明显更进一步。它喜欢把几个知识点揉在一个选择题里，比如：

#include <iostream> using namespace std; class Base { public: virtual ~Base() { cout << "~Base()\n"; } }; class Derived : public Base { public: ~Derived() { cout << "~Derived()\n"; } }; int main() { Base* p = new Derived(); delete p; return 0; }

这道题看着简单，但背后同时考察了：虚析构函数为什么必要、new和delete配对、多态机制的实现逻辑。如果你只记住“基类析构函数要加virtual”这个结论，没想过它是因为delete基类指针时要通过虚表找到派生类析构函数，那么换一道关于虚表指针布局的题就会露馅。

所以我给备考者的建议是：C++部分不要只看语法书，至少要把《深度探索C++对象模型》里面关于对象布局的章节翻一遍，搞明白虚表指针存在对象内存的哪个位置、多重继承时虚表怎么组织、空类为什么占一个字节。这些是游戏研发日常排查崩溃问题时真正会用到的底层知识。

2.2 数据结构与算法：游戏逻辑的基本功，不能只会套模板

算法题是笔试的大头，也是区分度最高的部分。我观察近年来的出题趋势，纯背 LeetCode 答案已经不好使了，因为题目会改场景。举几个典型的包装方式：

• “玩家在地图上从A点到B点，中间有障碍物，求最短路径” —— 本质是 BFS / A*。
• “一份技能升级表，每个技能有前置技能和消耗点数，求最省点数方案” —— 本质是图论 / DP。
• “排行榜要实时维护前100名” —— 本质是堆 / 跳表 / 有序结构。

这就要求你不仅会写算法，还能识别题面背后的数据结构和算法模型。备考时最好刻意练习“读题拆模型”的能力：拿到一道题，先不急着写代码，先在草稿纸上标出这是树、图、区间、状态转移中的哪一类，再选对应解法。这个习惯在笔试限时环境下特别重要。

2.3 计算机基础：网络和操作系统的考察很实务

游戏研发绕不开网络同步和性能优化，所以笔试里关于TCP/UDP、多线程、内存管理的题目往往不是死记硬背，而是放在具体场景里。

比如问：“战斗服向客户端广播单位位置，选择TCP还是UDP，为什么？”这类题没有绝对标准答案，但面试官想看你能不能说出“TCP可靠但可能队头阻塞、UDP不可靠但延迟低，游戏位置同步通常用UDP或应用层自定义可靠协议”这一套逻辑。同理，多线程题目喜欢问“对象池为什么需要加锁、怎么设计一个无锁队列的心跳场景”，这都是在考察真实工程中会遇到的问题。

2.4 图形学与数学：不深入，但基础概念必须清晰

游戏研发不是每个岗位都做渲染引擎，但即便是玩法逻辑岗，也必须懂向量、矩阵和坐标系转换。原因很简单：玩家位置、朝向、技能范围、镜头跟随，这些全部离不开三维空间的数学表达。

常见的考察方向是：给一个点坐标，经过平移、旋转、缩放后求新坐标；或者判断两个AABB是否相交；或者给一个三维向量求归一化。这些题目不会很复杂，但要求你计算准确、表达清晰。备考时把线性代数的基础部分过一遍，尤其是矩阵乘法顺序、左右手坐标系、点积和叉积的几何意义，基本就能覆盖。

2.5 游戏系统设计：简答题是拉开差距的隐藏赛道

很多人忽略笔试里的简答题，觉得随便写两句就行。这个想法很危险。压线的候选人可能正好因为你简答题写得比别人有条理，就被捞进面试了。

游戏系统设计的简答题通常是开放性的，比如：如何设计一个技能系统？如何实现一个背包系统？如何做帧同步状态回滚？这类题没有唯一答案，但拿高分的关键是展现系统思维，而不是堆砌名词。

我在后面的章节专门用一整节讲这类题怎么答，先说结论：分层拆解、时序清晰、考虑边界。

3. 算法与数据结构真题拆解：按出题思路推演解题路径

算法题是笔试的主战场，也是复习时投入时间最多的一部分。这一节我挑了三个有代表性的题目类型，完整推演一遍解题路径，不是直接给答案，而是带着“出题人想考什么”的思路去拆。

3.1 链表与指针操作：不只写对，还要写出健壮性

链表题是笔试常客，因为它能同时考察指针操作、边界处理和递归/迭代两种思维。以最常见的单链表反转为例。

struct ListNode { int val; ListNode* next; ListNode(int x) : val(x), next(nullptr) {} }; ListNode* reverseList(ListNode* head) { ListNode* prev = nullptr; ListNode* cur = head; while (cur != nullptr) { ListNode* next = cur->next; cur->next = prev; prev = cur; cur = next; } return prev; }

这段代码的核心在于：必须先把cur->next存下来，再改动指针指向。很多人在笔试现场容易忽略这个顺序，导致链表断掉。出题人想要看到的不只是你能背出反转逻辑，而是你能在答完后主动检查空链表、单节点链表这两种边界情况。

我建议笔试时如果碰到链表题，写完代码后在注释里补一句边界处理，比如：

// 处理空链表或单节点的情况 if (head == nullptr || head->next == nullptr) return head;

这种细节在机评时未必算分，但在人工复看答题记录时，会给面试官留下“这个候选人工程习惯不错”的印象。

3.2 地图寻路与BFS：题面是游戏，模型是经典算法

雷火笔试里出现“最短路径”“能否到达”“最小步数”这一类题目时，大概率会包装成地图或棋盘场景。这个我建议直接用BFS的模板去套，因为BFS天然适合“等权重图求最短步数”。

举个例子，题目如果换成“二维网格中，1表示障碍物，0表示可通行，求从(0,0)到(m-1,n-1)的最短路径步数”，核心代码是这样的：

#include <queue> #include <vector> using namespace std; int minSteps(vector<vector<int>>& grid) { int m = grid.size(), n = grid[0].size(); if (grid[0][0] == 1 || grid[m-1][n-1] == 1) return -1; vector<int> dx = {-1, 1, 0, 0}; vector<int> dy = {0, 0, -1, 1}; queue<pair<int,int>> q; q.push({0, 0}); grid[0][0] = 1; int steps = 0; while (!q.empty()) { int sz = q.size(); while (sz--) { auto [x, y] = q.front(); q.pop(); if (x == m-1 && y == n-1) return steps; for (int i = 0; i < 4; ++i) { int nx = x + dx[i], ny = y + dy[i]; if (nx >= 0 && nx < m && ny >= 0 && ny < n && grid[nx][ny] == 0) { grid[nx][ny] = 1; q.push({nx, ny}); } } } ++steps; } return -1; }

这道题看起来不难，但很多人会在三个地方出错：一是没有把起点标记为已访问，导致重复入队；二是把步数更新放在层序遍历外，导致步数多加；三是边界条件没有先判断起终点不可通行的情况。如果你在笔试时能一次性避开这三个坑，代码的完成度就很高了。

更进一步，如果题目里怪物和玩家的移动速度不同、地形有消耗差异，这时候就要把BFS换成Dijkstra或A*，题面看着复杂，核心依然是“从状态空间中找最优解”。复习时把BFS、DFS、Dijkstra、A*这几个模型的关系理清楚，遇到新题才不会慌。

3.3 动态规划：从题目里找到状态和转移方程，而不是背模板

动态规划是让很多人头疼的部分，但游戏研发笔试里的DP题通常不会太变态，一般集中在背包、最长公共子序列、路径计数、状态压缩入门这几个方向。关键在于你能否快速定义状态，并验证转移方程是否正确。

以“机器人从左上角走到右下角，每次只能向右或向下，有多少条不同路径”为例，很多人知道要用二维DP，但有的会写错转移方向：

int uniquePaths(int m, int n) { vector<vector<int>> dp(m, vector<int>(n, 1)); for (int i = 1; i < m; ++i) for (int j = 1; j < n; ++j) dp[i][j] = dp[i-1][j] + dp[i][j-1]; return dp[m-1][n-1]; }

这道题的核心思考路径是：到达(i,j)只可能来自上方或左方，所以状态转移是dp[i][j] = dp[i-1][j] + dp[i][j-1]，初始边界全是1。如果你只是背模板，遇到“某些格子有障碍物”“某些格子有额外分值”就会卡住。所以在备考阶段，我建议大家每做一道DP题，都用纸笔把状态定义、初始条件、转移方程、遍历顺序四件事写清楚，而不是在OJ上直接提交了事。

3.4 位运算与数学思维题：小技巧能省出大时间

雷火笔试里通常会有两三道“小而巧”的选择题或编程题，考察位运算和数学思维。比如判断一个数是否是2的幂：

bool isPowerOfTwo(int n) { return n > 0 && (n & (n - 1)) == 0; }

这类题的底层逻辑是：2的幂的二进制表示中有且只有一个1，n & (n-1)的作用是把最低位的1消掉。我在笔试时见到这类题，通常先用几个特殊值验证一下：n=0、n=负数、n=INT_MIN，再决定要不要补边界判断。这个习惯帮我避免过好几次因为边界条件丢分。

4. 容易被忽略的C++与计算机基础硬核点：答题拿满分的细节

算法题是主战场，但真正决定你能否进面的，往往是那些看起来不显眼的选择题和简答题。这些题分值不高，但覆盖面广，而且错了就是错了，没有调试机会。我把自己见过的高频考点和易错点整理在一起，这部分如果能吃透，笔试的保底分会稳很多。

4.1 虚函数与对象内存布局：理解机制而不是背结论

C++笔试中关于虚函数的题，最常见的坑是把“虚函数”和“纯虚函数”“虚继承”“虚析构”混在一起考。我建议你把下面这组问题逐一想清楚，而不是只背“析构函数要加virtual”：

• 一个类有虚函数时，对象内存的头部会多一个虚表指针，占用多少字节取决于平台（64位下是8字节）。
• 多重继承时有多少个虚表指针？这决定了内存布局和sizeof的结果。
• 虚继承和虚函数底层用的机制完全不同，前者为了解决菱形继承的数据冗余，后者为了实现动态多态。
• 构造函数和析构函数中调用虚函数，会发生动态绑定吗？不会，因为构造/析构期间虚表指针可能还未初始化或已改变。

这些知识点不是靠刷题能解决的，得靠“画内存图”来理解。备考时我建议对每个涉及多态的代码片段，都手动画出对象的内存布局，标注虚表指针、成员变量、对齐填充分别放在哪里。画过三五张图之后，相关选择题基本不会错。

4.2 智能指针与对象生命周期：工程安全的底线

游戏研发的代码里，裸指针大量存在，但为了防泄漏和野指针，智能指针也频繁使用。笔试常考的题型包括：shared_ptr的引用计数怎么变化、weak_ptr如何解决循环引用、unique_ptr为什么不能复制只能移动、自定义删除器的应用场景。

我记忆很深的一道题是：两个对象互相持有shared_ptr，会发生什么？答案是引用计数永远无法降为0，导致内存泄漏。正确的做法是把其中一个换成weak_ptr。这种题在游戏客户端里对应的场景就是：场景管理器和角色对象互相引用，如果都用shared_ptr管理，场景销毁时角色永远释放不了。

还有个高频考点是移动语义。很多人知道move是强制转换，但不知道它真正的作用是把资源的所有权转移过去，避免深拷贝。笔试里可能会给你一个包含vector 成员变量的类，问哪个构造函数会被调用、发生了几次堆分配。答这种题要能数清楚临时对象的生命周期。

4.3 内存对齐与缓存友好性：老生常谈但必须会算

内存对齐几乎是必考题，因为它直接关系到sizeof运算符的结果。比如：

struct A { char a; int b; char c; };

在32位或64位平台上，sizeof(A)是多少？很多人凭感觉填9或12，实际答案是12。原因是int需要4字节对齐，所以a占了1字节后，有3字节填充，然后b占4字节，c占1字节，最后整个结构体对齐到4的倍数，又补了3字节。如果把成员顺序改成int b; char a; char c;，sizeof就变成8。这个例子说明，成员声明顺序会影响对象大小，也影响缓存命中率。在游戏服务器高吞吐场景下，把热字段放在同一缓存行是重要的优化手段，笔试考这个是有实际背景的。

我备考时练了不少这类题，发现一个快速方法：先找出最大对齐单位，再按顺序计算每个成员偏移量，最后整体对齐。多练几道，笔试时就是送分题。

4.4 网络与操作系统基础：锁、进程线程、TCP/UDP的高频考法

雷火的笔试里，网络和操作系统题目的比例不低，但出题风格偏应用。常见题型包括：

• 进程和线程的区别，线程序度优越性体现在哪。
• 死锁产生的四个必要条件，以及如何预防。
• TCP和UDP在游戏场景下的适用性，如何实现可靠UDP。
• 什么是乐观锁悲观锁，什么是自旋锁，什么场景下用自旋锁。
• 多线程访问共享数据时，为什么要用原子操作而不是直接加锁。

游戏服务器和客户端的开发中，锁和并发无处不在。但这类笔试题目并不会考到很深，关键是你能不能用一两句话把事情说清楚，而不是堆名词。所以我建议答题时采用“一句话结论 + 三行展开”的结构，既清晰又有深度。

4.5 程序改错与代码填空题的常见陷阱

除了选择和简答，雷火笔试偶尔会有代码改错题或程序填空题。这种题的套路比较固定，陷阱集中在：

• 悬空指针：delete之后没有置nullptr。
• 深浅拷贝：类中有指针成员时没有实现拷贝构造函数和赋值运算符。
• 数组越界：循环边界错一位。
• 整数溢出：int相加后赋值给int，没有考虑溢出。
• 循环变量生命周期：在循环内定义的对象作用域问题。

5. 笔试现场的时间分配与做题顺序：最高效的作答策略

笔试时间看似充裕，但如果你没有规划，很容易在某一两道题上耗到天荒地老。我见过太多人算法题卡四十分钟，结果后面简答题乱写，选择题没时间检查。下面是我验证过的一套时间预算和做题顺序，供你参考。

5.1 时间预算表

假设笔试总时长是120分钟，题量大概是：选择题20-30道，编程题2-3道，简答题1-2道。

这里的核心原则是：分数优先，先保稳再看难。不要把时间均匀分配，更不要在一道题上赌上全部。

5.2 做题顺序的几个实战套路

我自己的做题顺序是这样：先花5分钟快速把整张卷子扫一遍，标记出“一眼会”“有点思路”“完全不会”三档。然后按下面的顺序执行：

• 先做选择题里秒答的题，快速建立信心，顺便确认熟悉的考点没白复习。
• 再写最有把握的编程题，保证至少一道完整AC。
• 接着写简答题，因为简答题只要写了就有分，而且你的系统思维能让面试官眼前一亮。
• 最后攻坚剩下那道编程题。如果只剩15分钟，直接上暴力解或部分正确思路，哪怕是O(n²)也能拿部分分。
• 完全没思路的题果断放弃，把时间留给检查和改错。

有人会问：为什么不先做编程题再做选择？因为如果一上来就写算法题，又卡住了，很容易崩掉整场心态。先拿下20个会的，再挑战算法题，心理负担会小很多。

5.3 在线笔试环境最容易翻车的几个细节

笔试不是“代码写完就完事”，在线OJ环境的细节有时候能决定成败。我总结过几个常见坑：

• 输入输出格式：题目要求多组输入或单组输入，格式不同，否则样例通过率为0。
• 编译器版本：有些平台是C++14，有些是C++17，别用C++20的特性，比如std::format这种。
• 头文件：在线OJ推荐使用万能头文件#include <bits/stdc++.h>，但要注意部分平台不支持，稳妥做法是手动包含需要的头文件。
• 本地IDE vs 在线编辑器：本地调试好之后，粘贴到线上平台时容易丢行尾空格或缩进，提交前再检查一遍。
• 不要在线上平台做大量输入测试：平台通常对运行时间有限制，如果自己写了个死循环，卡到超时会影响心情。

这些细节看起来琐碎，但每年都有候选人因为“还差一个回车没输出”“题目要求多组输入自己却只处理了一次”而丢分。笔试前建议先花15分钟熟悉平台，把示例题跑通。

6. 笔试结束后的下一步：用复盘把机会变面试通行证

笔试交卷不是终点，而是所有动作的起点。很多人考完就放飞自我，直到收到面试通知才惊慌失措地准备。实际上，笔试到面试之间的时间窗口非常宝贵，这个阶段如果你能做一次高质量复盘，面试表现会有明显提升。

6.1 考后48小时内的复盘方法

笔试刚结束，记忆还新鲜，这时候建议立刻做三件事：

• 回忆并记录所有拿不准的题，按考点分类整理成清单。
• 把每一道编程题的思路在草稿纸上重新写一遍，标注出哪一步卡住了、后来自查时是怎么想通的。
• 记录每一道题花费的时间，找出时间黑洞。比如你发现自己在“最长回文子串”上耗了20分钟，说明这种题型熟练度不够。

我个人的经验是：笔试后的复盘清单就是面试前最精准的复习提纲。因为笔试和面试的考察范围高度重合，你笔试卡住的地方，很可能就是面试追问的地方。

6.2 把笔试经验转化为面试素材

笔试与面试不是割裂的。面试官能看到你的笔试答题记录，也可能直接问：“你笔试里那题怎么做的？当时为什么这么写？”这时候，如果你能清晰讲出当时的推导过程、遇到的坑、以及后来复盘时想到的优化方案，就会给面试官留下极强的正面印象。

所以笔试结束后，不要只关注“对了几道”，要主动围绕游戏研发岗位做一次项目包装。哪怕你还没有一段完整的游戏项目经历，也可以写一个小的Demo，比如：

• 一个基于SDL或Unity的小游戏原型，核心系统包括状态机、对象池、简易渲染。
• 一个A*寻路的命令行演示程序，包含障碍物随机生成和路径可视化。
• 一个简单的帧同步演示，两个客户端各自跑同一套确定性逻辑。

这些Demo不需要很炫，但面试时能讲清楚设计取舍，效果远胜于背一堆八股。我就见过一个候选人，笔试成绩中上游，但拿着一个自写的回合制战斗框架Demo，把状态机、命令模式、对象管理讲得头头是道，最后拿下了offer。笔试只是门票，真正帮你通关的是你在复盘后的深度理解。

6.3 简历和面试沟通中的几个加分动作

• 简历里的技能清单一栏，把C++放在前面，后面括号里写明熟悉STL、智能指针、内存管理、多线程。
• 项目经历里的每一条，都写清楚“我做了什么、遇到了什么问题、怎么解决的、收益是什么”，不要只写功能列表。
• 面试被问“你做过最有挑战的事情”时，优先挑能和游戏研发能力挂钩的经历，哪怕是非游戏项目，也要从中提炼出与游戏研发相关的底层能力。
• 被问“你的缺点”这类问题时，不要只说空话，可以讲一个你复盘后正在改进的具体技术细节，比如“我之前写代码不注重内存边界，笔试时吸取教训后，现在每段代码都会主动检查越界和空指针”。

这些动作不会让你从“完全不会”变成“面霸”，但能让面试官在有限的几十分钟里更快确认你的价值。

最后再说一个自己踩过的坑。我当年笔试时，在一道图论题上死磕了近四十分钟，最后代码没调通，后面简答题只能草草写完。那次笔试虽然也进了面试，但复盘时发现，如果当时先把简答题做掉，总分至少能多出一截。后来带人备考时，我总会反复强调时间分配，其实就是在补自己当年那个坑。笔试真正的筛选逻辑并不只是“谁能写出最难那道题”，而是“在同样的限时压力下，谁能稳定输出最多的有效分”。这个认知，比任何一道题的答案都重要。