Unity Editor 是怎么做出来的：界面、框架，以及和 Godot / Unreal 的根本差别

Unity Editor 看起来像一套完整的桌面软件：可停靠窗口、Inspector、Scene 视口、菜单和快捷键。但如果你要自己做游戏引擎工具，最有用的问题不是「它长什么样」，而是：

这套界面是用什么画出来的？哪些能力属于编辑器，哪些属于运行时？游戏内编辑器能复用多少「看起来像 Editor」的绘制？

公司层面的二十年故事见 Unity 的二十年；C# 运行时见 从 Mono 到 CoreCLR。本文只谈 Editor 本身：窗口如何叠起来、UI 用了哪些框架、历史上改过什么，以及和 Godot、Unreal 的差别。

先把三层拆开

很多人会把「Unity」当成一个东西。对 Editor 来说，至少要分成三层：

C# 脚本跑在嵌入的 Mono 上——Unity 6.x 的 Editor 仍是如此；全面切到 CoreCLR 是 Unity 7 路线图里的事，不是 6 的现状。¹ 引擎对象则往往有一份 C++ 本体、一份托管包装，两边通过绑定连起来。²

所以 Editor 不是「用 C# 重写了一遍引擎」，也不是 Electron 套壳。它更像：一个原生引擎进程，嵌了托管运行时，再在上面用 C# 搭出几乎全部可扩展界面。Unity 公开了大部分 C# 参考源码，窗口、停靠、IMGUI 与 UI Toolkit 的托管侧都可以直接读。³

用户拖出来的「Hierarchy」「Inspector」，都是 EditorWindow。真正对应操作系统窗口的，是内部的 ContainerWindow：它保存原生句柄，负责显示、尺寸和关闭。中间的 GUIView / HostView 把原生输入转给托管代码；DockArea 则管理同一区域里的多个标签页。³

这套停靠布局会存进 .dwlt 一类布局文件。对工具作者的含义很具体：窗口是数据，布局是另一份数据。 界面控件本身不该是唯一的持久化来源。

Unity Hub 是另一回事。它负责安装和管理多个 Editor 版本，并不参与 Scene 绘制。Hub 的崩溃日志里能看到 app.asar 与 electron-json-storage，说明它走的是 Electron 打包路径；Editor 本体没有走这条路。⁴

界面到底怎么画

Unity 6.6 的官方建议很干脆：⁵

注意：Editor 里几乎不用 uGUI。uGUI 依赖 Canvas、GameObject 和场景层级，适合游戏，不适合停靠窗口和 Inspector。历史上撑起整个 Editor 的，是另一套东西。

IMGUI：每一帧把界面说一遍

早期 Unity 的编辑器 UI 是 Immediate Mode GUI。你在 OnGUI 里调用 GUILayout / EditorGUILayout，框架在这一帧绘制控件、处理点击，下一帧再来一遍。控件树默认不保留；状态要自己放在字段里。⁶

这对工具开发极友好：写一个 EditorWindow，几行就能出按钮和滑条，调试面板几乎没有启动成本。代价同样明显：复杂布局难维护，样式不统一，大列表容易把 CPU 画崩，设计师也没法在可视化工具里改界面。

Scene 视口里的 Handles / Gizmos 仍然是这种「立刻画」的思路。变换手柄、测量线、自定义场景控件，并不走 UXML。即时模式没有消失，只是从「整个 Editor」退到了「仍适合即时模式的地方」。

UI Toolkit：留下一棵树，按网页那套拆结构

大约从 2019 的 UIElements 开始，Unity 把 Editor 往 保留模式 推。现在的名字是 UI Toolkit。你声明一棵 VisualElement 树，改属性、收事件、让框架去布局和重绘。官方明确说它受网页技术启发：UXML 类似 HTML/XML，USS 类似 CSS，行为写在 C# 里。⁷

布局引擎采用 Yoga 的原则，也就是 Flexbox 的一个子集：flex-direction、flex-grow、align-items、justify-content。绝对定位留给 overlay，常规界面靠嵌套 flex 容器。⁸

