Qt与Dear ImGui：C++跨平台GUI框架选型与实战对比

1. 项目概述：为什么我们需要跨平台GUI框架？

做C++开发，尤其是涉及到需要和用户交互的桌面应用时，选对GUI框架几乎决定了项目一半的命运。我经历过不少项目，从早期的MFC到后来的wxWidgets，再到如今主流的Qt和新兴的Dear ImGui，每个选择背后都是一堆坑和一堆经验。今天想聊的，就是这两个当前在C++跨平台GUI领域里，风格迥异但都极具代表性的选手：Qt和Dear ImGui。

简单来说，Qt就像一个功能齐全、装修豪华的“精装房”。你拿到手，从门窗、水电到家具家电，一应俱全，甚至还有物业（庞大的社区和商业支持）。用它来开发一个功能复杂、界面标准、需要长期维护的工业软件或商业应用，非常合适。而Dear ImGui则更像一个“毛坯房”或者“自建工具房”。它只给你最核心的墙体结构（一个立即模式的GUI渲染库），里面的布局、装修、管线怎么走，全凭你自己发挥。它特别适合需要深度定制渲染、对性能极其敏感、或者界面需要频繁变动的场景，比如游戏开发中的调试工具、3D建模软件的插件界面，或者任何需要“把GUI画到任何地方”的奇特需求。

对于刚入行的朋友，可能会困惑：我到底该学哪个？对于有经验的开发者，可能在纠结：新项目用哪个更合适？这篇文章，我就结合自己这些年踩过的坑和做的项目，从设计哲学、上手成本、性能表现、适用场景等几个维度，把这两个框架掰开揉碎了讲清楚。目标不是分个高下，而是帮你建立一个清晰的认知地图，知道在什么路口该转向哪个方向。

2. 核心理念与架构设计：两种截然不同的世界观

要理解这两个框架，必须从它们最底层的设计哲学开始。这决定了你写代码的思维方式，也框定了它们能力的边界。

2.1 Qt：基于信号与槽的面向对象“保留模式”GUI

Qt的核心是“保留模式”（Retained Mode）。你可以这样理解：你在代码里创建了一个按钮（QPushButton）对象，这个对象在内存中“保留”了按钮的所有状态（文字、颜色、是否禁用等）。Qt框架内部维护着一个控件树，负责管理这些对象的状态、布局，并在需要时（比如窗口移动、按钮被点击）由主事件循环驱动进行重绘。

它的王牌机制是“信号与槽”（Signals & Slots）。这是一种类型安全、松耦合的对象间通信方式。一个按钮被点击了，它会“发射”（emit）一个clicked()信号；你的业务逻辑函数可以作为一个“槽”（slot），“连接”（connect）到这个信号上。当信号发射时，槽函数就会被自动调用。这种机制让界面逻辑和业务逻辑的解耦变得非常优雅。

// 一个典型的Qt代码片段 QPushButton *button = new QPushButton(“点击我”, this); QLabel *label = new QLabel(“初始文本”, this); // 连接信号与槽：当按钮被点击，就调用lambda函数改变标签文本 connect(button, &QPushButton::clicked, [=]() { label->setText(“按钮被点击了！”); });

这种面向对象和保留模式的架构，带来了极佳的结构性和可维护性。你的界面元素是实实在在的对象，可以通过Qt Designer进行可视化拖拽设计，生成.ui文件，再由uic工具编译成C++代码。这对于开发复杂的、表单式的企业级应用（如数据库管理前端、配置工具）来说，生产力极高。所有的控件、布局、样式都有成熟的、文档齐全的类支持。

注意：Qt的信号与槽虽然强大，但连接管理不当会导致内存泄漏或无效调用。特别是使用lambda表达式或涉及对象生命周期时，要特别注意在对象销毁前断开连接，或使用QObject::connect的五参数形式管理上下文对象。

2.2 Dear ImGui：基于立即渲染模式的“过程式”GUI

Dear ImGui走了一条完全相反的路：“立即模式”（Immediate Mode）。它没有“按钮对象”的概念。每一帧，你都需要在代码里“描述”一遍当前这一帧的界面应该长什么样。

// 一个典型的ImGui代码片段（在渲染循环中） ImGui::Begin(“我的窗口”); if (ImGui::Button(“点击我”)) { // 按钮在这一帧被点击了 buttonClicked = true; } if (buttonClicked) { ImGui::Text(“按钮被点击了！”); } ImGui::End();

