1. 先弄懂游戏循环：Unity的帧到底是怎么转起来的
1.1 游戏循环的由来：为什么Unity不按顺序把代码跑完
很多人在学Unity之前写过控制台程序或者Web程序，脑子里形成的固有印象是：代码从入口函数开始，一行一行往下执行，执行完就结束。但游戏完全不是这样。游戏程序从启动那一刻起，就处于一个永不退出的循环里——每秒钟这个循环要跑几十上百遍，每一遍就是一帧。这个循环就是游戏循环（Game Loop)。
Unity的游戏循环是引擎内置的，不需要你写，也不需要你管，但是你必须理解它。因为你的所有脚本逻辑，都是被这个循环切碎之后"按帧"调用的。你不是在写一个顺序流程，而是在写一堆挂在不同"触发点"上的回调函数。
用一个生活化的比喻来理解：传统程序像是做一道菜，备菜、下锅、装盘，做完就结束；游戏程序更像是开餐厅，从开门到打烊，一直在重复"接客、点菜、上菜、收桌"这套流程，每一桌客人就是一帧。Unity引擎不会因为你没写循环代码就停下来，它自己会一直转，你的脚本只是被它当成"某个环节的临时工"在调用。
理解了这个前提，再回头看那些所谓的"运行原理"问题，很多疑惑都会解开。比如为什么两个脚本之间传递数据有时候会拿到空值，为什么同一个物体改了位置画面却不跟着变，为什么物理和渲染经常对不上——本质上都是因为你还没在脑中建立"每一帧做了什么、以什么顺序做"的模型。
1.2 Unity一帧里的完整流程，从输入到渲染
Unity官方文档会把一帧拆成几个主要阶段，在Profiler里能看得非常清楚。很多新手打开Profiler被满屏的模块名吓住，其实只要抓住主干就行。一帧大致按这个顺序走：
- EarlyUpdate：处理输入事件（Input）、计时器、本地通知等，把上一帧遗留的底层数据先整理好。
- FixedUpdate阶段：物理引擎的固定步长模拟，所有挂了FixedUpdate回调的脚本在这里被调用。
- Update阶段：调用所有MonoBehaviour的Update回调，大部分游戏逻辑都在这。
- LateUpdate阶段：所有Update之后再执行的逻辑，适合做摄像机跟随、状态修正。
- 渲染阶段：引擎把场景里的物体做剔除、排序，然后向GPU提交绘制指令。
- 帧结束：处理一些清理、回调、异步任务的结果回收。
这里有一个非常关键的认知点：Update并不像很多新手以为的那样"每帧就执行一次这么简单"，它在整帧流程里有明确的位置。比如你在Update里写读取鼠标输入的逻辑，这份输入数据其实是上一帧末就收集好的；你在Update里改了一个物体的Transform，这个改动到渲染阶段才真正生效。所以我一直跟新人强调，不要只在Update里写代码，要试着把自己代入Unity的调度节奏里。
还要注意一个容易忽略的细节：场景里所有启用状态的MonoBehaviour脚本，它们在Update阶段的调用顺序在默认情况下是不确定性的。虽然Unity提供了Script Execution Order面板可以手动调整，但你不设置的话，两个脚本谁先执行完全取决于Unity内部的加载顺序。这就是很多"偶发的Bug"的源头。
1.3 帧率陷阱：Update、FixedUpdate与Time.deltaTime
Update每帧执行，但每帧的间隔时间不固定。60帧的时候，一帧16.67ms；跑到120帧的时候，一帧8.33ms；卡一下可能变成100ms。所以如果你在Update里写"每帧移动一个固定距离"，那么帧率高的设备上物体会动得快，帧率低的设备上动得慢。这就是为什么所有移动逻辑都必须乘以Time.deltaTime。
Time.deltaTime拿到的就是"上一帧到当前帧所经过的时间"（以秒为单位）。你用"移动速度 × Time.deltaTime"算出来的位移，实际效果是"每秒移动固定距离"，而不是"每帧移动固定距离"。这两者的差别，在帧率不稳的手机上尤其明显。同一段代码，在iPhone高刷屏和低端安卓机上跑出来的移动速度，只有乘了deltaTime才能保持一致。
而FixedUpdate使用固定步长（默认0.02秒，即每秒50次）调用，它不受帧率波动影响。物理模拟必须放在FixedUpdate里，原因就在于物理引擎需要稳定的时间步长来做积分计算。如果你把刚体的施力、速度修改放在Update里，帧率一变，物理模拟的时间间隔全乱套，物体运动就会变得忽快忽慢。
注意：FixedUpdate虽然每秒固定调用50次，但如果游戏帧率低于50帧，Unity会在同一帧内多次调用FixedUpdate来追补物理步长。所以不要在FixedUpdate里依赖帧计数或者一次性逻辑（比如"只执行一次"的操作），否则会出现莫名其妙的重复执行。
我实操中就踩过一个典型的坑：在FixedUpdate里写了一个"按下空格就跳"的判断，结果低帧率下玩家按一次空格，角色跳了两次。原因就是物理步长被追补时，FixedUpdate在那一帧里被调用了两次，而输入状态还没来得及刷新，所以两次都判定为"按下"。这种问题非常隐蔽，排查的时候只能看到"偶发双跳"，很难直接定位。
2. MonoBehaviour生命周期：脚本的执行顺序藏着设计意图
2.1 完整的生命周期调用顺序
每个挂在GameObject上的MonoBehaviour脚本，从存活到销毁，会依次经历下面这些关键节点。我建议所有打算深入Unity的人都把这个顺序背下来，它比任何API文档都重要：
- Awake：脚本实例被创建时立刻调用，且只调用一次。
- OnEnable：每次脚本被启用时调用（可能多次）。
- Start：在第一次Update之前调用，且只调用一次。
- FixedUpdate / Update / LateUpdate：循环执行。
- OnDisable：脚本被禁用时调用。
- OnDestroy：脚本实例被销毁时调用。
这个顺序不是随手排的，每一环都有考量：Awake在对象创建后立刻触发，可以保证所有组件都已经被创建好，而且它在场景加载过程中执行，适合做内部引用绑定；OnEnable会在对象每次激活时触发，适合注册事件和订阅消息；Start在第一次帧更新前调用，保证场景里所有对象都已经Awake完毕，适合做跨对象初始化。
2.2 Awake、Start、OnEnable到底有什么区别
这三个函数的区别，是我带新人时被问得最多的。很多人只知道"Awake先执行，Start后执行"，但实际用起来还是一头雾水。这里我给出一个更准确的判断标准：
Awake相当于"出生"，Start相当于"上台前"。
- Awake在这个脚本所属的GameObject被实例化时执行，即使物体在场景中被禁用（SetActive(false)），只要脚本本身是启用的，Awake依然会执行。
- Start会在场景中所有对象的Awake都执行完、即将进行第一次Update前才执行。
OnEnable的时机比很多人想象的更微妙：如果脚本一开始就是启用的，OnEnable会在Awake之后立即被调用；如果脚本一开始是禁用的，那么OnEnable会等到你SetActive(true)的那一刻才被调用。所以初始化逻辑放哪里是一门学问。
举个实际场景：你要做一个怪物管理器，它要监听场景中所有怪物的死亡事件。如果这个管理器对象在场景初始时是隐藏的（SetActive(false)），你在Awake里订阅了事件，但OnEnable不会立刻执行，等到你把它激活时OnEnable才执行。如果你把订阅逻辑写在Start里，可能已经错过了早期生成的事件。这种"为什么事件没收到"的问题，根源往往就是生命周期函数选错了。
2.3 基于生命周期的初始化设计模式
我自己的项目中，初始化逻辑有一套固定的分配规则，你可以直接参考：
- 用Awake做组件引用获取（GetComponent），因为此时对象所有组件都已就位，而且Awake调用时机最早，缓存下来供后面使用。
- 用Start做涉及其他对象的数据准备，比如读取配置、计算初始属性、向管理器注册自己。
- 用OnEnable订阅事件、OnDisable取消订阅，这样对象反复启用/禁用都不会出现回调堆积。
还有一个非常重要的提醒：不要在Awake里访问场景中其他GameObject的Start初始化结果。因为Awake阶段，场景里所有对象的Awake都还没执行完，但Start阶段所有对象的Awake已经全部完成。很多"间歇性Bug"，比如有时候能拿到引用、有时候为空，往往就是因为把跨对象的初始化放到了Awake里。
我记得有一次排查一个任务系统的Bug：任务UI在自己Awake里读取玩家背包里的道具数量，结果每次进新场景，UI上显示的数量总是上一次的值。后来发现原因就是：背包管理器的Awake还没跑，任务UI的Awake就先跑了，读数的时候背包数据根本没初始化。把读取逻辑挪到Start之后，问题立刻消失。这种问题在编辑器里很难稳定复现，因为你手动点Play的时候，加载顺序可能跟实际场景加载时的顺序不同。
3. GameObject与组件：场景运行时的心脏
3.1 Transform层级在运行时如何驱动
场景里每一个可见或不可见的物体都是GameObject，GameObject本身是个容器，它的行为都来自挂在上面的组件（Component）。Transform是几乎所有物体都有的组件，它负责位置、旋转、缩放，并且维护父子关系。
在运行时，Unity会按照"先父后子"的顺序更新Transform。父物体动了，子物体的世界坐标也要跟着变。所以当你修改父物体的position，子物体的position（局部坐标）虽然不变，但它的世界坐标已经跟着变了。这就是为什么在代码里把子物体的position直接改成世界坐标，有时候会出现"飞出去"的效果。
实操中一个很常见的坑：你在Update里设置子物体的localPosition，以为是相对父物体的偏移，但如果父物体在之前的帧里被旋转过、缩放过来，localPosition的计算结果会完全超出你的预期。每次修改Transform之前，先想清楚你要改的是局部坐标还是世界坐标，尽量统一操作维度。我见过一个UI血条跟随角色的Demo，作者把血条挂到角色子节点，然后在代码里设置position，结果角色一转身血条就飘到屏幕外。其实就是因为他用的是世界坐标position，而UI节点挂在角色下，每次赋值都被父节点Transform再次变换。
3.2 GetComponent的查找机制，为什么必须缓存
GetComponent是Unity里最常见的调用之一，但很多人不知道它的代价。在几万个物体的大场景里，频繁调用GetComponent会引起GC分配和查找开销。实际经验是：在Awake阶段把需要引用的组件缓存到私有字段里，之后直接使用缓存。
还要注意，GetComponent只查找当前GameObject，它不查找子物体，也不查找父物体。查找子物体要用GetComponentInChildren，查找父物体要用GetComponentInParent，这两个方法默认会递归遍历整个层级，所以开销更大，更要注意缓存。
有些人的代码里Update里写GetComponent，每帧查一次。单独看没什么感觉，但场景里如果有100个怪物，每个怪物每帧都查一次，一帧就是100次查找调用，一分钟就是6000次，一小时就是36万次。这些开销完全可以用初始化时的一次缓存省下来。对移动端的性能来说，这种无谓的调用累计起来是致命的。
提示：如果你确实需要在运行时频繁查找组件，优先考虑把引用从外部注入（Inspector拖引用），其次是Awake缓存，最后才是运行时GetComponent。
3.3 Instantiate与Destroy：创建销毁背后的原理
用过Instantiate的都知道它能复制一个对象出来，但背后的运行原理值得理清：Instantiate会执行一次对象的完整序列化拷贝，生成一个新的GameObject实例，然后把上面所有组件的Awake、OnEnable在合适的时机触发。新对象的Awake会在当前帧内、Instantiate返回之前执行，但Start要等到下一帧的Update之前才执行。
这就导致一个有趣的现象：Instantiate返回后，你可以立刻修改这个新对象的Transform、读写它的组件数据，它都是安全的；但你在这个时刻访问它的Start要设定的变量（比如从配置表读取的初始属性），拿到的是默认值。所以如果你在Start里根据某些外部数据初始化对象状态，而不是在Awake里赋值，Instantiate后立刻使用这个对象的业务数据，很可能是错的。
Destroy比较特殊：它不会立刻销毁对象，Unity会在当前帧更新结束后才真正执行销毁。所以你在Destroy之后立刻访问对象，仍然能访问到，但如果在下一次物理更新或者LateUpdate里访问，可能就会报"Object has been destroyed"错误。这就是为什么很多教程里会用DestroyImmediate，但在运行时用DestroyImmediate是不推荐的，它不会延迟销毁，容易造成引用悬挂。
实际开发里，我见过一个很典型的Bug：玩家发射子弹，子弹命中了敌人，敌人被Destroy，但子弹脚本OnTriggerEnter里在Destroy之后继续访问enemy.transform.position，结果下一帧物理回调又触发了一次，此时敌人其实已经在销毁队列里，访问其Transform时抛出了MissingReferenceException。这类问题排查起来非常浪费时间，最好的防御方式就是在Destroy之后不要持有任何对该对象的引用，凡是可能被异步回调触发的逻辑，访问对象前先判断是否为空。
4. 一帧内隐藏的工作：渲染与物理的调度逻辑
4.1 渲染管线怎么跟游戏循环接上
渲染是每一帧的重头戏。在Unity里，当你写了一个带MeshRenderer组件的物体，Unity的渲染管线会在每帧的渲染阶段，根据相机的位置、朝向、视锥体，判断这个物体是否在可视范围内，如果可见，就把它往GPU提交绘制指令。这个过程叫剔除（Culling）。Unity还会尝试把多个材质相同、Mesh相同的物体合并成一次绘制调用，这个过程叫批处理（Batching）。
这里要理解一个重点：CPU端的脚本逻辑和GPU端的渲染是不同步的。你在一帧的Update里修改Transform，当前帧渲染时Unity会重新读取Transform数据，然后把绘制指令提交给GPU，GPU的渲染是异步的，渲染结果要到下一帧才显示。所以当你在编辑器里拖动物体，你会发现Game视图的显示比场景视图略慢半拍，这就是同步差异造成的。
顺带提一句批处理为什么重要：GPU每一次绘制调用（Draw Call）都有固定的开销，绘制100个Cube需要100次Draw Call，但如果它们材质相同、网格相同，可以合并成1次Draw Call。很多项目一卡顿，第一件事就是查批处理有没有被破坏。什么会破坏批处理？比如物体被缩放成不同大小（动态批处理有要求），比如物体使用了不同的材质实例，比如UV偏移不一致。理解了渲染管线在帧内的调度位置，你再回头做优化时会更有方向感。
4.2 物理引擎的固定步长，为什么物理逻辑必须放FixedUpdate
物理系统是另一个独立运行的模块。Unity内置的PhysX物理引擎按照固定时间步长进行模拟，每一小步都要处理碰撞检测、刚体受力、关节约束等。默认值是0.02秒，也就是每秒50次模拟。如果你的游戏帧率稳定在60帧，那么物理模拟并不是每帧都执行一次，而是每三帧才执行一次（3×0.0167≈0.05，对应约2.5个步长，具体峰值分布不均匀）。
这带来一个经典问题：当你的游戏卡顿、帧率降到20帧，FixedUpdate的调用次数反而会变多，因为物理引擎要按固定时间间隔追补模拟。在低帧率状态下，一帧里可能连续调用多次FixedUpdate来追平物理时间。这也是为什么物理相关逻辑不能依赖帧率的原因，也是之前提到"按下跳跃却跳了两次"这种Bug的根源。
我在做物理相关功能时的习惯是：所有涉及刚体加力、速度设置、碰撞检测后处理的逻辑，一律放FixedUpdate；跟物理无关的纯表现逻辑、输入收集，放Update；需要读取物理结果来驱动表现（比如根据角色速度调整动画速度）的逻辑，放到LateUpdate里在物理之后读取。
4.3 LateUpdate存在的理由，为什么摄像机跟随要放这里
LateUpdate是在所有Update之后调用的，它存在的意义就是给"跟随"类逻辑一个稳定的时间点。比如摄像机跟随角色：如果摄像机在Update里读取角色的位置，而角色的移动也在Update里，两者的执行顺序是没有保证的，可能角色先动、摄像机后读，那么一帧画面里摄像机的位置总是滞后一帧。放到LateUpdate里，此时所有角色的Update都执行完了，摄像机读到的就是这一帧的最终位置。
这个设计非常重要，尤其是做FPS游戏或者竞技游戏的时候，跟手感的差异往往就在这一帧的延迟上。你用LateUpdate做摄像机跟随，跟手程度会比Update好很多，因为摄像机拿到的是当前帧角色已经更新完的最终位置，而不是上一帧残留的旧值。
我把这个逻辑总结成一句话：LateUpdate是"观察者视角"，适合读取其他对象Update之后的结果；Update是"行为者视角"，适合改变自身状态。所有跟手摄像、位置修正、UI对齐跟随，都应该放LateUpdate。
5. 主线程限制与协程：Unity并发模型的核心原理
5.1 为什么必须在主线程操作Unity API
Unity引擎的核心模块，包括场景管理、组件系统、渲染指令提交，都不是线程安全的。所有Unity对象的访问和修改，都必须发生在主线程。原因很简单：引擎内部的数据结构没有加锁，如果多个线程同时改Transform、同时访问GameObject，内存就会出现不可预知的状态。
所以你在后台线程里哪怕只是读取transform.position，也会在运行时抛出异常或者返回错误数据。正确做法是：后台线程只做纯计算（比如寻路计算、序列化、网络包解析），把结果存到队列里，主线程在Update或协程里取出队列结果，再去操作Unity对象。
我见过很多新手在项目里用C#的Task写网络请求，然后在回调里直接修改UI文本，结果就是Unity报"get_transform can only be called from the main thread"。这个问题其实不难解决，但需要用对模式：后台线程计算结果，主线程取结果并更新。
5.2 协程：它不是线程，是迭代器
协程（Coroutine）是Unity里常用的异步方案，但它的底层实现和"多线程"没有任何关系。协程的本质是一个C#迭代器（IEnumerator），Unity在每次迭代到yield语句时，会把当前方法挂起，然后在合适的时机恢复执行。
举一个实际例子：
StartCoroutine(MyCoroutine()); IEnumerator MyCoroutine() { Debug.Log("开始"); yield return new WaitForSeconds(2f); Debug.Log("两秒后"); }这段代码里，yield return new WaitForSeconds(2f)并不是真的让"线程等待两秒"，而是协程告诉Unity："我要暂停，请在两秒后的帧来恢复我。"所以协程里的代码始终跑在主线程上，它的挂起不影响其他代码执行，也不会占用额外线程。
实操心得：协程非常适合做延时、动画队列、UI自动滚轮这类逻辑，但要注意协程对"对象销毁"特别敏感。如果挂在某个GameObject上的协程还没跑完，物体被销毁了，协程会直接中止，不会再恢复。还有一种常见错误，是在协程里等待一个永远等不到的条件，比如等待一个被禁用的异步任务，协程会永远挂在那个yield上，白白浪费内存。
5.3 异步加载与真实异步，Unity到底异步了什么
Unity后来的异步接口（Addressables、SceneManager.LoadSceneAsync、UnityWebRequest）很多是基于真实的多线程异步实现的，它们允许后台线程做资源读取、解压、加载，但最终对Unity对象做修改、实例化到场景里时，仍然是在主线程上完成的。所以这类接口返回后你在回调里直接访问场景，是安全的，但你在非主线程里手动调用这些接口就是错误的。
用一句话记忆：Unity的世界里，主线程是唯一能碰场景数据的人，后台线程是它的助理，只能帮忙准备素材，不能上手操作。理解了这一点，你在写网络同步、资源加载、寻路这类多线程需求时，就不会试图绕过主线程，而是会主动用队列、事件、协程这些安全的方式把结果交还给主线程。
实际项目里我比较推荐的异步资源加载写法是：用UnityWebRequest在后台下载资源字节流（这一步是后台线程），下载完成后回到主线程把字节流交给AssetBundle.LoadFromMemory，然后再用Instantiate去创建对象。每一步都清楚"当前代码跑在哪个线程"，就不会出幺蛾子。
写到这里，Unity运行原理的地基已经铺完了。我在带新人入行的时候，最喜欢说的一句话是：先别急着学怎么做背包、怎么做角色控制，先把"游戏循环""生命周期""主线程"这三根柱子立起来，后面所有的框架和优化都是在这些地基上搭房子。这篇作为开篇，没有给你一段写死的代码，但如果你认真理解了游戏循环和生命周期，再看引擎里的每一个回调函数，都不会再觉得它们是魔法。
下一篇开始，我会从Component和脚本的交互入手，结合具体的玩法Demo，讲清楚Unity里的代码到底是怎么挂到场景里跑起来的。如果你在阅读过程中有任何疑问，尤其是对帧率、生命周期、协程这几块想深入聊的，欢迎在评论区提出，我挑典型的来展开。