一个自定义 Editor 窗口的现代入口不再是 OnGUI，而是 CreateGUI，往 rootVisualElement 上挂控件。Domain Reload 之后 VisualElement 不会被序列化，窗口必须重建树，并把真正要保住的状态放在 EditorWindow 的序列化字段里。⁹

IMGUI 并没有被删除。迁移文档给出的桥梁是 IMGUIContainer：可以在 Visual Tree 里嵌一块即时模式代码，反过来却不能把 VisualElement 塞进 OnGUI。¹⁰ 这是典型的渐进替换：新系统当宿主，旧系统当岛屿。

绘制侧，UI Toolkit 把大量元素合进动态图集，并用一条分支较多的 UI shader 减少切换。Unity 6 还把经典控件的几何生成和文本生成往 Job / 原生实现上搬，深层层级的 layout 缓存也有加强。¹¹

两套命名空间，才是真正的分界

UI Toolkit 同时服务 Editor 和 Runtime，但控件并不完全共用：

• UnityEngine.UIElements：按钮、列表、绑定、运行时也能用
• UnityEditor.UIElements：PropertyField、InspectorElement、对象选择器等 只存在于编辑器

UXML 里常见 xmlns:engine 与 xmlns:editor 两个前缀，原因就在这里。¹² 你可以让同一份菜单的视觉结构在 Editor 工具和游戏 HUD 之间复用；不能把 Inspector 的对象拾取、Undo、多对象混合值编辑，当成运行时控件一起带走。

Editor 还依赖哪些「看不见的框架」

界面只是最显眼的一层。做工具时真正要对接的，往往是下面这些系统。

序列化，而不是「窗口里的值」

Unity 把场景、Prefab、ScriptableObject 存成自己的 YAML 子集（Force Text 是现代项目的默认方向）。每个对象一块文档，属性名多带 m_ 前缀，引用靠 fileID / GUID。¹³

编辑器侧对应的运行时 API 是 SerializedObject / SerializedProperty。自定义 Inspector 应该改序列化属性，而不是直接改字段：Undo、Prefab 覆盖、多选混合值、脏标记，都挂在这条管线上。IMGUI 的 PropertyDrawer.OnGUI 和 UI Toolkit 的 CreatePropertyGUI，做的是同一件事的两种皮肤。

这一点对引擎工具作者几乎是铁律：把可编辑数据做成可序列化的数据模型，UI 只是模型的投影。 窗口关闭、Domain Reload、重新打开工程，模型还在，UI 可以扔掉重搭。

资源数据库与包

AssetDatabase 是 Editor 的文件系统真相来源：导入、依赖、GUID、刷新。它不是普通 System.IO。Package Manager 则把编辑器功能拆成包——UI Toolkit、Test Framework、Graph Toolkit、各渲染管线，都走这套分发。2019.3 起还可以从 Git URL 装包，Asset Store 资源也逐渐进同一套窗口。¹⁴

对工具链的启发是：编辑器核心保持相对小，功能用包扩展；用户项目的「引擎版本」和「工具版本」可以部分解耦。

搜索、Overlay、图工具

2019.3 引入 Quick Search，后来长成 Editor 级 Search：资源、层级、菜单、设置都从同一入口查。¹⁴ 复杂工具做大之后，全局搜索比再加一个菜单更重要。

2021 前后，Scene 视口上的工具条变成 Overlay：小块面板浮在 3D 视图上，而不是再占一个 Dock。Unity 6 把 Tile Palette 等也推进 Overlay，并让更多右键菜单改成 UI Toolkit 实现。¹⁵

图编辑是另一条线。Shader Graph、VFX Graph、Visual Scripting 长期用 GraphView。Unity 6.2 起提供实验包 Graph Toolkit（com.unity.graphtoolkit），目标是让内部团队和第三方用同一套节点图画自定义图工具。它仍是实验功能，不是「所有官方图窗口已经换完」。¹⁶

程序集边界

Editor 脚本必须放在名为 Editor 的文件夹，或 asmdef 只勾选 Editor 平台。UnityEditor 进不了 Player；硬引用会直接让打包失败。¹⁷¹⁸