注意看，这里没有创建Button对象，也没有Label对象。ImGui::Button(“点击我”)这个函数调用，同时完成了三件事：1. 计算按钮的几何形状；2. 处理输入（鼠标点击、悬停）；3. 渲染按钮。它的返回值就是一个简单的bool，告诉你这一帧这个按钮是否被按下了。状态（比如buttonClicked）完全由用户代码自己管理。

这种模式带来了几个革命性的特性：

1. 极简的集成：ImGui不关心你的渲染后端是OpenGL、DirectX、Vulkan还是Metal，也不关心你的窗口系统是GLFW、SDL还是原生的Win32/ Cocoa。它只提供一堆绘制顶点和纹理的命令，你需要自己实现一个简单的绑定层将这些命令转换到你的图形API上。官方已经为几乎所有主流组合提供了后端示例。
2. 无状态的自由：界面结构完全由你的代码流决定。你可以用if/else、for循环等任何C++逻辑来动态生成界面。今天按钮在左边，明天根据条件它就可以跑到右边，代码表达非常直接。
3. 接近零的初始化开销：没有复杂的控件树构建过程，启动速度快得惊人。
4. 与渲染引擎的深度集成：因为绘制命令是你控制的，你可以轻松地将ImGui界面渲染到纹理（Texture）上，然后把这个纹理贴到3D场景中的一个模型表面，实现“世界空间UI”。这在游戏开发中非常有用。

当然，代价就是所有高级功能（如复杂的布局、表格、树形控件）都需要你自己基于基本的绘图原语去搭建，或者寻找第三方扩展库。它更像一个GUI“工具箱”而非“套件”。

3. 开发体验与生产力对比：从“开箱即用”到“深度定制”

理念的不同，直接导致了开发体验的天壤之别。我们可以从项目初始化、界面构建、数据绑定、工具链支持几个方面来感受。

3.1 项目搭建与“Hello World”

Qt：通常你会使用Qt Creator这个强大的IDE。新建一个Qt Widgets Application项目，向导会帮你生成main.cpp、mainwindow.h/cpp、*.pro项目文件。你几乎不用写一行代码，直接点击运行，就能看到一个带菜单栏、工具栏和中心区域的窗口。如果你想手动集成，通过CMake或qmake管理依赖和构建，步骤也相对标准，但需要正确链接Qt的核心模块（如Core, Gui, Widgets）。跨平台编译通常意味着在每个目标平台都要安装对应版本的Qt SDK或自己从源码编译。

Dear ImGui：没有安装程序，没有向导。你需要做以下几件事：

1. 从GitHub下载imgui.cpp和imgui.h等核心文件。
2. 选择并集成一个后端（例如imgui_impl_glfw.cpp+imgui_impl_opengl3.cpp）。
3. 在你的渲染循环中，正确调用ImGui的帧开始、构建界面、帧结束、渲染命令提交的函数。
4. 实现字体加载和纹理管理。

这个过程对于新手可能有些吓人，但一旦跑通第一个例子，后续就都是一样的模式。它的“项目搭建”本质上就是“把几个源文件拖进你的工程里”。跨平台性极好，因为你的代码不依赖平台特定的GUI库，只依赖你选择的后端（如GLFW/SDL），而这些库本身也是跨平台的。

3.2 界面构建与工具支持

这是两者差异最大的地方。

Qt的优势在于其成熟的可视化设计工具Qt Designer。你可以像拼图一样拖放按钮、列表、输入框，用布局管理器自动排列，直观地设置属性，并通过Qt的样式表（QSS，一种类似CSS的机制）来美化界面。设计好的界面保存为.ui文件，在编译时自动生成C++代码。这种“所见即所得”的方式，对于构建数据录入、信息展示等传统桌面界面，效率是碾压级的。此外，Qt提供了海量的内置控件，从基础的按钮到复杂的图表（Qt Charts）、3D视图（Qt 3D）、Web引擎（Qt WebEngine），几乎涵盖了所有你能想到的需求。

Dear ImGui的界面构建是纯代码驱动的。所有的窗口、控件位置都是通过函数调用在代码中定义的。这听起来很原始，但却带来了无与伦比的灵活性和动态性。你的界面逻辑可以紧密地和你应用程序的状态绑定在一起。

// 动态生成一个属性编辑器 for (auto& property : object.properties) { ImGui::Text(“%s:”, property.name.c_str()); switch (property.type) { case PropertyType::Float: ImGui::DragFloat(property.name.c_str(), &property.value.floatValue, 0.1f); break; case PropertyType::Color: ImGui::ColorEdit3(property.name.c_str(), &property.value.colorValue[0]); break; // ... 其他类型 } }

