企业官网建设流程全解析

别把笔试当考试，它其实就是一次和主程的“技术对线”。很多人准备Unity3d游戏开发工程师岗位，把大量时间花在刷渲染管线和GPU Instancing上，结果一到笔试，居然栽在“值类型和引用类型的区别”这种题上，既可惜又典型。我自己也参与过不少游戏团队的招聘命题和简历筛选，发现Unity3d笔试真正筛掉的，不是基础差的人，而是那些“用过但没想过为什么”的人。这篇文章，我想把Unity3d游戏开发工程师笔试背后的出题逻辑、高频知识模块、经典真题的拆解思路，以及我自己的备考和踩坑经验一次性讲清楚，给准备入行或者打算跳槽的朋友做一个参考地图。

1. 先摸清底牌：Unity3d笔试到底在考什么

1.1 笔试角色的定位：不是难为你，是替面试官省时间

很多人对笔试有个误解，觉得笔试是公司故意设置的门槛，题目越偏越显得公司有水平。其实站在用人方的角度看，笔试的作用非常朴素：在短时间内过滤掉明显不合适的候选人。一个Unity3d游戏开发岗位，一天可能收到上百份简历，项目经历写得天花乱坠，但实际动手能力如何，没办法靠简历判断。笔试就是成本最低的“技术体检”。

所以你会发现，Unity3d笔试题目往往不是偏题怪题，而是“基础中的基础”。它考察的核心就三件事：C#语言功底扎不扎实、Unity引擎机制理解得到不到位、遇到问题有没有清晰的解决思路。至于渲染算法、图形学数学推导这些，反而很少在初级岗位的笔试里出现，因为那些东西面试官知道你工作之后会用到再说，笔试阶段他更想确认你有没有写代码的“常识”。

我见过一个挺有意思的案例：某候选人简历上写了三年Unity开发经验，结果笔试题第一题“请说明FixedUpdate和Update的区别”，他答得模棱两可。这种题不会直接淘汰，但会让面试官在心里打一个问号——三年的经验，是不是都在用别人的框架？笔试的题目设计，本质上就是在帮你“自证”简历上的话。

1.2 高频考察模块与出题套路

结合我自己经历过的笔试和看过的题库，Unity3d游戏开发工程师笔试的知识点分布其实是相对固定的，可以分成五个大的模块。我按出现频率和权重排了个序，你参考一下：

从这里能看出一件很重要的事：数据结构与算法和C#基础加起来占了将近一半的比重。很多自学者容易陷入一个误区，整天研究Shader和URP管线，反而忽略了最核心的语言功底。但用人单位的逻辑很简单——引擎功能可以入职后学，编程思维和语言基础才是决定你能走多远的关键，所以笔试必然会在这些地方做重点筛选。

出题套路方面也有规律。选择题考概念辨析，比如“以下哪个是引用类型”“Vector3的默认值是什么”；简答题考机制理解，比如“请简述协程的执行原理”“物体碰撞后如何获取碰撞点信息”；手写代码题则高度集中在几个固定场景：移动控制、对象池、单例模板、列表去重排序、简单的状态切换。看到这里你应该明白了，笔试并没有想象中那么神秘，它是有明确范围和套路的。

2. C#语言基础：笔试里最“阴”的部分

2.1 值类型与引用类型：一道题看出你的内功

C#基础在Unity笔试里出现的频率极高，而值类型与引用类型又是其中最经典的考点，几乎每次笔试都会碰到。这个知识点之所以被反复考察，是因为它背后牵扯的东西太多了：内存分配位置、赋值行为、函数传参、装箱拆箱、GC压力……一个点没搞懂，连锁反应就是一片。

先说概念。值类型包括所有内置数值类型（int、float、double、bool）、struct、enum，它们存储在栈上，赋值时是“复制一份”。引用类型包括class、interface、数组、string、委托等，它们存储在堆上，变量本身保存的是对象的引用地址，赋值时是“让两个变量指向同一个对象”。这个区别看起来简单，但笔试经常用“交换两个数”这种题来挖坑。

我印象很深的一道题是：写一个Swap函数，交换两个int变量。用值传递写一遍，再用ref关键字写一遍，说出区别。很多人第一反应是“这不很简单吗”，但真动手写的时候才发现，值传递那个版本交换完，主函数里的变量压根没变。这就是典型的“以为会了，其实没会”。