这不是风格问题，是产品边界：游戏进程不该带着 Inspector、AssetDatabase 和停靠布局。

Unity Editor 历史上改过什么

如果只看皮肤，Unity 5 到 Unity 6 都还是「左边层级、中间场景、右边检查器」。真正的结构变化发生在更下面。

2019 年那一刀特别关键。在那之前，Unity 等于公开承认：即时模式适合程序员五分钟写工具，不适合做可主题化、可设计师参与、可虚拟化列表的大型 IDE。UI Toolkit 选择网页隐喻（文档 + 样式表 + 保留树），而不是把 Editor 改写成 Qt 或 WPF。

Unity 6 对工具作者最实际的变化，不是又换了一套皮肤，而是三条线同时收束：¹¹¹⁵

1. 数据绑定从 Editor 序列化属性，扩展到运行时也能用的 DataBinding
2. 自定义控件用特性声明，不必再写一大套 UxmlFactory / UxmlTraits
3. 绘制性能开始按「大批控件 + 深层级」去优化，而不只是能显示

和 Godot、Unreal 的根本差别

表面都是「可停靠的游戏编辑器」，分层方式却不一样。

Godot：编辑器用引擎自己的 UI 画出来

Godot 官方写得很直白：编辑器是一个用 C++ 写的 Godot 项目，用 Godot 的渲染器和 UI 系统绘制，不依赖 GTK 或 Qt。editor/editor_node.cpp 相当于编辑器的主场景。编辑器核心不能夹带 GDScript / C#；扩展则另说。¹⁹

游戏 UI 的 Control 节点，和编辑器 Dock、Inspector、文件面板，是同一套控件体系。@tool 让脚本在编辑器里跑，再用 Engine.is_editor_hint() 区分「正在编」还是「正在玩」。²⁰

这带来一个很强的结果：编辑器和游戏之间没有「第二套 UI 框架」。 你为游戏做的面板，概念上就能嵌进编辑器；你为编辑器做的控件，也更接近最终玩家会碰到的东西。代价是编辑器必须跟引擎 UI 的能力绑死，也更难在「纯工具进程」和「纯游戏进程」之间划出硬边界。

Unreal：Slate 是底，UMG 是皮，模块在编译期切开

Unreal 编辑器几乎全部建立在 Slate 上：C++ 的保留模式控件，带一套声明式构造 DSL。游戏里常见的 UMG，是包在 UObject 外面的设计器友好层，底层仍是 Slate widget。²¹

Editor Utility Widget 允许用 UMG 做编辑器页签，但文档写明这些 Widget 就是给 Editor UI 用的。²² 运行时模块和 Editor 模块在 .uplugin / Build.cs 里分成 Runtime 与 Editor；游戏目标不该链上 UnrealEd。需要时用 Target.bBuildEditor 和 #if WITH_EDITOR 切开。²³

和 Unity 相比，Unreal 更「源码引擎」：你可以编一个带完整编辑器的目标，也可以编一个什么工具都没有的 Game 目标。Fortnite 创作工具、各类内置关卡编辑器，走的是「同一套 Slate/UMG，换成产品目标」这条路，而不是把 Unreal Editor.exe 塞进 Shipping 包。

三句话对照

Unity 的特殊性在于：它把「好写的编辑器扩展」和「不能进包的编辑器运行时」绑在同一套 C# 里，又用程序集把它们剪开。 Godot 选择不剪开 UI；Unreal 选择在 C++ 模块图上剪开。

游戏里能不能画出「Editor 那样的界面」？

如果问题是「把 Play 按钮、AssetDatabase、整套 IDE 打进包」——不能，也没必要。游戏内编辑器真正想要的通常是另一件事：

玩家（或关卡师）在运行中的画面上，看到类似 Editor 的面板、列表、属性条，并能拖三维 Gizmo。

绘制层可以复用一部分；Editor 专用控件和 Scene 手柄不能原样搬进 Player。 分两层看会清楚很多：屏幕 UI，和世界空间里的拖拽工具。