这种模式特别适合开发工具软件，因为工具软件的界面本身就是程序逻辑的直观反映。没有.ui文件需要同步，界面改了就是代码改了，版本管理清晰。但缺点也很明显：调整像素级布局、实现复杂的多列对齐，需要手动计算位置，比较繁琐。社区也有一些布局辅助库（如ImGuiLayout）和扩展控件库（如ImGuiColorTextEdit），但生态和Qt完全不在一个量级。

3.3 数据绑定与状态管理

Qt使用模型/视图（Model/View）架构来处理数据与显示的分离。例如，你要显示一个文件列表，不会直接往QListWidget里塞字符串，而是创建一个继承自QAbstractItemModel的模型类，在里面管理实际的数据。视图（QListView）会自动监听模型的变化并更新显示。这种架构对于显示大型、结构化数据（如数据库查询结果）非常高效和优雅。状态由各个控件对象和自定义的数据模型共同管理。

Dear ImGui是无状态的，状态管理完全交给用户。这既是自由也是负担。简单的状态（如一个布尔开关、一个浮点数）可以直接用局部变量。复杂的状态就需要你自己设计数据结构来管理，ImGui只负责读取和修改这些数据。这种直接性使得调试非常方便，你可以在任何地方修改状态并立即看到界面反馈，但大型应用的状态管理需要你引入类似MVC的模式来组织代码，否则容易变得混乱。

4. 性能、资源与部署考量：轻量化与重型化的抉择

选择框架时，性能和应用体积往往是硬性指标。

4.1 运行时性能与内存占用

Qt作为一个完整的应用框架，其运行时开销是显著的。启动时需要初始化庞大的元对象系统、事件循环、样式引擎等。一个最简单的空Qt Widgets应用，内存占用可能在几十MB到百MB级别（取决于链接方式和编译器优化）。它的渲染通过平台原生的绘图API（如Windows上的GDI/Direct2D，macOS上的Core Graphics）或自身的渲染引擎（如RHI）完成，通常不是性能瓶颈，但在需要每秒60帧以上高频率、大量动态元素更新的场景下（如实时数据仪表盘），需要精心优化，避免频繁的布局计算和重绘。

Dear ImGui的性能特点非常鲜明：

• CPU端：每一帧都需要重新构建整个界面的绘制命令列表（Draw List）。对于静态界面，这看起来是浪费。但实际上，由于ImGui的代码极其紧凑，且避免了复杂的对象管理和事件分发，这个重建过程非常快。在典型的工具界面下（几百个控件），每帧的CPU时间通常小于1毫秒。
• GPU端：ImGui将所有界面的绘制合并为尽可能少的绘制调用（Draw Call）。它通常只生成一个或少数几个顶点/索引缓冲区，并使用一张包含所有字形和图标的小纹理图集（Atlas）。这使得它的GPU开销极低，几乎可以忽略不计。
• 内存：一个集成了ImGui的应用程序，其内存增量通常只有几百KB到几MB，因为它不创建永久的控件对象。

实操心得：ImGui的性能优势在界面频繁变化时尤为突出。比如一个实时显示传感器数据的监控窗口，数据每秒更新几十次。用Qt，你需要调用setText()，可能触发重绘和布局计算。用ImGui，你只是在下一次帧循环中传入了新的字符串值，重建命令列表的开销恒定且很低。但对于一个拥有几十个复杂标签页、数千个静态控件的配置对话框，Qt的首次构建可能更慢，但之后因为状态被保留，交互响应可能更灵敏；而ImGui则需要每帧重建这数千个控件的命令，CPU压力会增大。不过在实际中，这种巨型静态界面很少见。

4.2 应用体积与依赖

Qt的应用体积一直是个痛点。即使用静态链接并剥离调试符号，一个简单的控制台程序加上Qt Core和Gui模块，也很容易超过10MB。如果使用了更多模块（如Network, Multimedia），体积会迅速膨胀。动态链接可以减小可执行文件，但需要随应用分发对应的Qt DLL（Windows）或Framework（macOS），部署包依然不小。商业应用还需要考虑Qt的许可证（LGPL要求动态链接或提供对象文件，商业版则需付费）。