再看装箱和拆箱。值类型转换成object或接口类型时会发生装箱，反之则是拆箱。笔试题通常这样出：以下代码产生了多少次装箱？别小看这个问题，它能顺带考察你对GC的理解。每次装箱都会在堆上分配一块新内存，频繁装箱必然导致GC压力增大。在游戏里，如果Update里每帧都做装箱操作，Memory Profiler里会看到一堆垃圾内存。

2.2 委托、事件与Lambda：闭包陷阱最爱藏在这里

委托和事件是C#笔试的另一个重灾区。Unity里到处是委托的影子，Button的onClick、协程的yield return、事件系统……这些都和委托息息相关。笔试常考的无非这么几种：委托的声明和调用、多播委托的执行顺序、事件和委托的区别、Lambda表达式捕获外部变量的坑。

先说最简单也最常考的一个点：多播委托的返回值问题。如果用+=给一个委托挂多个方法，并且委托有返回值，那么最后返回的只有最后一个方法的返回值，前面方法的返回值会被丢弃。这个知识点在选择题里特别常见，选项就四个返回值，让你判断最终输出。知道的人一秒选完，不知道的人就会在这里卡半天。

事件和委托的区别，笔试标准答案是“事件是委托的封装，外部只能通过+=和-=来订阅和取消订阅，不能直接调用”。但实操中还有个更隐蔽的坑：在类外部直接调用事件。如果你把事件定义成public，然后在别的类里用instance.MyEvent()这样的方式去触发它，编译器会直接报错。这其实是事件的保护机制在起作用，但很多人没意识到这正是它和委托的本质差异。

Lambda捕获外部变量这个坑，笔试里爱用循环体来出题。经典题目是：for循环里用Lambda给五个Button注册点击事件，点击后输出i的值，问输出是多少？答案是五个按钮全输出5。因为Lambda捕获的是变量i本身，而不是某个时刻的“值”，循环结束时i已经变成5了。这个坑在真实项目里也很常见，修起来容易，但在笔试环境下写出正确答案，说明你对闭包的原理真懂。

2.3 字符串拼接与StringBuilder：还债的典型代表

字符串只要是C#笔试就绕不开，因为它太容易产生GC了。题目一般是这样：以下代码会产生多少个字符串对象？string s = "a" + 1 + "b" + 2;这里不仅有字符串拼接，还有int到string的类型转换，每一步都可能产生新的对象。

正确的认知是：string是引用类型，但具有不可变性。每次修改字符串，实际上是在堆上重新创建一个新的字符串对象，旧的就会被GC回收。所以循环里做大量字符串拼接，性能会非常难看。笔试里如果让你“说说如何优化字符串拼接性能”，正确答案就是StringBuilder。

但注意，StringBuilder也不是万能灵药。它内部维护一个字符数组，当字符串长度超过当前容量时，会重新分配一块更大的数组并把旧数据复制过去，这本身也有开销。所以更优的做法是构造StringBuilder时预估一个合适的初始容量。这个细节笔试不一定考，但你在简答题里主动写出来，绝对是个加分项。

3. Unity引擎核心机制：理解原理才能答到点子上

3.1 脚本生命周期与执行顺序：必背，但更要理解

Unity脚本生命周期是所有Unity笔试的“必考送分题”，但如果只背顺序不理解原因，万一题目换个方式出，你就麻了。完整顺序是：Awake、OnEnable、Start、FixedUpdate、Update、LateUpdate、OnDisable、OnDestroy。

笔试最常考的比较是Update和FixedUpdate。标准答案是：Update每帧调用，帧率越高调用越频繁；FixedUpdate按固定时间间隔调用，默认0.02秒一次，和帧率无关。但为什么物理计算要放在FixedUpdate而不是Update里？因为物理模拟需要稳定的时间步长，如果放在Update里，帧率波动会导致物理表现忽快忽慢。这个“为什么”才是面试官真正想听的内容，你只背结论，一旦被追问原理就容易露馅。

Awake和Start的区别也是高频题。Awake在对象被实例化时立即调用，即使脚本组件被禁用也会执行，适合做组件缓存和初始化；Start在脚本第一次启用前调用，适合做依赖其他组件的数据初始化。笔试爱出的坑是：如果一个物体上挂了两个脚本，Awake和Start的执行顺序是怎样的？答案是——所有脚本的Awake都会在任意一个Start之前执行完。Unity这么做是为了保证初始化顺序的确定性，避免某个Start里访问的组件还没初始化。