屏幕 UI：能画，但要用运行时那一套

UI Toolkit 从一开始就把「Editor 和 Runtime 共用元素体系」写成目标：同一棵 Visual Tree、同一套样式和布局。官方示例甚至是同一张饼图控件，既出现在 Editor 窗口里，也出现在 Scene 的运行时 UI 上。⁷ 运行时入口不是 EditorWindow，而是场景里的 UIDocument，由 PanelSettings 决定 Overlay 还是世界空间、用哪份主题 USS。²⁴

所以：你可以做出很像 Unity Editor 的深色属性面板——把主题 USS 写成自己的资源，控件用 UnityEngine.UIElements。你不能 GetWindow<InspectorWindow>()，也不能把 Editor 默认主题当成游戏资源去加载。

IMGUI 也有一条更老的路。UnityEngine.GUI 本来就能在游戏里画，手册也写了「游戏和 Editor 扩展都可以用」；只是立刻补充：正常玩家 UI 不该走这条，性能和可视化编辑都差。²⁵ 对游戏内编辑器来说，IMGUI 适合先搭一个调试用属性条；面板一多，还是 UITK 更合适。

Unity 6 对「普通游戏 HUD」仍推荐 uGUI，UITK 是备选。⁵ 游戏内编辑器更接近复杂工具，而不是血条：列表、树、多列、绑定，走 UITK 更贴需求。世界空间里的广告牌、VR 指针，再另算。

Gizmo 和拖拽轴：观感能仿，API 不能搬

Scene 视口里那套红绿蓝移动轴，来自 UnityEditor.Handles（例如 PositionHandle），只存在于编辑器。²⁶ Gizmos.DrawLine / OnDrawGizmos 写在 UnityEngine 里，但文档明确是给 Scene 视口 的调试辅助；构建出来的 Player 不会走这条绘制路径。²⁷

游戏内要「拖物体」，得自己画、自己做拾取：

• 用 Mesh / LineRenderer / Graphics.DrawMeshNow，或 URP 里的 overlay pass 画轴和线框
• 用摄像机射线做轴命中，拖动时把屏幕 delta 投到轴向量上
• 指针在 UITK 面板上时，挡住 Gizmo 拾取，避免点到属性条却拖走了场景物体

数学并不神秘，Unity 公开的 C# 参考源码里就能看到 Handles 怎么算；缺的是 运行时宿主：命中测试、与 UI 抢输入、多摄像机、HDRP/URP 的绘制回调都不一样。社区有成熟的 Runtime Transform Gizmo 资产，本质也是重写，不是调用 Handles。

Debug.DrawLine 同样是编辑器/开发期辅助，不能当 Shipping 里的工具绘制。

和「把整个 Editor 嵌进游戏」的差别

下面这些仍然进不了包，游戏内编辑器也不该依赖它们：

• AssetDatabase、Prefab 覆盖、YAML 场景资源管线
• Editor Undo（UnityEditor.Undo）——要自己做命令栈
• ContainerWindow 停靠、Play Mode（那是 Editor 进程里跑游戏，不是游戏里跑 Editor）
• Unity as a Library：把 Player 嵌进别的原生窗口，方向相反。²⁸

Godot 在这一层更省事：编辑器和游戏都是 Control，Gizmo 也更容易跟同一套视口走。Unreal 的 Slate/UMG 可以进游戏，Details 面板那种自动反射编辑仍要自己接。Unity 给游戏内编辑器留的正门，就是 UI Toolkit 运行时 + 自绘 Gizmo，不是 UnityEditor.dll。

引擎工具开发者可以借什么

不一定要抄 Unity 的皮肤。值得抄的是它被教训过之后留下的结构。

1. 即时模式用来点火，保留模式用来长成产品。
原型、调试条、Scene Handle，用即时模式最快。面板一多、要换肤、要给非程序员改，就该有一棵能持久化结构的控件树。Unity 用了十年才把这件事做成官方方向，说明迁移成本真实存在——所以它才留了 IMGUIContainer。