Dear ImGui在这方面是极致的轻量。核心库只有几个头文件和源文件，编译后体积增加极小。它没有任何外部依赖（除了你选择的图形和窗口后端），部署极其简单，几乎就是“把exe扔过去就能跑”。这对于开发需要内嵌到其他大型软件中的工具、插件，或者对分发体积有严格要求的场景（如一些独立游戏），是巨大的优势。

4.3 部署与跨平台一致性

Qt的跨平台能力是其立身之本。“一次编写，到处编译”的理念执行得很好。但“一致性”有两面性：

• 优点：Qt在不同平台上会尽量使用原生风格（通过Fusion等样式也可以统一为自定义风格），让应用看起来像是系统原生的。行为也经过适配，符合各平台习惯。
• 挑战：为了达到这种一致性，Qt在底层做了大量抽象和封装。当你遇到一个平台特有的bug或需要调用原生API时，可能需要使用#ifdef进行条件编译，或者使用Qt提供的平台抽象类（如QWindow），这有时会引入复杂性。

Dear ImGui提供的是视觉和交互的一致性。因为界面是自己绘制的，它在Windows、macOS、Linux上看起来和操作起来完全一样。这对于开发工具类软件是优点，因为用户希望操作逻辑统一。但对于面向大众的消费级应用，这种“非原生”感有时会被认为不够精致。不过，ImGui的高度可定制性允许你通过修改样式（颜色、圆角、字体）来打造独特的视觉风格，甚至可以模仿原生系统的外观（虽然比较费力）。

5. 适用场景与选型指南：没有最好，只有最合适

经过上面的对比，我们可以清晰地画出它们的势力范围。

5.1 坚定选择 Qt 的场景

1. 开发传统桌面应用程序：这是Qt的主场。需要复杂的窗口管理（多文档界面MDI、停靠窗口）、丰富的标准控件（表格、树形视图、富文本编辑）、完整的键盘导航和支持无障碍访问的应用。例如：办公软件、集成开发环境（IDE）、音视频编辑软件、CAD/CAM软件。
2. 需要快速原型开发或对UI设计效率要求极高：Qt Designer能极大加速界面布局和迭代。产品经理或设计师可以通过设计器快速产出界面原型。
3. 项目庞大，需要清晰的架构和长期维护：Qt的面向对象设计、信号槽机制、模型/视图架构，为大型项目提供了良好的工程实践基础。其成熟的文档、庞大的社区和商业支持（Qt Company）能降低长期维护风险。
4. 需要用到Qt生态中的其他强大模块：例如，你需要内嵌一个功能完整的浏览器（Qt WebEngine），需要操作蓝牙设备（Qt Bluetooth），或者需要一套现成的图表解决方案（Qt Charts）。直接使用Qt的这些模块比寻找第三方库并集成要省心得多。

5.2 坚定选择 Dear ImGui 的场景

1. 游戏开发工具链：这是ImGui诞生的土壤。游戏引擎的编辑器、调试器、性能分析器、关卡编辑器等，需要深度集成到渲染管线中，界面需要随游戏视图实时更新，并且要求极低的输入延迟。ImGui是事实上的标准。
2. 3D图形/科学可视化软件的辅助界面：例如，在你自己写的渲染器、物理模拟器或数据可视化程序中，需要一些参数调节面板、摄像机控制窗口。ImGui可以无缝地和你自己的OpenGL/Vulkan/DirectX渲染代码结合在一起。
3. 需要高度定制或非标准界面的应用：你想做一个完全圆形的控制盘、一个节点式编程界面、或者一个模仿物理旋钮的控件。用Qt实现这些需要自定义绘制（QPainter），可能很复杂。而ImGui从底层就是让你“画”界面，实现这种定制反而更直接。
4. 嵌入式或资源受限环境：在一些非x86的嵌入式平台上，内存和存储空间紧张，无法承载完整的Qt运行时。ImGui极小的体积和简单的依赖使其成为可行选项。
5. 快速迭代的内部工具：当你需要为某个特定任务快速开发一个一次性或短期使用的工具时，ImGui的“代码即界面”模式允许你边写逻辑边构建界面，开发调试循环非常快。

5.3 混合使用与折中方案

现实中的选择不总是非此即彼。有些聪明的做法是混合使用：