还有一道我特别喜欢用来考人的题：OnEnable和OnDisable。很多人不知道这两个方法在对象激活状态切换时会反复触发，而且OnEnable在Awake之后、Start之前执行。如果你在OnEnable里做了事件注册，就必须在OnDisable里做反注册，否则对象被销毁后委托仍然持有引用，会造成内存泄漏。这个知识点笔试不一定直接考，但排查问题的时候用得特别多。

3.2 协程：看似简单，实则坑不少

协程几乎是Unity笔试的“钉子户”。常考形式有：协程的返回值类型是什么？yield return null和yield return WaitForSeconds有什么区别？协程和线程的区别是什么？

先答最基本的：协程的返回值类型是IEnumerator，用yield return来暂停执行，等条件满足后再继续。很多人以为协程是多线程，这是最大的误解。协程跑在主线程上，它只是C#迭代器机制和Unity引擎配合实现的一种“伪异步”效果。当你yield return null的时候，Unity会在下一帧继续执行这个方法。协程适合做延时任务、序列动画，但不适合做耗时运算，因为一旦你在协程里做大量计算，该卡还是卡。

笔试里有个经典坑：StopAllCoroutines并不能停止所有协程。准确说它只能停止“当前MonoBehaviour上启动的、还存活着的协程”，如果你在别的组件上调用了协程，或者协程内部又启动了其他协程，StopAllCoroutines管不到。还有个更隐蔽的坑：协程如果yield return的是一个其他组件的协程对象，它的执行时序会变得非常复杂，笔试题偶尔会用这个来出判断题。

3.3 物理体系与碰撞检测：不只是OnCollisionEnter

Unity物理部分的笔试题目通常集中在三个方面：刚体（Rigidbody）、碰撞器（Collider）、触发器（Trigger）。核心概念不难，但考察方式很灵活。

先说碰撞的三个条件：两个物体都得有Collider，至少一个物体有Rigidbody，并且运动的物体要有Rigidbody。笔试常考判断题：一个静态物体（只有Collider）和一个运动物体（Collider+Rigidbody）碰撞，OnCollisionEnter会触发几次？答案是一次，但很多人会答两次。原因在于，碰撞回调是挂在“发生碰撞的物体”上的，每个物体各收到一次属于自己的回调。笔试如果问“如何获取碰撞点信息”，用Collision.contacts[0].point，这个也是高频考点。

触发器（IsTrigger）则是另一个经典考点。勾选IsTrigger后，物理碰撞不会发生，但会触发OnTriggerEnter/OnTriggerStay/OnTriggerExit。笔试题经常这样出：一个角色走进一个区域，如何判断他进入了？答案就是用触发器。要理解的是，触发器没有物理阻挡效果，它只是一个“感应区域”，适合做伤害区域、任务触发点、拾取判定。

还有一个笔试常客是射线检测（Raycast）。Physics.Raycast的常用重载、LayerMask的用途、以及为什么在2D游戏里要用Physics2D.Raycast而不是Physics.Raycast。其中LayerMask是高频中的高频，因为它牵扯到性能和过滤问题。合理使用LayerMask可以避免不必要的射线检测，这是项目优化的基础手段。笔试问你“如何只检测玩家层”，答案是用LayerMask.GetMask("Player")。

3.4 坐标空间与Transform：笔试里的数学题

Unity开发离不开坐标系。笔试中关于Vector3和Transform的题目，主要考察两类：一类是向量运算，另一类是坐标空间转换。

向量运算里，Vector3.Dot（点乘）和Vector3.Cross（叉乘）是常客。点乘判断两个向量的方向关系：结果大于0说明夹角小于90度，等于0说明垂直，小于0说明夹角大于90度。叉乘的结果向量垂直于两个原向量构成的平面，方向由左手定则决定。笔试的实际应用场景通常是：判断一个物体是否在另一个物体的前方。答案是Vector3.Dot(forward, targetDir)，大于0就在前方。

坐标空间转换的经典题是：如何把世界坐标转换成屏幕坐标？答案是Camera.main.WorldToScreenPoint。反过来则是ScreenToWorldPoint。笔试还可能问“TransformPoint和TransformDirection的区别”，前者同时处理位置和旋转缩放，后者只处理方向。这些API名称看着相似，但用错场景会出很诡异的问题，笔试出这种题考的就是你对API细节的敏感度。

4. 数据结构和算法：从游戏场景里抽象出来的硬功夫