2. 数据模型与视图生命周期分开。
可序列化对象 + Undo + 文件格式，比控件状态更重要。Domain Reload、窗口重建、崩溃恢复，都在逼你承认：UI 是临时的。

3. 用硬边界保护 Player。
Editor 程序集、Editor 文件夹、asmdef 平台开关，看起来烦，却避免「工具代码悄悄进包」。Godot 用 hint 软隔离，Unreal 用模块类型隔离，Unity 用程序集隔离。做自己的引擎时，也要先决定这一刀砍在哪。

4. 布局引擎选一个有文档的模型。
Yoga / Flexbox 让停靠、工具栏、自适应面板有公共语言。自研「每个控件 setRect」在第三个窗口就会崩溃。

5. 搜索和 Overlay 是规模化之后的编辑器 UX。
菜单会满。把「找到任何东西」做成平台能力，比再加一个顶栏按钮更有杠杆。视口上的轻量 Overlay，则避免工具把 Scene 挤没。

6. 图编辑要当平台，而不是每个工具重写一遍。
GraphView 生态已经证明：Shader、VFX、对话、行为树最后都会要节点图。Graph Toolkit 还在实验，方向是对的——内部工具和第三方工具共用宿主。

7. 不要把启动器技术栈和编辑器技术栈混为一谈。
Hub 用网页壳管安装，Editor 用原生引擎管视口，是合理分工。把 Scene 视口塞进 Chromium，会把输入、GPU、帧循环全部交给一个并非为此设计的运行时。工具进程可以 Electron；实时 3D 编辑器通常不行。

8. 允许旧系统以岛屿形式活着。
完美重写很少发生。能嵌 IMGUI 的 UITK，比「截止日期前全部迁移」更像能交货的架构。

收束

Unity 6 的 Editor，已经不是「一个巨大的 OnGUI」。它是原生窗口栈上的托管 IDE：新界面走 UI Toolkit（Yoga、UXML、USS、绑定），旧界面以 IMGUI 岛屿残留，资源与撤销走序列化管线，扩展被程序集挡在 Player 之外。

和 Godot 比，Unity 刻意不让游戏 UI 与编辑器 UI 成为同一套控件——但 Unity 6 的 UI Toolkit 正在把 控件树 做成两边都能挂的那一层。和 Unreal 比，Unity 把扩展写成 C# 脚本而不是 C++ 模块，发布时同样把门关死。

游戏内编辑器因此有一条清楚的路：用运行时 UITK 画出「很像 Editor」的面板，Gizmo 自己画、自己拾取。不能走的路，是把 EditorWindow、Handles、PropertyField 原样打进包。面板可以像；轴和 Inspector 的自动化，要自己付实现成本。若你正在做这类工具，更值得先定的是：选择集、撤销栈、关卡存档，以及一套放在运行时程序集里的控件——而不是如何把 Unity Inspector 嵌进 Game 视图。

注释

1. Unity 6.7 Manual，CoreCLR scripting back end (Experimental)。说明 CoreCLR 桌面 Player 仍为实验状态，Editor 在 6.x 仍使用 Mono。 ↩

2. Unity Manual，Object。说明托管 C# 对象与原生 C++ 对象存在对应关系。 ↩

3. Unity Technologies，UnityCsReference。公开的 C# 参考源码，含 ContainerWindow、EditorWindow、HostView、DockArea 等 Editor 窗口栈实现。 ↩ ↩²

4. Unity Discussions，Unity Hub doesn't open（macOS 崩溃日志）。日志路径出现 Unity Hub.app/Contents/Resources/app.asar 与 electron-json-storage，表明 Hub 以 Electron 方式打包；这是社区日志证据，不是 Unity 的产品白皮书声明。 ↩

5. Unity 6 Manual，Comparison of UI systems in Unity。给出 Unity 6.6 对 Editor / Runtime 的推荐与备选 UI 系统。 ↩ ↩²

6. Unity 6 Manual，Create custom Editor Windows with IMGUI。说明 EditorWindow + OnGUI 的 IMGUI 扩展方式，并推荐新工具改用 UI Toolkit。 ↩

