企业官网建设流程全解析

《透视 ImGui：从底层原理到面试通关》第一讲：IMGUI 的灵魂 —— 架构博弈与 ID 机制

做图形界面做到一定阶段，你一定会碰到一个绕不开的名字：Dear ImGui。不管你是做游戏编辑器、工具链、美术向的调试面板，还是做那种“只要能用就行”的内部工具，ImGui 几乎成了事实标准。很多人说它简单，调几个 API 就能出窗口出控件，但其实“用起来简单”和“理解它为什么简单”是两码事。面试的时候，面试官问一句“ImGui 的 ID 机制到底怎么工作的”，很多人就卡住了。再问一句“它为什么要用即时模式渲染，跟 Qt 那种保留模式相比，优劣在哪”，能答清楚的人就更少了。

这篇文章就是系列的第一讲，我们直接拆掉 ImGui 的两个灵魂支柱：架构博弈和ID 机制。读完你应该能回答这几个问题：ImGui 凭什么能做到每帧重建界面、它的状态放在哪里、控件为什么需要 ID、PushID 到底在干什么、哈希碰撞怎么办。这些不是面试八股，而是你真正常年写工具 UI 时一定会踩到、一定会用到的底层知识。

1. 架构博弈：即时模式凭什么敢跟保留模式叫板

1.1 两种渲染哲学的正面碰撞

要理解 ImGui，你得先理解它跟 Qt、WPF 这类传统 UI 框架的根本差异。传统框架叫保留模式（Retained Mode），它的核心思想是：你创建一棵控件树，这棵树常驻内存，所有控件的状态、层级、布局都保存在这棵树上。用户点击一个按钮，框架去树上找这个按钮，改它的状态，再重绘它。

ImGui 走的是即时模式（Immediate Mode），核心思路完全不同：没有常驻的控件树，每一帧从零开始重新构建界面。你在代码里写：

