有人问了一个看起来特基础、仔细想又说不清的问题：Unity引擎到底是怎么知道某个MonoBehaviour子类里有Start方法，然后在正确时机自动调用的？刚入门的同学觉得这事挺玄学——脚本里写了个Start，引擎就跟约定好了一样，在场景激活后的第一帧前给你执行掉；可问它是怎么找到这个方法的，是反射、是注册表、还是别的黑魔法，很多人就卡住了。这篇文章就把这条链路从头到尾挖一遍，搞清楚Unity在“方法发现”“方法注册”“方法调用”三个阶段分别做了什么。
这个话题不仅仅是为了解一道面试题。实际开发里，你遇到的“为什么Start没执行”“为什么两个脚本之间初始化顺序不对”“为什么SendMessage那么慢”这些问题，根源全在这里。搞懂内部机制，排查问题会快得多，设计架构也不会再滥用字符串消息。
1. 先理解Unity选中的套路：约定优于接口
很多人默认以为Unity靠的是某种接口或者虚方法，比如所有生命周期方法都是MonoBehaviour基类里定义好的virtual方法，子类通过override触发。这个直觉放在C#里很合理，但实际完全不是这么回事。
1.1 MonoBehaviour的基类里并没有Start和Update
你可以自己翻一下程序集，MonoBehaviour基类里根本不存在virtual void Start()、virtual void Update()这些虚方法。如果存在，你就无法在一个脚本里重复定义自己的Start却不去写override了。Unity之所以这么设计，核心是为了“按需回调”：一个脚本可以只实现Update，另一个脚本可以只实现Start，每个类不需要为用不到的消息方法付出任何成本。
如果改成接口方案，比如ILifecycleUpdate之类的接口，那么每个MonoBehaviour子类都不得不实现一大堆方法，否则编译就报错，使用体验会变得非常反人类。Unity选择了“约定优于配置”的路线——引擎内部维护了一套消息方法名字表，所有继承自MonoBehaviour的类型，只要某个方法的名字和签名能匹配上，就会被引擎自动识别为回调。
1.2 魔法方法的通用特征
这些被识别的方法有几个共同特征：
- 是实例方法，不是静态方法；
- 方法名和Unity预定义的消息名完全一致；
- 参数数量、参数类型、返回值类型与Unity预期一致；
- 访问级别通常是private或public均可（细节后面展开）；
- 不需要override，也不需要额外标注Attribute。
所以本质上，Unity通过“方法签名匹配”来完成逻辑绑定。这跟C#的事件、委托、接口都不一样，它更像是一种“引擎侧的自定义规则”。
2. 引擎和C#代码之间的两次握手
Unity引擎的核心是C++实现的，你的业务逻辑是C#写的。要让C++在合适时机调用C#方法，必须有两条通路：一条是把“哪些方法可以用”告诉C++，另一条是C++在游戏循环里拿着这些方法去实际执行。我把这两步分别称为“方法发现注册”和“生命周期分派”。
2.1 第一次握手：程序集加载后的方法扫描
程序集加载完成后，Unity的脚本运行时会在初始化阶段做一次“普查”。它遍历当前加载的所有托管程序集，筛出所有继承自MonoBehaviour的类型，再对这些类型的每个方法逐个比对名字和签名。
这一步在编辑器里非常容易被观察到：你写完脚本触发编译，Unity会短暂卡顿一下，然后在Console里提示“已编译脚本并完成程序集加载”，背后其实就做了大量元数据解析。运行时加载AB包或附加脚本时，同样的流程也会在后台走一遍。
关键点在于，这个扫描结果会被缓存下来。引擎为每个MonoBehaviour类型建立一张“消息方法表”，记录这个类里有哪些生命周期方法可用。之后运行时不需要再反复反射查找，直接查表即可。
2.2 第二次握手：PlayerLoop中的分派
Unity的主循环是一个被拆成多个阶段的调度器，业内通常叫PlayerLoop。每个阶段都会遍历场景中活跃的GameObject，拿到挂载的组件列表，然后检查组件的类型对应的方法缓存表里有没有当前阶段需要触发的回调。
举个具体的例子：每帧的“Update”阶段，引擎会遍历当前场景里所有Active的GameObject，找到其中的MonoBehaviour组件，再查询每个类型是否缓存了Update消息。如果缓存表里存在Update，就发起调用；如果不存在，直接跳过。这就是为什么没有实现Update方法的脚本完全不会带来额外开销。
FixedUpdate、LateUpdate、OnGUI、OnDisable等阶段也都是这么分派的，只是它们挂在PlayerLoop的不同节点上。
3. 底层真相：Mono与IL2CPP两种后端路线
前面说的“方法表”和“调用”还是抽象层面的。具体落地时，Unity有两种脚本后端，它们的实现路线完全不同，但对外暴露的行为保持一致。理解区别，能帮你搞清楚为什么移动端推荐用IL2CPP，以及为什么有些反射代码在IL2CPP下会出问题。
3.1 Mono后端：反射后在Native侧缓存函数指针
在Mono后端下，Unity的C++侧会调用Mono运行时API，比如mono_class_get_methods、mono_class_get_method_from_name，在程序集加载阶段拿到某一个C#方法的MonoMethod*指针，然后缓存起来。
当PlayerLoop触发Update回调时，引擎拿着缓存的MonoMethod*，调用mono_runtime_invoke来真正执行C#方法。这里有个关键点：虽然“查找方法”阶段用了反射，但“执行方法”阶段不再有任何反射开销，走的直接是运行时invoke。对性能敏感的开发者应该放心——Unity不会每帧都做一遍字符串查找。
3.2 IL2CPP后端：C#代码变成了C++代码
IL2CPP后端下，所有C#代码在打包阶段被转换为C++代码。你的Start方法最终是一段可以被直接编译的C++函数，方法本身不再需要通过解释器分发。
Unity在转换时会生成一个全局的元数据表，里面保存着每个方法的MethodInfo信息。运行时拿到MethodInfo后，可以直接取得对应的C函数指针并调用。
这套机制的优势非常明显：
- 没有JIT编译，启动时不需要解释执行；
- 没有反射元数据庞大的运行时开销；
- 方法调用链可以被AOT编译器优化得更充分。
所以从内存和性能两个维度看，IL2CPP都比Mono更适合移动端。
3.3 两种后端共通的缓存思想
不管哪个后端，Unity都遵循同一条经验法则：查找一次，执行多次。生命周期方法被扫描识别一次，之后所有调用都走缓存路径。如果你写的代码有一天需要进行类似“按名字调用方法”的操作，一定要继承这个思想，不要让查找逻辑出现在高频循环里。
4. 生命周期时序：一套严格编排的执行顺序
理解了“怎么调到”之后，再看“什么时候调”。生命周期消息的先后顺序确实有一套标准时序，但边界条件也很多，尤其是“对象激活时机”和“场景加载流程”会改变某些回调的触发位置。
4.1 一个对象从实例化到销毁的完整调用链
拿你用Instantiate动态创建一个Prefab举例，假设它在创建时是激活的，执行顺序如下：
- Awake：对象创建后立刻执行，此时Prefab上所有脚本的Awake都会被连续调用；
- OnEnable：对象如果处于Active状态，Awake之后马上触发；
- Start：不是创建后立即触发的，而是在该对象第一次进入帧更新循环之前。更准确地说，是同一帧里所有Awake和OnEnable执行完之后、第一个Update之前；
- Update / FixedUpdate / LateUpdate：进入帧循环后按各自节奏触发；
- OnDisable：对象被设为非激活，或组件被Disable时触发；
- OnDestroy：对象被销毁时触发。
这里有个特别容易踩的坑：很多人以为Start是创建后立刻跑的，结果在Start里访问另一个刚Instantiate出来的对象的数据时发现“拿不到”。原因就是那个对象的Awake虽然已经执行，但它的Start可能还没执行，因为引擎是按帧调度的。
4.2 Start一定会在Awake之后执行吗
对同一个对象上的同一个脚本，答案是肯定的。引擎保证消息调用顺序是Awake、OnEnable、Start。但不同对象之间就没有这个保证。你在对象A的Awake里访问场景对象B，B有可能根本没被激活，更别说Awake了。这是Unity设计上就默认的行为，不是随机问题。
如果确实需要依赖一个全局的初始化顺序，可以考虑使用脚本执行顺序面板（Script Execution Order）来调整同一脚本执行先后。但需要注意，它只影响部分消息的执行优先级，不能修复所有初始化时序问题。
4.3 几个不会触发回调的典型场景
如下场景里，消息不会按预期触发：
- 对象初始状态是未激活（GameObject.SetActive(false)），挂在它上面的MonoBehaviour的Awake不会立即执行，直到对象后续激活才会补执行Awake；
- 组件被Disable时，Update不会再触发，但Awake已经执行过；
- 如果方法签名不对，比如写了Start(float value)，引擎不会把它当作Start回调，因为签名匹配不上；
- 脚本编译期有错误时，整个程序集无法加载，所有回调不会触发。
这些情况在排查“脚本没反应”时非常有用。优先检查对象激活状态、组件是否Enable、方法签名是否一致。
4.4 编辑器消息是另一套逻辑
还有一批命名像消息、但生命周期完全不同的方法，比如Reset、OnValidate、OnDrawGizmos。它们属于编辑器扩展回调，只在编辑器环境下触发。Reset在组件“Add Component”时触发，用于重置字段默认值；OnValidate在脚本Inspector面板上的值被修改或脚本加载时触发，常用于编辑器里的数据校验。
这些方法虽然也由引擎自动识别，但和运行时生命周期消息不是一个分派流水线。别在真机环境里指望它们执行。
5. 源码视角：去Unity的参考实现里找证据
如果你想把上面这些结论验证一遍，最直接的方式是打开Unity的C#参考源码仓库。Unity开放过一部分运行时和编辑器的源码，重点看这些目录：
- Runtime/Export/Scripting：MonoBehaviour、GameObject等底层定义的C#侧封装；
- Runtime/Export/PlayerLoop：PlayerLoop系统相关的结构定义；
- Runtime/Scripting：脚本运行时和本机互操作相关代码。
源码里会明确展示如消息方法查找相关的枚举定义和调用逻辑。看到这些宏定义和查找逻辑后，你会彻底明白：Unity根本没有在MonoBehaviour基类里为每个消息准备虚方法，而是通过在Editor和Runtime两侧分别注册回调完成的。
反编译工具也可以帮你确认。比如用常见反编译工具打开程序集，直接搜索“Start”或“Update”，你会发现MonoBehaviour类本身并没有这些方法的定义。你自己的脚本里写的方法，只是恰好被引擎的规则匹配到了。
这里给一个非常有操作性的验证技巧：在脚本里给Start方法加上断点或打印调用栈，然后在Unity的Console窗口里展开堆栈。你会看到调用栈底有“Native Method”之类的标记，再往上才是你自己的方法。这说明调用入口确实来自引擎native侧，而不是C#侧的事件系统。
6. 常见问题盯防手册
围绕“Unity怎么调用MonoBehaviour子类方法”这个话题，实际开发中容易遇到下面几个高频疑点。逐个说清楚，能免掉不少排查时间。
6.1 Start方法可以写成private吗
可以。很多人把Start写成public，其实是没必要的。Unity在扫描消息时，查找标志通常覆盖Public和NonPublic、Instance，所以private的Start和Update同样会被识别并调用。
之所以这里会产生误会，是因为主流编程语言里“外部调用”和“可见性”强相关。但Unity引擎并非从C#代码里直接调用你的方法，而是通过运行时API查方法表后调用。在方法可见性上，引擎没有强制要求public。
不过要注意，如果你用自定义工具类直接反射调用别人的Priviate方法，那是另一套规则，未必能跨程序集访问。
6.2 为什么某个脚本没有Start方法也不会报错
因为Unity扫描消息表时，只把“存在且签名匹配”的方法登记为回调。没有Start方法，就只是表格里这一项为空，PlayerLoop分派到Start阶段时直接跳过该组件。这属于正常状态。
顺带提一句性能常识：一个场景里挂成百上千个脚本，其中多数都没有Update方法，并不会产生明显的每帧开销。这正是“按方法名字匹配”方案的价值之一。只有在脚本真正实现了Update时，每帧才会有一次调用开销。
6.3 SendMessage和Unity消息机制是什么关系
SendMessage是MonoBehaviour对外暴露的一个字符串API，它走的是另一条反射查找路线。调用方用字符串指认方法名，运行时实时去目标组件上查找并调用，能找到就执行，找不到也能“兜底”不报错。
问题也很明显：
- 字符串查找发生在运行时，无法在编译期发现拼写错误；
- 每次调用都有反射开销，性能远不如引擎内置消息；
- 方法名改动后，调用方字符串会无声断裂。
官方文档和社区也普遍不推荐在业务逻辑中大量使用SendMessage。你自己的框架设计里，如果生命周期回调不够用，完全可以定义一个自有的接口体系或者事件系统。
6.4 生命周期方法里的执行顺序能否控制
同一对象上同一个方法，比如多个脚本的Update执行顺序，可以在Script Execution Order里调整。但没有语义上的绝对顺序保证，除非你把需要严格排序的逻辑放到同一个对象的同一个脚本里，或者放到一个自定义管理器中统一驱动。
实际项目里更常见的做法是：让某些对象不依赖Awake/Start的先后，而是在自己的Start里完成“准备数据”，用轮询或事件机制去消费。靠顺序来强行解决问题，往往会让架构越来越脆。
7. 自己设计类似机制时，能借鉴什么
这套“消息方法识别”的设计不只属于Unity。任何需要让用户代码被上层系统自动发现的场景，都可以参考几个核心经验。
7.1 性能优先的注册方式
不要在高频路径上做字符串查找。扫描可以放在初始化阶段，运行时只查缓存。比如你自己写一个UI管理器，希望所有面板在打开时自动调用Open，那就在注册面板时扫描一次，生成委托缓存，而不是每次打开面板都去反射。
7.2 约定文档要精确
既然使用了“方法名字+签名”作为约定，就要在文档里写清楚方法名、参数和返回值。Unity之所以能靠文档约束让开发者写出正确签名，是因为它踩过无数坑后沉淀了一套完善的约定说明。如果你在自定义框架里这么做，一定要把错误签名会引发的结果也写清楚，否则用户会莫名踩坑。
7.3 给用户一个优雅的兜底接口
纯约定机制最大的问题是出错时很难快速定位。Unity提供了部分编辑器提示，但在自行设计的框架中，更建议提供接口手段作为辅助。比如把“标准回调”和“自定义事件总线”同时开放，用户能用接口实现可靠绑定，也能用约定方法获得便利。二者结合，比单一机制更贴近实际开发需求。
8. 最后再分享几个排查经验
平时做项目，遇到“回调不执行”，按照下面顺序查，基本都能定位：
- 查看Console是否有编译报错，有错先解决编译问题；
- 确认GameObject在Hierarchy中处于Active状态；
- 确认MonoBehaviour组件处于Enable状态；
- 确认方法名和签名没有写错，特别是参数类型和大小写；
- 确认脚本没有挂载多个实例导致同名方法被重复调用；
- 确认当前场景存在该对象，有些排查了半天结果发现是打开了错误场景；
- 对于编辑器特有回调，确认当前确实在编辑器环境下运行。
有一次我在调试一个诡异的“Start不执行”问题，最后发现是脚本所在的Prefab被放在了一个未激活的父节点下。整个子树的Awake都没跑，直到运行时某个逻辑才把父节点激活。这个问题通过打印对象状态字段，一眼就看出来了。排查这类问题，最快的方式永远是先确认对象的ActiveSelf和ActiveInHierarchy状态，这两个值会直接决定消息能不能分发下来。
另外，如果你在IL2CPP打包后发现某些动态反射调用失效，也要优先怀疑后端差异。IL2CPP默认会做代码裁剪，若某些生命周期方法因为被裁剪而丢失，需要在链接器配置里保留对应方法。不过这个坑多出现在反射那一路，正常写的Start、Update是不会被误裁的，因为引擎在扫描阶段就识别并保留它们了。
我个人在多年项目里最大的体会是：Unity这套自动调用机制并不神秘，它是“先扫描、再缓存、最后分阶段触发”的经典框架设计。理解它之后，就不要在业务代码里重复造类似的轮子，更不要依赖SendMessage这种低效字符串方案。设计自己的生命周期系统时，把“初始化扫描一次”和“运行时零查找”这两条经验记住，就能避免很多性能和技术债问题。