7. Unity 6 Manual，Introduction to UI Toolkit。说明 UITK 的网页启发、保留模式、UXML/USS，以及 Editor 与 Runtime 共用同一套元素体系。 ↩ ↩²

8. Unity 6 Manual，Position element with the layout engine。官方写明布局原则来自 Yoga，并实现 Flexbox 子集。 ↩

9. Unity Manual，Create a custom Editor window with C# script。说明 CreateGUI、rootVisualElement，以及 Domain Reload 后必须重建 Visual Tree。 ↩

10. Unity 6 Manual，Migrate from Immediate Mode GUI (IMGUI) to UI Toolkit。对比 OnGUI / CreateGUI，并说明可用 IMGUIContainer 在 UITK 树中嵌 IMGUI。 ↩

11. Benoit Dupuis，Unity，2024-11-19，Unity 6 UI Toolkit: News and Updates。官方介绍运行时数据绑定、自定义控件特性化、网格/文本生成与深层布局等 Unity 6 改进。 ↩ ↩²

12. Unity Manual，Introduction to UXML。区分 UnityEngine.UIElements 与 UnityEditor.UIElements 两个命名空间。 ↩

13. Unity Manual，Format of text serialized files。说明场景等资源以 Unity 的 YAML 子集文本序列化。 ↩

14. Unity，Unity 2019.3: Updates & improvements to Unity Editor workflows。支撑新 Editor 视觉、UI Builder 预览、Quick Search，以及 Package Manager 安装 Git / Asset Store 资源。 ↩ ↩²

15. Unity Manual，New in Unity 6.0。列出 Overlay、Scene 上下文菜单 UITK 化、运行时绑定、UxmlElement 等并入 Unity 6 的变化。 ↩ ↩²

16. Unity Discussions，Unity’s Graph Toolkit (Experimental), AVAILABLE TODAY in Unity 6.2。官方宣布 Graph Toolkit 作为 Unity 6.2 实验包发布。 ↩

17. Unity Manual，Special folder names。说明 Editor 文件夹中的脚本只在编辑器运行，不会进入构建。 ↩

18. Unity Manual，Create a Custom Inspector。明确自定义 Inspector 必须放在 Editor 文件夹或 Editor-only 程序集，否则独立构建会失败。 ↩

19. Godot Documentation，Introduction to editor development。官方说明编辑器是用 C++ 写的 Godot 项目，使用引擎自己的渲染器与 UI，不依赖 GTK/Qt。 ↩

20. Godot Documentation，Running code in the editor。说明 @tool 与在编辑器中运行脚本的方式。 ↩

21. Epic，Slate UI Framework、Using Slate in a Project、Creating User Interfaces With UMG and Slate。官方将 Slate 作为引擎 UI 编程框架，游戏项目可通过模块依赖使用；UMG 是建立在其上的可视化 UI 层。 ↩

22. Unreal Engine Documentation，Editor Utility Widgets。说明 EUW 基于 UMG，专门用于修改 Editor UI。 ↩

23. Unreal Engine Documentation，Setting up Editor Modules for Customizing the Editor。支撑用独立 Editor 模块扩展编辑器、避免把编辑器模块打进非 Editor 目标。 ↩

24. Unity 6 Manual，Panel Settings properties reference。说明运行时用 PanelSettings / UIDocument 绘制 UXML，并可指定主题 USS、Overlay 或世界空间。 ↩

25. Unity 6 Manual，Introduction to IMGUI。说明 IMGUI 可在游戏与 Editor 扩展中使用，但一般不推荐作为正式玩家 UI。 ↩

26. Unity Scripting API，Handles。PositionHandle 等 Scene 手柄位于 UnityEditor 命名空间。 ↩

27. Unity Scripting API，Gizmos、MonoBehaviour.OnDrawGizmos。官方写明 Gizmo 用于 Scene 视口的可视化与调试。 ↩

28. Unity Manual，Integrate Unity into Windows applications。说明 Unity as a Library 嵌入的是 Runtime / Player，不是 Editor。 ↩