4.1 高频数据结构：数组、链表、字典怎么选

数据结构在Unity笔试里不是以纯理论形式出现的，而是揉在游戏场景里。比如背包系统用什么数据结构？NPC列表用什么？按键映射用什么？这类题目没有绝对标准答案，但需要你讲出选择的理由。

背包系统首推List或数组，因为它的核心操作是“遍历显示”和“按索引访问”，这两点恰好是数组的强项。如果背包格子固定，直接用数组；如果支持动态扩容，用List。而道具ID和道具实例之间的映射关系，则用Dictionary，因为它的增删改查都是O(1)时间复杂度。

Unity笔试特别喜欢考Dictionary和List的性能对比。选择题里经常出现：在10000个元素里查找一个值，用List和Dictionary哪个更快？答案是Dictionary。原因是Dictionary内部用哈希表实现，查找时间复杂度是O(1)，List是线性查找O(n)。但反过来，如果要频繁遍历且元素数量不大，List的开销更小，因为Dictionary的哈希计算也有成本。数据结构没有绝对好坏，只有合不合适。

另外一个笔试高频题是“如何对List去重且保持原顺序”。这个需求在游戏里非常常见，比如任务列表的去重。最优解法是用HashSet辅助，遍历一遍List，如果HashSet里没有就加入结果集，同时把元素加入HashSet。时间复杂度O(n)，代码也简洁。用Linq的Distinct也行，但底层实现其实也是哈希表，性能差别不大。

4.2 经典算法：排序、查找、递归一个都别落下

排序算法在Unity笔试里出现的频率不如互联网公司高，但一旦出现就是两种考法：要么考冒泡排序或快速排序的手写，要么考“什么时候用什么排序”的判断题。

手写排序，我强烈建议你把冒泡排序和快速排序背得滚瓜烂熟，尤其是快速排序的分区思想（选取基准、左右指针、递归处理）。因为笔试手写代码环境通常没有自动补全，一旦紧张很容易写乱。快速排序的平均时间复杂度O(nlogn)，最坏情况是O(n²)，当数据基本有序时性能反而差，这时候插入排序反而更快。这些细节判断题也爱考。

查找算法里，二分查找是必须掌握的。笔试常考的场景题是：在一个有序数组中找到指定元素的索引，如何高效实现？答案就是二分查找。代码本身不难，但有个细节值得注意：中间值的计算要用low + (high - low) / 2，而不是(low + high) / 2，因为后者在极端情况下会溢出。这个细节在笔试改卷时是个明显的区分点。

递归在Unity里最常见的应用场景是树的遍历，比如技能树、UI层级树。笔试如果出“如何遍历一个UI父节点下的所有子节点”，用递归写一个深度优先遍历就能过。但递归的缺点也要清楚：每次递归调用会占用栈空间，层级过深容易出现堆栈溢出，所以实际项目中如果知道层级不会很深才用递归，否则就用显式栈加循环。

4.3 寻路算法：至少要知道A*的思路

寻路算法是游戏开发特有的笔试考点，而且偏向于“聊思路”而不是“写代码”。就算笔试不要求你现场写A*，你也要能解释清楚它的核心原理。

A*的核心是一个估值函数：f(n) = g(n) + h(n)。其中g(n)是从起点到当前节点的实际代价，h(n)是从当前节点到终点的估算代价。算法维护两个集合：openList（待考察的节点）和closeList（已考察的节点）。每次从openList里取出f值最小的节点，扩展它的邻居，更新g值和父节点，直到终点被加入closeList。

笔试里更常考的是A和Dijkstra的区别。标准答案是：**Dijkstra只考虑g值，没有启发式函数，所以能找到最短路径但效率低；A在Dijkstra的基础上加了启发式函数h(n)，搜索更有方向性，效率更高**。还有个细节题：如果h(n)恒等于0，A*就退化成Dijkstra。这些回答能体现你是“真懂”而不是“背了个概念”。

5. 典型笔试实操题：从题干到满分作答

5.1 移动控制题：考察Transform与DeltaTime

移动控制是Unity笔试手写代码题里最经典的题目，没有之一。题目通常这样出：写一个脚本，让物体用WASD控制前后左右移动，并且移动速度不受帧率影响。