• 主应用用Qt，调试/工具面板用ImGui：在一个大型的Qt应用中，你可以将ImGui集成到某个OpenGL Widget（QOpenGLWidget）中，用于渲染一些需要高性能实时更新的可视化调试信息，比如一个3D场景的调试视图。
• 使用Qt for Python (PySide6)：如果你喜欢Qt的完备性但又觉得C++开发较慢，可以考虑使用PySide6。它提供了Qt的全部功能，但用Python开发，能极大提升工具开发效率。而性能关键的核心部分仍可用C++实现。
• 关注其他轻量级选项：如果你喜欢ImGui的理念但需要更多现成的控件，可以关注基于ImGui的扩展项目，如ImGui的ImPlot（绘图库）、ImNodes（节点编辑器）。或者评估其他立即模式GUI库，如Nuklear（比ImGui更小）。

6. 常见问题与实战避坑指南

在实际项目中切换或使用这两个框架，会遇到一些典型问题。这里记录一些我的踩坑经验。

6.1 Qt 开发中的典型“坑”

1. 内存管理：Qt使用父子对象（parent-child）机制进行内存管理。当父对象被销毁时，会自动销毁其所有子对象。这很方便，但也容易导致问题。比如，如果你将一个局部变量窗口的父对象设置为nullptr，又忘了手动delete，就会内存泄漏。反之，如果错误地设置了父对象，可能导致对象被意外提前销毁。使用智能指针（QSharedPointer,QScopedPointer）是现代Qt代码的好习惯。
2. 多线程：Qt的GUI组件不是线程安全的。所有对界面元素的更新都必须在主线程（即GUI线程）中进行。如果从工作线程更新UI，必须使用信号槽（Qt::QueuedConnection连接方式）或QMetaObject::invokeMethod来将调用“投递”到主线程事件队列。忘记这点是导致程序随机崩溃的常见原因。
3. 样式表（QSS）性能：QSS非常强大，但滥用会影响性能。特别是对可滚动区域内的众多项目使用复杂选择器，会导致滚动时的重绘性能下降。尽量使用ID选择器，并避免在paintEvent中动态设置样式。
4. 部署时的依赖地狱：在Windows上使用动态链接，需要借助windeployqt工具来收集所有必需的DLL。但即使这样，有时还是会漏掉某些插件（如图像格式插件qjpeg.dll、平台插件qwindows.dll）。务必在目标系统（或干净的虚拟机）上进行充分的部署测试。

6.2 Dear ImGui 集成与使用中的挑战

1. 输入处理冲突：ImGui需要独占处理鼠标和键盘输入。你必须确保在ImGui处理完输入后，阻止这些输入事件继续传递给你自己的3D摄像机控制器或其他逻辑。通常在后端的实现文件（如imgui_impl_glfw.cpp）中，会有设置回调函数来“偷走”输入事件的代码。如果集成后发现鼠标点击UI时，背后的3D场景摄像机也在乱动，就是这里没处理好。
2. 字体管理与图标集成：ImGui默认使用Proggy字体，很丑。加载TTF字体文件是必须的。但要注意，中文字体文件很大，全加载会占用大量显存。通常的解决方案是只加载所需字符范围的字体（ImFontGlyphRanges），或者使用字体合并工具。添加自定义图标（如FontAwesome）也需要将图标打包成纹理图集，并正确设置UV坐标。
3. 界面状态持久化：ImGui本身不保存窗口位置、大小、折叠状态。你需要手动调用ImGui::SaveIniSettingsToMemory()和ImGui::LoadIniSettingsFromMemory()来保存/加载这些状态到磁盘。很多新手会忘记这个功能，导致每次打开工具窗口都要重新调整布局。
4. 复杂布局的实现：实现一个类似属性网格（Property Grid）那样整齐排列“标签-控件”的布局，需要手动计算文本宽度和对齐。虽然ImGui提供了ImGui::Columns()等辅助函数，但相比Qt的布局管理器，还是需要更多的手动计算。社区库ImGuiLayout或ImGuiKnobs（用于旋钮）可以解决部分问题。

6.3 选型决策速查表

为了更直观，我将核心决策因素总结成下表：

7. 从零开始：两个框架的极简入门示例

最后，让我们用最简短的代码，分别感受一下用Qt和Dear ImGui创建一个带按钮的窗口是什么感觉。这能最直观地体现两者的思维差异。

7.1 Qt 极简示例 (使用 CMake)

CMakeLists.txt:

cmake_minimum_required(VERSION 3.16) project(HelloQt) set(CMAKE_CXX_STANDARD 17) set(CMAKE_AUTOMOC ON) # 自动处理Qt的元对象编译 find_package(Qt6 REQUIRED COMPONENTS Core Gui Widgets) add_executable(HelloQt main.cpp) target_link_libraries(HelloQt Qt6::Core Qt6::Gui Qt6::Widgets)

main.cpp:

