每年的秋招补录季，总有一批同学被各种笔试题“教做人”，尤其是游戏大厂的C/C++岗位。搜狐畅游的这套2019校招笔试题，虽然年份早了点，但考题风格和难度放在今天依然很有参考价值——游戏开发工程师的笔试考什么、重点看什么，几乎都能从这套题里摸出脉络。
我当时补录阶段也做过这套题，说实话，难度不算变态，但覆盖面很广，语言细节、内存模型、算法基础都有涉及。而且它有一个很典型的特点：偏爱考“C/C++的差异点”和“底层内存行为”。如果只是把C++当“带类的C”来写，很多题会做得很别扭。这篇就把这套题背后真正想考察的点拆开揉碎，帮准备校招的你划一划重点。
这套题适合谁？主要两类人：一是正在准备游戏公司C/C++方向笔试的应届生，二是想系统查漏补缺的在校生。哪怕你暂时不投畅游，把里面的知识点吃透，对其他游戏大厂的笔试也有很大帮助。下面我按考点模块一个个拆解。
1. 语言基本功：C/C++差异点才是真正的考点
先说一个大方向：游戏公司笔试里C/C++题目，很少考“背语法”，而是喜欢考两个语言在底层行为上的差异，以及这些差异在实际工程里带来的影响。畅游这套题也不例外，不少题目表面上看是语法题，实际上是在考察你对“C++在C的基础上做了什么、为什么这么做”的理解。
1.1 为什么游戏开发如此执着于C/C++
聊考点之前，得先搞清楚一个底层逻辑：为什么游戏公司校招笔试要考C/C++，而且是深扣底层的那种考法。
游戏引擎（Unreal、Unity底层、自研引擎）基本都是C++写的，性能要求极高。渲染、物理、动画、粒子这些模块，每一帧要在几十毫秒内完成大量计算，编译型语言+手动内存管理带来的性能优势，是Java、Python这类语言替代不了的。尤其是移动端游戏，CPU和内存资源有限，一个内存泄漏、一次不必要的拷贝，都可能直接导致掉帧或者闪退。
所以游戏公司对C/C++岗位的候选人有个隐性的要求：必须理解代码在内存里长什么样。栈上还是堆上？生命周期多长？拷贝了几次？这些如果心里没数，写出来的代码到项目里大概率会埋雷。笔试就是在用题目筛掉那些“只会调API、不懂底层”的简历党。
1.2 高频差异考点速查表
结合这套题和多家游戏公司的笔试风格，我整理了下面几个“必考差异点”，每一组都要能说出个一二三来：
| 对比维度 | C | C++ | 游戏开发中的实际影响 |
|---|---|---|---|
| 内存管理 | malloc/free | new/delete、RAII | 手动管理易泄漏，C++用RAII降低风险 |
| 函数调用 | 函数指针 | 函数重载、虚函数、lambda | 多态让引擎架构可扩展，但虚函数有性能成本 |
| 类型转换 | 强转 | static_cast/dynamic_cast等 | 更安全，dynamic_cast有运行时开销，热路径慎用 |
| 默认参数 | 不支持 | 支持 | 提高接口灵活性 |
| 标准库 | 无 | STL容器/算法 | 高效开发，但要理解底层数据结构和迭代器失效问题 |
| 范式支持 | 面向过程 | 面向对象 + 泛型 + 函数式 | 游戏ECS架构中常用组合优于继承、数据驱动设计 |
这张表不是让你背，而是笔试里的选择题、改错题，很多都是围绕这些差异设计的。比如它可能会给你一段“看起来像C++实际上是C风格”的代码，让你判断哪里有问题。
1.3 对“c转c++”群体的特殊建议
热词里有个“c转c++”，这个背景在准备笔试时很有代表性。很多同学C语言底子不错，指针玩得溜，但一接触C++就习惯性地用它写C风格的代码——结构体满天飞、全局函数到处是、手动new/delete。这在笔试里很容易吃亏。
为什么？因为面试官从你的代码风格就能看出你“有没有C++思维”。比如**RAII（资源获取即初始化）**这个概念，C语言里没有对应的东西，但C++面试里反反复复会问。它的核心逻辑是：资源（内存、文件句柄、锁）在构造函数里获取，在析构函数里释放，利用栈对象的生命周期来自动管理资源，异常发生时也能保证析构函数执行。
我在实际项目中见过太多“C风格C++”代码导致的线上问题。最典型的就是：忘记delete、异常路径上资源不释放、裸指针到处传。C++11之后有了智能指针（unique_ptr/shared_ptr/weak_ptr），RAII的落地成本大大降低，笔试里手写一个简单的智能指针类也几乎是标配题。如果你还在用C的思维写C++，这一关过不去。
2. 笔试核心考点拆解：内存、多态与STL
这套题的主干考点，大概可以归纳成三块：内存模型、面向对象核心机制、STL的底层行为。每块都值得展开讲，因为它们对应的不只是笔试分数，更是后续技术面和实际开发的基石。
2.1 内存布局：栈、堆、全局区、常量区
C/C++程序的内存分区是必考内容，选择题、简答题都可能出现。标准划分是这样的：
- 栈区：由编译器自动分配释放，存放局部变量、函数参数。栈默认大小在Windows下通常是1MB左右，Linux下一般是8MB。递归过深、在栈上申请大数组，很容易栈溢出。
- 堆区：由程序员手动分配释放（new/malloc对应delete/free）。堆空间受限于系统可用内存，远大于栈。
- 全局区/静态区：存储全局变量和static变量，程序结束才释放。
- 常量区：存储字符串常量等，只读，修改会导致崩溃。
- 代码区：存放函数体的二进制代码。
笔试里常见的坑有哪些？我列几个真实案例：
第一，栈上放了大对象。比如一个包含int[1024*1024]的结构体，直接定义成局部变量，在某些平台直接爆栈。正确做法是分配在堆上，或者用std::vector管理。
第二，返回栈对象地址。函数返回局部变量的指针或引用，出了函数作用域，这块栈内存就被回收了，后续使用是未定义行为。编译器通常会给Warning，但笔试的代码题不一定开-Wall，自己得能看出来。
第三，内存重叠的memcpy问题。memcpy对重叠内存区域是未定义行为，应该用memmove。笔试里偶尔会埋伏这个点，考察你对库函数细节的熟悉程度。
2.2 指针和引用的本质区别
这是C++面试题里的“入门必问”，畅游的题里也出现过。如果要我一句话总结：指针是保存地址的变量，引用是变量的别名；指针可以为空，引用必须在定义时初始化且之后不能改绑定。
但笔试不会只考概念，它可能给你一段代码，让你判断输出或者指出编译错误。比如：
int a = 10; int &ref = a; int *ptr = &a; ref = 20; // a变成20 ptr = nullptr; // 只是指针变量不再指向a，a没变这里要清楚：对引用赋值，实际上是给被引用的变量赋值；对指针变量赋值，只是改变指针的指向。还有一个高频题：函数参数传值、传引用、传指针的区别。传值会拷贝一份，传引用和传指针不会拷贝（但指针本身有4/8字节拷贝），修改行为不同。在游戏开发里，大量对象传递时用const引用是性能关键——避免一次无谓的拷贝可能省下几毫秒，这在每帧逻辑里就是天壤之别。
2.3 多态的实现原理：虚函数与虚表
“C++多态怎么实现的？”几乎每家游戏公司技术面都会问，笔试里也会用代码题来考。核心就三点：虚函数、虚表（vtable）、虚指针（vptr）。
当你定义了一个含虚函数的类，编译器会为这个类生成一张虚函数表，表里存放的是虚函数的地址。每个对象内部会有一个隐藏的虚指针（vptr），指向所属类的虚表。调用虚函数时，通过vptr找到虚表，再从虚表里取出对应的函数指针来调用。这个过程叫动态绑定，运行时才确定调用哪个版本。代价是什么呢？一次间接寻址，以及虚函数通常无法内联——对性能敏感的游戏代码，这是要尽量避免在每帧逻辑里大量使用虚函数的原因之一。
笔试题目常见形式：基类指针指向派生类对象，调用虚函数/非虚函数，判断输出。我给你出一道典型的：
class Base { public: virtual void show() { cout << "Base" << endl; } void print() { cout << "Base print" << endl; } }; class Derived : public Base { public: virtual void show() override { cout << "Derived" << endl; } void print() { cout << "Derived print" << endl; } }; int main() { Base* p = new Derived(); p->show(); // 虚函数，动态绑定，输出 Derived p->print(); // 非虚函数，按指针类型绑定，输出 Base print delete p; }关键在于：非虚函数是编译期静态绑定的，编译器看的是指针的静态类型。而虚函数是运行期动态绑定，看的是对象的真实类型。这个题如果答错，基本等于告诉面试官“你C++多态还没入门”。
2.4 内存对齐：没听过真的会吃亏
内存对齐是C/C++笔试里很喜欢考的一个细节，因为它直接关系到结构体占多大内存。游戏里经常需要把数据打包进Buffer，内存对齐问题如果处理不好，轻则性能下降，重则直接崩溃。
规则看起来很简单但实际容易踩坑：每个成员按其对齐数对齐，结构体的总大小是最大对齐数的整数倍。对齐数一般是编译器默认值（如#pragma pack默认8字节）和成员自身大小的较小值。
举个例子：
struct Test { char a; // 1字节 int b; // 4字节 char c; // 1字节 };直觉上大小是6字节，实际在默认对齐下是12字节。为什么？a占1字节后，为了对齐b（4字节），要跳过3个字节填充；然后c占1字节，结构体总大小要对齐到最大对齐数4的整数倍，又得填充3个字节。所以2字节的数据，占用了12字节的存储空间，浪费了6字节。
怎么优化？按成员大小降序排列成员声明顺序，或者用#pragma pack调整。这在游戏引擎的序列化、网络同步数据包设计里特别关键——一个结构体多占的字节，乘以成千上万的实例，内存占用差距就出来了。如果你笔试时能主动提一嘴“这个结构体有内存对齐，sizeof不等于成员之和”，面试官的好感度会明显上升，因为它说明你真有过底层开发经验。
3. 常见笔试题型与解题思路：从读懂题目到交付满分代码
光掌握知识点还不够，你还得知道这些知识点在笔试题里是怎么被“包装”成题目的，以及用什么思路去解最快最稳。畅游这套题型的分布很有代表性，我按出现频率排个序：代码阅读与输出、改错题、算法题、设计/开放题。
3.1 代码阅读题：输出就是照妖镜
这类题最喜欢用继承、指针、生命周期组合拳。比如：定义了三个类，基类构造时调用虚函数，派生类里又有一个成员对象，问你main里new一个派生类后程序输出什么。
很多同学一看到“构造函数里调用虚函数”就迷糊。这里有个非常关键的坑：在构造函数或析构函数中调用虚函数，不会发生动态绑定。因为构造时对象的vptr是指向当前正在构造的这个类对应的虚表，子类部分还没构造完成，不能调用尚不存在的派生类版本。所以基类构造函数里调用的虚函数，调用的一定是基类自己的版本。
这种题目怎么练？我建议把《Effective C++》的条款09“绝不在构造和析构过程中调用虚函数”找来精读一下，笔试里这道题基本就稳了。
还有另一类常见题：对象生命周期与析构顺序。记住一个规律：构造顺序是“基类先于派生类、成员按声明顺序初始化、构造体执行”；析构顺序完全反过来：“派生类析构函数体先执行、成员按声明顺序逆序析构、基类最后析构”。这个顺序题也经常和虚析构函数一起考——如果基类析构函数不是虚函数，delete基类指针指向的派生类对象时，只会调用基类析构，派生类部分资源泄漏。这是一道经典的安全隐患题。
3.2 改错题：考的是项目里的真实代码味道
改错题比阅读题更贴近工程。给你一小段代码，里面埋着内存泄漏、空指针解引用、迭代器失效、混用new[]和delete等错误，要你找出来并改正。
以迭代器失效为例，这是STL题里的“钉子户”。看这段：
std::vector<int> v = {1, 2, 3, 4, 5}; for (auto it = v.begin(); it != v.end(); ++it) { if (*it % 2 == 0) { v.erase(it); // 错误：erase后it失效，再++是未定义行为 } }正确写法是：
for (auto it = v.begin(); it != v.end(); ) { if (*it % 2 == 0) { it = v.erase(it); // erase返回下一个有效的迭代器 } else { ++it; } }为什么vector的erase会导致迭代器失效？因为vector在删除元素后，需要把后续元素向前移动，整个存储空间不变，但被删位置后面的迭代器指向的元素已经变了；而且如果erase导致容量重分配，那就全废了。改这题的时候最好顺手写一句注释，说明“erase返回下一个有效迭代器”，体现你对容器底层实现的理解。
这种题目考察的就是你有没有写过多线程、写过项目里真实业务逻辑代码。平时自己写代码时多开- Wall -Wextra 编译选项，编译器报的Warning就是改错题的现成素材，遇到一个查一个，积累多了笔试题自然不在话下。
3.3 算法题：时间限制下的策略性取舍
游戏公司笔试的算法题，一般不会像LeetCode Hard那么变态，但也不会让你轻松AC。难度集中在Medium偏下到Medium之间。题目类型上，数组/字符串操作、链表反转/合并、二叉树的遍历与深度、DFS/BFS搜索、动态规划基础题出现频率最高。
这里我重点提醒一点：笔试的算法题，时间复杂度是最重要的评分标准。C/C++的运行速度比脚本语言快得多，但服务器判题机对时间限制依然很严格。热词里“时间限制: c/c++ 1000ms，其他语言 2000ms”就是个典型配置。C/C++只给1秒时限，意味着你的算法必须接近最优复杂度，O(n^2)的算法如果n到了10^5，1秒内基本跑不完。
举个例子，求最长不重复子串。朴素解法两重循环O(n^2)，n=10^5时代入n^2=10^10，即使每秒执行10^9次操作，也要10秒，直接超时。用滑动窗口+哈希表，O(n)，稳过。所以笔试答题前一定要先估算数据范围，不要看见字符串题就双循环，那是埋自己。
顺带说一嘴代码风格。笔试代码一般要手写完整个输入输出，不习惯的同学会在这里浪费大量时间。建议提前把常用的IO模式背下来，比如C++风格的：
#include <iostream> #include <string> #include <vector> using namespace std; int main() { ios::sync_with_stdio(false); cin.tie(nullptr); int T; cin >> T; while (T--) { string s; cin >> s; // 处理逻辑... } return 0; }关了流同步之后，cin/cout的效率能接近scanf/printf的水平，笔试时能省下不少时间。另外，如果题目对性能和内存很敏感，也可以用纯C风格的输入输出更稳妥。
3.4 设计/开放题：用工程经验拿下附加分
除了传统选择题和算法题，畅游这类游戏公司的笔试偶尔会加一两道设计类或开放类题目，比如“如何设计一个伤害计算系统”“多人在线游戏中的背包系统怎么设计”。这部分没有标准答案，但可以通过答案看出候选人有没有工程思维。
如果遇到这类题，我的建议是抓住三个关键词：数据驱动、组件化、可扩展。比如要设计一个技能系统，不要一上来就说“定义一个大Skill类，里面放伤害、冷却、特效、音效一堆字段”——那是最糟糕的答案。试着从数据驱动的角度回答：技能配置表存放所有技能的数值和表现参数，代码里用基类Skill + 不同行为组件组成，新技能只需新增配置和少量组件，不需要改动核心逻辑。
这种答题思路，不是临时抱佛脚能整出来的，靠的是平时写项目时多琢磨“如果产品需求变了，我这份代码要改哪里”。平时写课程设计或Demo时，养成这个思考习惯，笔试的开放题就能从容不少。
4. 从准备笔试到搭建环境：本地动手实践才是硬道理
知识点看得再多，不动手都是纸上谈兵。热词里频繁出现的vscode配置C/C++环境、MinGW-w64安装这些问题，看似基础，实际上把很多初次参加笔试的同学拦在了“想写代码但环境起不来”这一步。笔试前把本地环境彻底打通，绝对值得拿出半天时间专门搞定。
4.1 本地环境搭建：从MinGW-w64到VS Code
Windows下最通用的C/C++开发环境，组合就是VS Code + MinGW-w64 + GCC/G++编译器 + GDB调试器。VS Code本身只是个编辑器，所有编译和调试能力都依赖后边这些工具链，这一点务必理解。
MinGW-w64的安装有两条路。一是离线安装包，需要去SourceForge上找；二是在MSYS2里通过pacman安装。我推荐MSYS2这条路，因为后续安装其他库（CMake、Ninja、SDL等）也方便。装完后重点是把<MSYS2安装路径>\mingw64\bin加入系统PATH环境变量，否则VS Code怎么都找不到编译器。
验证是否装好，就在终端敲：
gcc --version g++ --version gdb --version三个都能输出版本号，说明工具链没问题。
然后是VS Code这边，装两个必备插件：C/C++（Microsoft官方出品，提供IntelliSense和调试支持）、Code Runner（方便快速编译运行单文件）。项目根目录下需要建.vscode/tasks.json（编译任务）和.vscode/launch.json（调试配置）。核心配置我就直接贴出来：
{ "version": "2.0.0", "tasks": [ { "label": "C++ Build", "type": "cppbuild", "command": "g++", "args": [ "-g", "-std=c++17", "-Wall", "-Wextra", "${file}", "-o", "${fileDirname}/${fileBasenameNoExtension}.exe" ], "group": "build", "problemMatcher": ["$gcc"] } ] }-std=c++17指定C++标准，如果笔试要求C++11就把数字改成11。-Wall -Wextra打开所有常见警告，这对帮你发现笔试题里埋的坑特别有效。写代码时看到Warning就顺手修复，时间长了写出来的代码别人挑不出刺。
调试配置launch.json也要准备好，笔试现场如果允许本地调试（有的在线编程环境不行），能单步看变量、看内存，很多逻辑错误当场就能抓出来。
4.2 调试工具到底有多重要：GDB和Visual Studio的选择
刚才提到的GDB是命令行调试器，通过VS Code的图形界面来用，对新手友好。但我想额外说一句：如果你准备长期走游戏开发，Visual Studio（Windows下）还是值得装的，尤其是它的“内存窗口”和“反汇编视图”。看C++对象在内存里的真实布局，比在脑子里空想vptr、内存对齐要直观得多。
怎么用？很简单，写一段有多态继承的代码，在调试器里给对象加监视，展开对象的成员，你会清清楚楚看到那个隐藏的vptr指针，再按照vptr去虚表里看函数地址。这一步看完，多态的抽象理解瞬间落地。
游戏公司里用Visual Studio的团队占绝对多数，调试器用得顺不顺直接影响开发效率。Unity的C#脚本栈和C++原生插件的崩溃转储，最后都是扔到Visual Studio里分析。笔试阶段先把VS Code练熟，入职后自然会切换过去。
4.3 笔试中的代码验证技巧
很多同学笔试时有个致命习惯：代码写完了，不输入任何测试用例就提交。这等于把到手的分数拱手让人。我建议至少留10分钟来跑自测用例。
本地跑代码时，怎么设计测试用例？三个维度：正常输入（确保主流程正确）、边界输入（空数组、n=1、最大值）、极端输入（数据量大的情况，用来验证会不会超时）。
比如一道数组题，如果你用C++写的，可以顺手在main里构造一个100000个元素的用例，用<chrono>库计时，跑了超过1秒就要考虑优化：
#include <chrono> auto start = std::chrono::high_resolution_clock::now(); // 调用要测试的函数 auto end = std::chrono::high_resolution_clock::now(); auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(end - start); cout << "耗时: " << duration.count() << "ms" << endl;这比什么“我猜应该能过”可靠得多。
4.4 笔试前两周的冲刺准备清单
最后整理一份冲刺清单，这是我带过不少学弟学妹后总结出来的版本，两周内按这个顺序过一遍，笔试当天的状态会完全不一样：
- 第一周（基础巩固）：把C++ Primer的“类、继承、虚函数、模板”四章再翻一遍；LeetCode按标签刷题，重点刷数组、字符串、链表、二叉树、DFS/BFS，一共刷30道左右，每题控制在30分钟内。
- 第二周（模拟演练）：找3~4套不同游戏公司往年的C/C++笔试题，严格按考试时间（90分钟）模拟；重点训练“先易后难，跳过卡壳题”的节奏；整理错题本，把反复出现的考点（内存对齐、虚函数、迭代器失效）一一记录。
- 考前1~2天：不再刷新题，只看错题本和速查表；检查本地环境和在线IDE账号都能正常登录；确认考场允许使用本地编译器还是必须在网页上写代码。
如果时间更紧，至少把STL里vector、map、unordered_map的底层实现原理和复杂度背清楚，它们是游戏开发中使用频率最高的容器。
5. 进阶视角：校招笔试题背后，游戏开发真实场景的映射
笔试不只是敲门砖，很多题目本质上就是游戏开发日常的缩影。能看透这层，你答题的深度会很不一样。
5.1 ECS架构与虚函数的博弈
前面提到虚函数有性能成本。那游戏行业到底怎么处理“多态”和“性能”的矛盾？现代游戏引擎越来越推崇ECS（Entity-Component-System）架构，核心思想是“组合优于继承”，把数据（Component）和行为（System）分离，而不是用深重的类继承树表达所有实体。
在ECS里，玩家、怪物、子弹都是一个Entity，本质上是一个ID；它们的数据由各种Component组合而成；逻辑则放在System里统一处理。这种架构下，虚函数的用武之地大大减少，取而代之的是函数指针、std::function、或者直接模板化。为什么要这么做？因为虚函数的间接跳转破坏了CPU分支预测，而且对象内存不连续，cache locality差，在成千上万个实体上做遍历更新时，性能差距非常明显。
笔试里可能不会直接问“什么是ECS”，但如果你在开放题里能提到“避免大量虚函数调用，可以采用数据驱动设计”，面试官会立刻意识到你平时是关注引擎架构的。这比堆砌名词有用得多。
5.2 对象池：为什么游戏引擎总是自己管内存
笔试里如果你能答出“频繁new/delete会产生内存碎片”，那只是及格。更进一步，游戏引擎通常会为特定类型维护对象池（Object Pool）：预先分配一大块内存，切成固定大小的槽位，对象创建时从池里取，销毁时还给池子。子弹、粒子、飘字这些高频创建销毁的对象都是对象池的典型应用。
这样做的核心原因是：避免频繁向操作系统申请和释放内存。系统调用是有代价的，而且大量小内存块反复分配释放，堆碎片化会越来越严重，最终可能导致“明明内存够用，但malloc找不到足够大的连续块”。
笔试题偶尔会让你实现一个简单的对象池，或者从内存碎片角度分析某段代码的隐患。答这类题时，除了说“使用对象池”，最好能画一两笔（不会有洁癖的面试官不喜欢画图的）说明块分配策略、空闲链表、内存对齐对齐处理。这就把单纯的概念题变成了加分题。
5.3 笔试答题的工程素养：从变量命名到代码注释
最后聊一个所有笔试题的通用加分项：代码风格。同一道题目，两个人答案的分数可能完全一样，但代码一眼看上去的观感差异巨大。
我的建议是：
- 变量命名必须语义清晰，
cnt、cur、nxt这种缩写可以，但a、b、c这种就别用了。 - 核心算法块加上两三行注释，说清楚思路。笔试阅卷不一定是真人逐行看的，但算法题的关键步骤有注释，很大概率会被判卷人识别为“高分段答案”。
- 不要写大函数，一段逻辑抽成一个子函数，每行不要超过100个字符。
- 避免使用奇技淫巧。比如三目运算符嵌套，或者在for循环里写连续赋值，这些写法在工程里都是可读性毒药，笔试时更没必要炫技。
我自己参加笔试时就有个切身体会：同样是AC的代码，有人只用35分钟写完并且注释清晰，有人卡在最后5分钟提交了一个没注释的版本，面试官拿到的参考完全不同。笔试不只是跟判题机对话，更是跟后来审你卷子的人对话。
写在最后
很多同学觉得校招笔试就是靠刷题，刷得越多分越高。我的体会是，刷题是必要条件，但不是充分条件。真正能让分数产生质变的，是你对“为什么这么考”的理解——为什么游戏公司要考虚函数、内存对齐、迭代器失效？因为这些都是你入职后每天都会遇到并影响线上产品质量的问题。
回到搜狐畅游这套2019年的题，它让我印象最深的地方在于：没有一道题是纯粹为了难为人。每一道题背后，都能找到游戏引擎或游戏逻辑里真实的映射。所以，准备这类笔试的时候，不要只盯着“答案”，多问一句“这题在游戏里对应什么场景”，你的复习效率和答题深度都会完全不一样。
如果你正准备即将到来的校招，这套思路可以立刻用起来。先把环境搭好，然后把基础考点过一遍，最后用几套往年题做模拟。考场上遇到不会的题也别慌，把能想到的步骤写出来，能拿一分是一分——说到底，笔试只是第一步，更重要的是让它成为你技术积累的一个起点。