标准答案其实很简单，核心就两点：用Input.GetAxis读取输入，用transform.Translate移动，方向乘以Time.deltaTime。但为什么乘以deltaTime才是关键，这个之前已经说过了——因为Update的调用频率和帧率挂钩，不乘deltaTime，高帧率电脑上物体飞快，低帧率电脑上物体爬行。

完整的参考代码大致长这样：

using UnityEngine; public class PlayerMove : MonoBehaviour { public float moveSpeed = 5f; void Update() { float horizontal = Input.GetAxis("Horizontal"); float vertical = Input.GetAxis("Vertical"); Vector3 moveDir = new Vector3(horizontal, 0, vertical).normalized; transform.Translate(moveDir * moveSpeed * Time.deltaTime, Space.World); } }

这个代码能拿基础分，但要拿高分，你还可以补充几个细节。第一，Space.World还是不传，默认是Space.Self，如果物体有父节点且父节点有旋转，两者的移动方向就不一样，所以最好明确写出来。第二，如果物体是刚体控制的，正确做法是修改Rigidbody.velocity或调用AddForce，而不是直接动Transform，因为物理引擎有自己的模拟节奏。

5.2 对象池实现：考察工程能力和性能意识

对象池是Unity笔试中出现频率极高的设计题，因为它直接考查你有没有性能优化意识。题目一般这样出：请设计一个简单的对象池，用于处理子弹/敌人的频繁生成和销毁。

对象池的核心思想是“复用对象，避免频繁实例化和销毁”。实例化和销毁会产生GC，在游戏里表现为卡顿，所以用池子把用过的对象暂存起来，下次需要时直接激活复用。

思路是：先创建一个空物体当池子容器，初始预生成N个对象，用Queue存储未使用的对象；Get方法从队列头部取对象，取不到就新实例化一个；Recycle方法把对象放回队列，并SetActive(false)。

using System.Collections.Generic; using UnityEngine; public class ObjectPool : MonoBehaviour { public GameObject prefab; public int preloadCount = 20; private Queue<GameObject> pool = new Queue<GameObject>(); void Start() { for (int i = 0; i < preloadCount; i++) { GameObject obj = Instantiate(prefab, transform); obj.SetActive(false); pool.Enqueue(obj); } } public GameObject Get(Vector3 position, Quaternion rotation) { GameObject obj = pool.Count > 0 ? pool.Dequeue() : Instantiate(prefab, transform); obj.transform.position = position; obj.transform.rotation = rotation; obj.SetActive(true); return obj; } public void Recycle(GameObject obj) { obj.SetActive(false); pool.Enqueue(obj); } }

这段代码在笔试里已经算中上水平了。但有一个高频追问：为什么用Queue而不是List或者Stack？答案是Queue是先进先出，拿出的对象都是“等待时间最久”的，理论上更不容易被频繁激活和禁用；Stack反而容易反复操作同一个对象。这个细节在笔试中写出来，能体现出你思考过数据结构的选型。

5.3 生命周期与协程的判断题：考的就是你的认真程度

最后这类题没什么技术难度，考的就是你平时有没有认真看官方文档。常见判断题如下：

第一题：一个物体上挂两个脚本A和B，A的Awake里访问B组件，B的Awake里访问A组件，代码会报错吗？答案是不会。因为Unity保证所有脚本的Awake在Start之前执行完，但不会保证Awake之间的执行顺序，所以A在Awake里可以安全地获取B组件，只是不能保证B已经初始化了。

第二题：在Update里调用StartCoroutine，协程一定会下一帧才执行吗？答案是取决于yield return的内容。如果你yield return null，下一帧继续；如果你yield return new WaitForSeconds(1)，一秒钟后继续。但如果你在协程里没有yield return任何东西，它会一直执行到第一次yield之前。这个细节笔试经常出选择题，答案是“立即执行到第一个yield”。

第三题：一个物体被SetActive(false)后，上面的协程还会继续执行吗？答案是会暂停，但不会销毁。等SetActive(true)后，协程会从暂停处继续。这个知识点很多人不知道，因为协程和MonoBehaviour生命周期是绑定的，但激活状态的变化并不会自动停止协程。如果想彻底停止协程，只有两种方式：调用StopCoroutine或销毁物体。

这三道题别看简单，在真实笔试中，能全答对的人比例其实不高。它们考察的不是记忆力，而是你有没有在实际开发中遇到过并自己验证过。

6. 备考路线与现场应战心得

6.1 两周冲刺计划：笔试前怎么做最有效