#include <QApplication> #include <QPushButton> #include <QMessageBox> int main(int argc, char *argv[]) { QApplication app(argc, argv); // 创建应用对象，管理事件循环 QPushButton button(“点击我”); button.resize(200, 100); // 设置按钮大小 button.show(); // 显示按钮（窗口） // 连接信号与槽：点击按钮时弹出消息框 QObject::connect(&button, &QPushButton::clicked, []() { QMessageBox::information(nullptr, “提示”, “你好，Qt！”); }); return app.exec(); // 进入主事件循环 }

要点：你需要先创建QApplication，然后创建控件对象，设置属性，连接信号槽，最后启动事件循环。控件对象在堆栈或堆上创建，由框架管理其生命周期和绘制。

7.2 Dear ImGui + GLFW + OpenGL3 极简示例

假设你已经集成了imgui、imgui_impl_glfw、imgui_impl_opengl3这几个源文件。

main.cpp:

#include “imgui.h” #include “imgui_impl_glfw.h” #include “imgui_impl_opengl3.h” #include <GLFW/glfw3.h> int main() { // 1. 初始化GLFW窗口和OpenGL上下文 glfwInit(); GLFWwindow* window = glfwCreateWindow(1280, 720, “Hello ImGui”, NULL, NULL); glfwMakeContextCurrent(window); glfwSwapInterval(1); // 开启垂直同步 // 2. 初始化Dear ImGui上下文 IMGUI_CHECKVERSION(); ImGui::CreateContext(); ImGuiIO& io = ImGui::GetIO(); (void)io; // 3. 设置ImGui样式（可选） ImGui::StyleColorsDark(); // 4. 初始化平台和渲染器后端 ImGui_ImplGlfw_InitForOpenGL(window, true); ImGui_ImplOpenGL3_Init(“#version 130”); bool show_demo_window = false; bool show_another_window = false; // 5. 主渲染循环 while (!glfwWindowShouldClose(window)) { glfwPollEvents(); // 处理系统事件 // 开始新一帧的ImGui构建 ImGui_ImplOpenGL3_NewFrame(); ImGui_ImplGlfw_NewFrame(); ImGui::NewFrame(); // 构建我们的界面 { ImGui::Begin(“主窗口”); if (ImGui::Button(“点击我”)) { // 按钮在这一帧被点击了 show_another_window = true; } ImGui::SameLine(); ImGui::Text(“这是一个按钮。”); if (show_another_window) { ImGui::Begin(“另一个窗口”, &show_another_window); ImGui::Text(“你好，ImGui！”); if (ImGui::Button(“关闭我”)) show_another_window = false; ImGui::End(); } ImGui::End(); } // 渲染 ImGui::Render(); int display_w, display_h; glfwGetFramebufferSize(window, &display_w, &display_h); glViewport(0, 0, display_w, display_h); glClearColor(0.45f, 0.55f, 0.60f, 1.00f); glClear(GL_COLOR_BUFFER_BIT); ImGui_ImplOpenGL3_RenderDrawData(ImGui::GetDrawData()); // 执行ImGui的绘制命令 glfwSwapBuffers(window); } // 6. 清理 ImGui_ImplOpenGL3_Shutdown(); ImGui_ImplGlfw_Shutdown(); ImGui::DestroyContext(); glfwDestroyWindow(window); glfwTerminate(); return 0; }

要点：你需要自己管理窗口和OpenGL上下文。在每一帧的循环中，先调用NewFrame()，然后通过一系列ImGui::Begin()/ImGui::End()和控件函数“描述”界面，最后调用Render()和渲染后端的提交函数。界面状态（如show_another_window）完全由你自己的变量控制。

对比这两个例子，你可以深刻感受到“对象与事件”和“立即描述”两种思维模式的差异。Qt的代码更像是“设置和配置”，而ImGui的代码更像是“每帧的绘制脚本”。

我个人在实际项目中的体会是，不要试图用一个框架解决所有问题。评估新项目时，我会先问几个问题：这个工具的最终用户是谁？界面是静态表单居多还是动态调试面板居多？是否需要和现有的3D渲染引擎深度集成？对安装包大小和启动速度有多敏感？团队更熟悉哪种开发模式？回答完这些问题，选择往往就清晰了。很多时候，甚至在同一个大项目中，不同的子模块根据其特性，分别选用Qt和ImGui，让它们各司其职，才是最优解。工具是为人服务的，搞清楚你要解决的核心问题，才能选出最趁手的那把“锤子”。