if (ImGui::Button("点击我")) { // 按钮被按下的逻辑 }

这段代码每帧都会执行。每一帧，ImGui 都会重新计算这个按钮的位置、大小、颜色，重新判断鼠标是否悬停在它上面，重新决定它是否被点击。按钮不是一个“对象”，而是一段每帧执行的指令。

用一句话概括两者的区别：保留模式是“我创建了一个控件，它一直存在”；即时模式是“我每帧都在画这个控件，画完这帧它就没了”。ImGui 的做法，相当于把整个 UI 视为一帧渲染的副产物，而不是一个持久的场景图。

1.2 为什么游戏行业率先拥抱即时模式

ImGui 最早的爆发场景是游戏开发。为什么？因为游戏引擎本身就是一个每帧运行的循环：每帧读输入、更新逻辑、渲染画面。ImGui 的即时模式跟这个循环天然同频。你不需要在引擎里额外挂一个 UI 框架的更新钩子，只需要在渲染帧的某个位置调用 ImGui 的 NewFrame 和 Render，然后一切水到渠成。

但更本质的原因在于成本问题。用 Qt 做调试工具，你要么用 QWidget 搭一套完整的界面，要么用 QML 写一堆描述文件，加上信号槽连接、数据模型映射、事件过滤器……这套东西对一个“临时看一眼数据”的面板来说太重了。ImGui 的哲学是：你只描述“这个面板长什么样、要操作什么”，剩下的交给我。你甚至不需要维护控件对象的生命周期，因为本来就没有对象。

当然，天下没有免费的午餐。即时模式的代价也很明显：每帧都要重新做布局计算。一个复杂的 ImGui 界面，布局耗时会随控件数量线性增长，控件多了确实会变慢。另外，因为控件没有常驻身份，跨帧的状态（比如滚动条位置、输入框内容）必须靠用户手动维护或 ImGui 内部存储，这就引出了 ID 机制的问题。归根结底，这是一个“开发效率和运行效率”的交换，在工具开发场景里，几乎总是倾向于开发效率。

1.3 状态存储的秘密：窗口、滚动与输入框都藏在哪儿

既然控件每帧都重建，那 ImGui 怎么记住窗口位置、滚动条偏移、输入框的文字？答案是：它有一个全局的状态存储区，本质是一个大数据表。ImGui 为每个窗口、每个控件维护一个键值对，键就是控件的 ID，值就是状态数据。窗口的位置和大小、滚动偏移量、折叠状态、输入框的缓冲区、选中项索引，全都在这个表里。

这个表本身就是一个大哈希表，键是ImGuiID（32 位无符号整数），值是一个void*或特定结构体。每帧开始，ImGui 按你代码里写的顺序，一个控件一个控件地“重建”。重建时会算控件的 ID，去表里查有没有旧状态。有，就加载；没有，就用默认值。这就是为什么同一帧里同一个 ID 的控件只能出现一次，如果同一个 ID 出现两次，后一个会把前一个的状态覆盖掉，表现出来就是两个控件互相抢状态。

理解了这一点，你就理解了 ImGui 的“记忆”机制：它不靠对象存活，而靠哈希表里的像素级状态。窗口拖动一下，记录的只是一个矩形坐标；列表滚动一下，记录的只是一个浮点偏移。一切持久状态，归根结底都是数据表中的若干数字。

2. ID 机制：ImGui 的灵魂，也是面试官最爱挖的坑

2.1 为什么需要 ID：没有对象的框架如何区分控件

现在关键问题来了：ImGui 每帧都在创建控件，这些控件没有对象身份，那它怎么区分两个不同的按钮？答案就只能靠 ID。ID 是控件的唯一标识，是状态存取和事件路由的依据。

如果不用 ID，会出现什么状况？你写一个循环，生成 10 个按钮，每个都叫“按钮”。ImGui 算出来这 10 个按钮的 ID 完全一样，它就会认为这是同一个按钮，散落在不同位置的 10 个控件共用同一个状态槽。结果就是：悬停状态互相覆盖，点击状态错乱，最经典的故障是“第 3 个按钮被点击，第 1 个按钮的响应逻辑触发”，或者“滚动其中一个列表，另一个列表跟着动”。

所以 ID 的使命很明确：让每一个控件在同一帧内拥有唯一身份。注意限定语是“同一帧内”，因为跨帧的话，ID 只影响状态读取，如果状态槽被两个控件以某种时序共用，必然出bug。

2.2 ID 到底是什么：从标签字符串到 32 位哈希

ImGui 的控件 ID 计算有一个清晰的优先级链。以ImGui::Button为例，如果你只传了一个字符串标签，比如ImGui::Button("保存")，它做的事情分几步：

1. 取出当前代码位置的 ID 堆栈（后面细说）。
2. 把栈顶 ID 作为“父 ID”。
3. 将标签字符串“保存”做哈希，得到一个 32 位哈希值。
4. 将“父 ID”和这个哈希值再做一次混合哈希，得到最终 ID。

这就解释了为什么ImGui::Button("保存")和ImGui::Button("另存为")是不同按钮：它们的字符串哈希值不同，最终 ID 不同。

但你要是写：

const char* names[] = {"保存", "打开", "导出"}; for (int i = 0; i < 3; i++) { ImGui::Button(names[i]); }

这里三个按钮的标签分别是“保存”“打开”“导出”，字符串不同，哈希值不同，ID 自然不同，不会出问题。真正出问题的场景是标签字符串相同的时候，比如：

for (int i = 0; i < 10; i++) { ImGui::Button("选项"); }

十个按钮标签都是“选项”，哈希值相同，ID 相同，十兄弟共用一个状态槽，互相覆盖，必炸。

那解决办法是什么呢？官方 API 给了一个带 ID 后缀的重载：

ImGui::Button("选项##1"); ImGui::Button("选项##2");

##后面的内容叫“ID 后缀”，它不参与显示，但参与哈希计算。也就是说，按钮显示的都是“选项”，但它们的 ID 分别是“选项##1”“选项##2”的哈希结果，互不相同。

2.3 ID 堆栈的本质：一个整形数组的压栈与弹栈

PushID和PopID是理解和应对复杂控件树的钥匙。它们的本质非常简单：ImGui 内部维护了一个ImVector<ImGuiID>数组，PushID把一个新 ID 压进去，PopID弹出来。每次计算控件的最终 ID 时，会用当前栈里所有的值参与混合哈希。

为什么要用栈而不是直接在标签上做文章？因为随着界面复杂化，很多控件的标签是在运行时拼出来的。比如你在遍历一个结构体数组，每个结构体有个名字，你希望以这个名字为维度确定唯一 ID：

struct ItemData { std::string name; int value; }; std::vector<ItemData> items = ...; for (auto& item : items) { ImGui::PushID(item.name.c_str()); // 按名字压栈 ImGui::SliderInt("数值", &item.value, 0, 100); ImGui::PopID(); }

这里如果不用 PushID，两个 name 不同的 item 会由于 SliderInt 的标签都是“数值”，导致共用一个状态槽。而 PushID 之后，控件 ID 会带上 item.name 的哈希，自然不同。

更有意思的是PushID支持多种类型，除了字符串，还能传int、指针等。比如遍历一个指针数组，你可以直接把指针压栈：

for (auto* ptr : pointers) { ImGui::PushID(ptr); // 指针值作为 ID 的一部分 if (ImGui::Button("删除")) { /* ... */ } ImGui::PopID(); }

因为每个指针地址不同，哈希值基本不会一样，这比拼一个“删除第 N 个”的字符串靠谱得多——万一增删导致索引变化，字符串和实际对象的映射会飘，而指针永远指着那个对象。

2.4 哈希的细节：不是简单的字符串哈希

ImGui 的哈希实现不是随便调一个std::hash<std::string>，那是实现相关的，跨平台跨版本都不一致。ImGui 用自己的哈希函数，把字符串、整数、指针统统折算成 32 位 ID。

核心算法类似 FNV-1a 的变种，但 ImGui 用的是它自己封装的ImHashStr和ImHashData。ImHashStr逐字符处理字符串，每一步做一次乘法加异或，得到一个无符号整数。ImHashData处理任意内存块，比如传入一个 int、一个指针，都能折算成哈希值。

有意思的是，ImGui 的哈希算法里还藏了一个“种子（seed）”机制。混合父 ID 和子标签时，父 ID 作为种子传给子标签的哈希函数，这样即使两个子控件标签相同，父 ID 不同，最终 ID 也不同。这就是同一帧内 ID 唯一性的保障基础。

哈希碰撞的概率理论上存在，32 位空间大约 40 亿个值，碰上两个字符串哈希到同一个值，概率极低，但不是零。ImGui 官方对这个问题的态度是“接受这个概率，不值得为它增加防御代码”。实际工程里，你更可能遇到的是逻辑上的 ID 冲突（比如标签忘了加##、循环里忘了 PushID），而不是真的撞哈希。

3. 从零手写一个带 ID 管理的 UI 内核：比读源码管用

3.1 用二百行代码还原 ImGui 的核心回路

看理论容易晕，最好的办法是亲自拆一个简化实现。我在这里写一个极度简化的 ImGui 式框架核心，重点展示 ID 计算、状态存取和布局三块。这是我从一个模拟项目X的调试器界面里提炼出来的最小可运行模型，你完全可以在本地跑起来感受一下。

#include <string> #include <unordered_map> #include <vector> #include <functional> struct ImGuiID { unsigned int value; }; // 极度简化的哈希实现（FNV 风格） inline unsigned int hash_str(const char* str, unsigned int seed = 2166136261u) { unsigned int h = seed; while (*str) { h ^= static_cast<unsigned char>(*str++); h *= 16777619u; } return h; } class IDStack { public: void push(const char* s) { ids_.push_back(hash_str(s)); } void push(int v) { ids_.push_back(hash_str(reinterpret_cast<const char*>(&v), 2166136261u) ^ v); } void pop() { ids_.pop_back(); } unsigned int top() const { return ids_.empty() ? 0u : ids_.back(); } // 计算最终 ID：从根到叶子逐层混合 unsigned int compute(const char* label) const { unsigned int h = 2166136261u; for (unsigned int id : ids_) { h ^= id; h *= 16777619u; } h ^= hash_str(label); h *= 16777619u; return h; } private: std::vector<unsigned int> ids_; }; struct ButtonState { bool hovered; bool clicked; }; class UI { public: IDStack id_stack; std::unordered_map<unsigned int, ButtonState> button_states; int cursor_y = 0; int mouse_x = 0, mouse_y = 0; bool mouse_down = false; // 控件：按钮 bool button(const char* label) { unsigned int id = id_stack.compute(label); ButtonState& state = button_states[id]; int x = 10, y = cursor_y, w = 100, h = 20; bool hovered = (mouse_x >= x && mouse_x <= x + w && mouse_y >= y && mouse_y <= y + h); state.hovered = hovered; state.clicked = hovered && mouse_down; // 布局：光标下移 cursor_y += h + 4; // 输出调试信息 printf("按钮[%s] ID=0x%08x 悬停=%d 按下=%d\n", label, id, hovered, mouse_down); return state.clicked; } }; int main() { UI ui; // 模拟一组数据 std::vector<std::string> items = {"项目A", "项目B", "项目C"}; // 模拟几帧 for (int frame = 0; frame < 3; frame++) { printf("===== 第 %d 帧 =====\n", frame); ui.cursor_y = 0; ui.mouse_x = 30; // 模拟鼠标位置， hover 第一个按钮 ui.mouse_y = 10; ui.mouse_down = (frame == 1); // 第二帧按下鼠标 for (auto& name : items) { ui.id_stack.push(name.c_str()); // 关键：按名字压栈 ui.button("详情"); ui.id_stack.pop(); } // 不压栈会怎样？三个按钮 ID 完全相同 // for (int i = 0; i < 3; i++) { ui.button("详情"); } } return 0; }

跑一下这个模型，你会直观看到三点：

1. 三个按钮的 ID 各不相同，因为id_stack.push(name)把名字哈希压进栈了。
2. 每帧按钮的布局位置重新计算，cursor_y从 0 开始，依次累加。
3. 鼠标悬停、点击事件是基于坐标的实时判断，跟控件 “存活” 与否无关。

当然这只是概念模型，ImGui 真身的源码要严谨得多。比如它的ImGuiID是 32 位无符号整数，布局用ImVec2坐标系统，按下和释放分多个阶段的鼠标状态，事件响应还有按键激活优先级……但这些细节都不影响我们抓住它最核心的“ID 计算 + 状态表 + 布局游标”三件套。

3.2 验证 PushID 的必要性：去掉 PushID 会怎样

上面的代码里注释了一行“不压栈会怎样”，我建议你亲自动手试一下。把for循环里的push和pop注释掉，再跑一遍。你会看到什么？3 个按钮的 ID 变成了同一个值，状态表里只有一份状态记录。鼠标 hover 第一个按钮，另外两个也变成 hover；点击第一个，逻辑会在所有按钮的响应里同时触发。这就是典型的 ID 冲突现场。

真实项目里我碰到过一个最典型的案例：某个资产浏览器列表面板，每一行绘制一个“使用次数”输入框，一开始没加 PushID，结果每次输入一个数字，其他行也跟着变。排查了半天，根源就是 ID 冲突——所有输入框的标签都是“使用次数”，状态共用。后来在每行开头加了一个PushID(asset_guid)，问题当场消失。

3.3 控件响应式状态的真相：状态与 ID 是一一对应的

你写if (ImGui::Button("保存"))，为什么只有鼠标点击的那一帧返回 true？因为Button的内部逻辑是：计算当前光标位置的按钮 ID，查状态表。状态表里存了“上一帧鼠标是否悬停”“当前帧鼠标是否按下”这类信息。只有满足“本帧鼠标在按钮范围内且按下，上一帧鼠标也在按钮范围内”这个条件时，Button才返回 true。这是一种“按下动作触发”的语义，不是“按住状态”。

这带来一个诀窍：按钮的响应逻辑不是持续执行，而是只在点击的那一帧执行。如果你需要按住持续触发（比如长按加速），你要么自己维护一个按住状态，要么调整触发逻辑。很多人写工具时忽略这一点，导致“长按按钮只有第一帧生效”的怪问题。

4. 进阶：那几个能让你面试加分的细节

4.1 同帧多窗口：ID 命名空间的分层隔离

一个 ImGui 应用里往往有成百上千个控件，标签形形色色。全局只有一个 ID 栈，很容易浅层冲突，所以 ImGui 用了一套窗口级命名空间来隔离。

每个Begin创建的窗口，内部实现会做一个PushID(window_name)。也就是说，你在“主窗口”里写按钮“保存”，和在“设置窗口”里写按钮“保存”，最终 ID 是不同的，因为它们的父 ID 不同。这也是 ID 栈存在的原因之一：父 ID 像一根根锚，把子控件锚定在不同的命名空间下。

所以，如果两个不同窗口下的控件标签同名，完全不需要慌，ImGui 已经帮你隔离了。但如果同一个窗口下，同一个循环里，你生成了多个同标签控件，那就必须要靠PushID或##后缀手动区分。

4.2 动态列表的 ID 策略：为什么索引不能作为唯一依据

遍历一个动态数组，很多人第一反应是PushID(i)，把循环索引压栈。这在数组内容不变时没问题，但数组是动态的——插入一个元素、删除一个元素、排序一次，索引就全变了。后果是：控件 ID 变了，状态存取也跟着变。比如你有一个输入框列表，之前输入的内容存在索引 1 对应的状态槽里，你在索引 0 前面插入一项，原来索引 1 的内容变成了索引 2，状态槽也跟着飘了，输入框里可能显示历史遗留的文本。

更靠谱的策略是用稳定标识做 ID，比如数据库主键、GUID、项的名称（如果保证不重名）。这也是很多开源项目写 ImGui 列表时的经验。如果连稳定标识都没有，那至少把索引和一个不变因子（比如容器地址、窗口名）组合起来，让状态尽量稳定。

4.3 宽字符标签：别让哈希和编码坑了你

ImGui 默认的*Label处理的是 UTF-8 编码的const char*。中文标签用 UTF-8 没问题，但如果你从某个老旧的编译环境拿到的是宽字符字符串（wchar_t*），直接转成const char*可能会转出乱码，导致哈希值不稳定。解决办法是统一全项目的字符串编码为 UTF-8，或者用 ImGui 的Begin系列接口配合 UTF-8 转换函数处理。另外，##后缀规则对中文同样有效，比如"删除##id_3"和"删除##id_4"不会冲突。

4.4 动态绘制顺序：稳定性是第一原则

ImGui 的 ID 是依赖“绘制顺序 + 标签 + 父 ID”算出来的。这意味着如果你在一个帧里先画 A 再画 B，下一帧先画 B 再画 A，即使标签没变，两个控件的 ID 却会因为绘制顺序不同而产生不同布局路径，导致状态错乱。这一点在实现折叠面板、动态隐藏/显示控件时尤其重要。最好的做法是保持绘制顺序的稳定，不轻易改变条件分支的先后位置。

4.5 多上下文与全局状态：引擎级工具才要知道的事

ImGui 允许创建多个ImGuiContext，每个上下文有自己独立的 ID 栈、状态表和样式表。这在插件化系统里非常实用：每个插件一个上下文，互不干扰。代价是每帧要为每个上下文分别调用NewFrame和Render，而且 ImGui 默认风格的样式数据要各自维护一份。多数工具不需要多上下文，知道有这个概念就够了。

5. 面试考点速查：从“用过”到“讲清”

5.1 经典问题与参考回答模板

把常见的面试问题整理了一下，每一道我都见过真实候选人在这一关翻车。

Q1：ImGui 和传统 UI 框架的本质区别是什么？

回答框架：从渲染模式切入（即时 vs 保留）。说明 ImGui 每帧重建界面、无对象生命周期、状态存在哈希表中。传统框架构建场景图、信号槽、事件轮询。再补一句两者取舍：ImGui 开发效率高、调试方便、与游戏循环同频；但复杂界面布局开销大，屏幕阅读器这类无障碍支持几乎缺失。

Q2：为什么两个同名按钮会冲突，怎么解决？

回答框架：因为 ID 计算只取决于标签哈希和父 ID。画出同样的标签，哈希值相同，状态槽相同。解法有两种：用##后缀让显示与 ID 分离，或者用PushID/PopID引入额外维度使 ID 唯一。

Q3：PushID 和 PopID 背后的数据结构是什么？

回答框架：一个 ID 栈（ImVector<ImGuiID>）。计算控件 ID 时栈内所有值参与哈希混合。PushID压栈，PopID弹栈。如果两者不配对，后续控件的 ID 全部偏移，状态定位错乱。

Q4：ImGui 的渲染流程是怎么一步步完成的？

回答框架：输入收集（鼠标、键盘、游戏手柄）→NewFrame()→ 每帧执行用户代码里的控件布局与交互逻辑 →Render()生成顶点缓冲和索引缓冲 → 由渲染后端（OpenGL / DirectX / Vulkan / Metal）提交绘制。核心思维是“每一帧的界面都是全新生成的”。

Q5：ImGui 的滚动条位置是怎么记住的？

回答框架：通过状态存储表。滚动条位置的浮点值以滚动条控件的 ID 为键存入表里。下一帧重新生成滚动条时，通过 ID 取回位置值，应用到新帧的滚动逻辑。这也是为什么 ID 一旦变化，滚动位置就会“失忆”。

5.2 五个最经典的实战排查技巧

写了一个经验速查表，都是从真实工具开发里提炼出来的：

5.3 避坑要领：这些经验写代码时很难想起来

1. 堆栈不对称问题：PushID 和 PopID 必须严格对称，如果中间有提前 return，务必用 RAII 思想处理，但 ImGui 是 C API 没有 RAII，你可以用局部struct ScopeGuard在析构时自动 PopID。很多人写工具时中途 return 忘了 PopID，后续控件 ID 全部偏移，表现是界面突然“乱套”，定位极其费劲。

2. 控件标签里的##与#规则：ImGui 有特殊规则——单个#是“ID 分隔符”，双##才是“显示与 ID 分离”。"按钮#id1"的显示部分是“按钮”，ID 部分是“id1”；"按钮##id2"的显示部分和 ID 部分也是分离的，但#和##的行为细微差别很容易记混。实际上大多数情况你只用##就够了。记住：##之后的内容只参与 ID 计算，不显示。

3. 控件状态清零：如果你想让某个控件彻底重置状态，直接把它的 ID 块从代码里删掉再重新编译，状态表里那份旧记录就丢失了。但如果 ID 没变，即便你换了一个含义完全不同的控件，它也会沿用旧的滚动位置/选中状态。所以重构界面时，如果担心状态污染，主动给控件换 ID 是最省事的。

4. 随机数做 ID：任何时候不要把随机数当作 PushID 的参数。随机数会导致状态槽每帧都“刷新”，所有持久状态全部失效。真要想用临时值做 ID，可以用ImGui::GetID("某个独一无二的字符串")显式生成稳定 ID。

6. 从架构到面试：一条链路串起来的思维模型

回到系列标题里的“面试通关”这四个字。面试官考 ImGui 相关问题时，并不是真的指望你把源码背得滚瓜烂熟。他们想听的，是你有没有形成一套关于 UI 框架的思维模型。架构博弈那一段讲清了“为什么”，ID 机制那一段讲清了“怎么做”，两者合起来就是一条完整的链路：因为采用了即时模式，所以控件没有常驻对象身份，所以需要 ID 来区隔；因为要用 ID 存取状态，所以有了哈希计算和 ID 堆栈；因为状态和 ID 绑定，所以动态列表必须用稳定标识；因为要稳定，所以工具开发里处处要留意窗口命名、标签后缀、堆栈对称。

这条链路一旦打通，不管面试官从哪一环切入，你都能顺着逻辑讲下去。比如他问“ImGui 怎么处理滚动”，你能从状态存储表答起；他问“为什么会有灵异外观”，你能从 ID 冲突分析出可能的窗口标题重复。归根结底，ImGui 的本质就是一个以“即时生成、哈希索引、状态存储”为核心的小型 UI 系统。它的“小”恰恰是它在工具链里如鱼得水的原因，而理解这个“小”，就是你从“使用者”进阶为“理解者”的转折点。

7. 写在最后：一个老工具人关于 ImGui 的几句实话

做了这么多年编辑器工具，我的个人经验是：ImGui 就像一把锋利的瑞士军刀。用得好的人，能半小时搭出一个好用的资产预览面板；用不好的人，三天后还在跟“为什么两个按钮互相干扰”搏斗。把它为了省事而构建的那套“无对象”模型吃透，是彻底驾驭它的钥匙。

如果你刚刚接触 ImGui，我给你的第一条实操建议就是：像做实验一样搭建一个小项目，故意制造一次 ID 冲突（比如不加 PushID 的连续同标签按钮），亲眼看看那个“按钮互相抢状态”的效果。只有见过坏现象，你才会对好方案有真正的体感。这也是我当年踩坑踩出来的经验，那些只读文档不写代码的人，永远不会理解##后缀的深刻含义。

还有一个珍藏多年的小技巧：如果你某个界面的 ID 布局特别复杂，实在不想手动维护 PushID / PopID，可以考虑把界面拆成多个Begin窗口，每个窗口天然会成为独立命名空间，能规避大量隐性冲突。代价是界面看起来不是一个整体，重活布局组合还需要自己处理。取舍之下，复杂面板拆窗口往往比堆栈长链更好维护。

下一讲我会聊一聊 ImGui 的渲染管线对接：它到底怎么把几千个顶点送到 GPU 手里，又怎么和 OpenGL、DirectX 这些后端接口做适配。这一讲的内容是地基，地基稳了，上面盖什么都踏实。