如果你准备时间比较紧张，我给一个可按天执行的冲刺计划。它的核心思路是：先补基础，再刷高频题，最后做自测，避免到处找资料把自己淹没。

第一周前两天，集中过C#基础。找一本C#入门书或者网上的教程，重点看值类型引用类型、委托事件、字符串、集合类、泛型这几章。目标是合上书能默写一个简单的泛型委托，能在纸上画出值类型和引用类型在内存里的分布图。

第一周中间三天，过Unity核心机制。重点是生命周期、协程、物理系统、UGUI的常用组件。可以自己开一个空工程，把生命周期方法的Debug.Log全都打印一遍，亲眼看执行顺序。这个过程花不了多少时间，但效果远超死记硬背。

第一周最后两天，刷算法和设计模式。不用刷LeetCode那种偏ACM的题，重点刷数组操作、字符串处理、简单查找排序。设计模式重点理解单例、对象池、观察者、状态模式在游戏里的落地方式。每个模式想一个游戏里的应用场景，比如状态模式用于角色动画切换，观察者用于成就系统。

第二周进入刷题模式。找2-3套Unity笔试题，严格计时做完，再对照答案复盘。刷题的目的不是为了押中题，而是培养“在规定时间内写出整洁代码”的肌肉记忆。笔试现场写代码是有时间压力的，如果你平时习惯了IDE的自动补全，纸上写代码的手感会很生疏，提前练很有必要。

最后留两天做“模拟面试”：让朋友随机问上面的知识点，你用口述方式回答。这一步能帮你查漏补缺，还能提前适应面试的表达节奏。

6.2 现场答题的几个实战技巧

笔试现场有些技巧，是刷题刷不出来的，但直接影响成绩。

第一，先通读全卷再动手。拿到题目先花两分钟把所有题看一遍，标出自己会的题和拿不准的题。先做会的，稳定拿分，再回来啃难题，避免在不会的题上死磕导致会做的题没时间写。

第二，手写代码题，先写注释再写代码。哪怕题目没有要求，也可以在代码前面用注释写一下思路。这有两个好处：一是帮自己理清逻辑，二是让改卷的人看到你的思考过程。如果代码写错了但思路对，也能拿到步骤分。

第三，不会的简答题，不要空着。把自己能想到的相关知识点都写上，最好能和问题挂上钩。比如问“如何优化加载速度”，就算你不知道AssetBundle的细节，也可以从“异步加载、分批加载、对象池复用”这些角度回答，都能得分。空着是零分，写了至少有机会。

第四，代码格式要工整。笔试手写代码时，花括号对齐、变量命名规范、缩进清晰，这些都是加分项。改卷人一天看几十份卷子，卷面工整的会下意识给更高的评价。这在程序员的评分标准里虽然不写在纸面上，但确实存在。

6.3 那些笔试之后才明白的经验教训

最后分享几个我自己在招聘和备考过程中总结出来的教训。

第一个教训是：别在简历上写“精通”，但笔试一定要展示“严谨”。我见过太多简历写了“熟悉C#”，结果笔试题里连using System都没写全的人。笔试成绩是简历的照妖镜，与其在简历上堆砌形容词，不如在笔试里把基础题答完美。

第二个教训是：复盘比刷题重要。很多人笔试结束就扔一边，只看个对错，不去深究为什么错。我在带新人时发现，那些成长快的人，都有一个习惯：错题一定会弄懂背后的原理，然后自己动手验证一遍。这个习惯在笔试备考里也一样重要，一道错题复盘透了，比你刷十道新题都有用。

第三个教训是：笔试通过只是起点，面试还会继续深挖你的笔试答案。很多公司在面试环节会让候选人讲解笔试的解题思路，尤其是手写代码题。所以你在笔试时写下的每一行代码，都要能讲清楚“为什么这么写”。这看起来要求很高，但反过来也提醒你——答题时不要背模板，要靠理解去写。只有理解到位，才能经得起追问。

Unity3d游戏开发工程师的笔试，本质上是把你的知识体系拆开给面试官看一遍。它考察的范围并不算广，但深度要求不低。这篇文章里列出的知识点和题目，是我觉得大家准备笔试时绕不开的主干，也是我实际招聘中验证过的重点。最后再分享一个小建议：准备笔试的过程中，一定要自己动手写代码验证，哪怕是最简单的一句Debug.Log。很多问题，只有你亲手跑过一遍，才算是真懂了。希望你笔试顺利，拿到心仪的Offer。