OpenGL/VTK 资源生命周期与性能

1. Context 是所有权边界

OpenGL 对象名只在兼容 context/share group 中有意义。创建、更新和删除通常要求正确 context 在当前线程 current。

GUI/render thread
  makeCurrent
    -> create/update/draw/delete GL resources
  doneCurrent

worker thread: CPU mesh/field preparation only

不要在普通 C++ 析构任意时点直接 glDelete，窗口/context 可能已销毁。监听 QOpenGLContext::aboutToBeDestroyed，makeCurrent 后释放，并提供 context 已不可用时的兜底策略。

2. QOpenGLWidget 生命周期

• initializeGL：context current 后初始化；可能因 context 重建再次发生，设计幂等重建；
• resizeGL：更新 viewport/projection；
• paintGL：仅执行本帧渲染，避免阻塞 I/O/大分配；
• widget 组合通常通过 FBO，不能假定默认 framebuffer 永远是 0；
• 高 DPI 下逻辑像素与 framebuffer 像素不同。

3. 数据管线

domain mesh (CPU, immutable snapshot)
  -> render extraction (positions/indices/scalars)
  -> staging buffer
  -> GUI/render thread upload VBO/EBO/texture
  -> draw commands

worker 生成纯 CPU 数据，上传在拥有 context 的线程。用 generation ID 丢弃过期结果，限制 staging/upload 队列，防快速时间步耗尽内存。

4. VTK 与 Qt

使用目标 Qt/VTK 版本匹配的 QVTKOpenGLNativeWidget 和 surface format。VTK pipeline 对象、render window/interactor 的生命周期和线程支持按版本文档核对；一般在 GUI/render 线程修改/渲染，后台只计算独立数据。

Qt、VTK、OpenGL ABI/构建配置必须匹配，尤其 Debug/Release、MSVC runtime 和 OpenGL backend。

5. 大数据性能

• 只在数据变化时上传，不每帧重建全部 buffer；
• 脏区域/分块更新；
• LOD、视锥裁剪、抽样和 level-of-detail；
• 合批减少 draw calls，但避免单批过大更新；
• 用 GPU timer/query 与 CPU profiler 区分瓶颈；
• 控制峰值显存和 CPU/GPU 双份数据。

glBufferData/persistent mapping 等策略依驱动和版本，必须测量，不写成绝对最快。

6. 拾取

常见：CPU BVH/ray cast、GPU ID buffer、VTK picker。GPU ID picking 需处理 MSAA、透明、DPI、异步 readback 和 ID 宽度；CPU picking 需空间索引和变换一致。

selection 保存领域 stable ID，不长期保存 VTK pointer/数组下标；网格重建后用映射更新或清除选择。

7. 资源销毁顺序

1. 停止产生新 render jobs；
2. 取消/排空 worker 和上传队列；
3. GUI thread makeCurrent；
4. 释放 VTK/GL 资源；
5. doneCurrent；
6. 销毁 widget/context；
7. 最后释放领域 snapshot。

8. 面试速答

为什么 GL 资源删除需要 context？ 对象名和驱动状态属于 context/share group，删除调用需在兼容 current context 解释。

为何不在 worker 直接更新 VBO？ context 通常属于 GUI/render 线程，跨线程 current 和同步复杂；worker 更适合生成 CPU staging 数据。

LOD 只为帧率吗？ 还减少上传、显存和交互延迟，但需保持误差/选择语义。

9. 自测答案

QOpenGLWidget resize 后 picking 坐标为什么错？可能混淆逻辑像素、devicePixelRatio、viewport/Y 轴。Context 重建后旧 GLuint 是否可继续？不能假定，需按 share/recreate 协议重建。

渲染资源有 CPU 与 GPU 两条生命线

CPU wrapper created
 -> GPU allocation created in device/context
 -> command references resource
 -> submit fence N
 -> CPU decides destroy
 -> wait/defer until fence N complete
 -> GPU free

C++ 对象析构不代表 GPU 已停止使用资源。常用 deferred deletion queue 按 fence/frame 回收。

Context/Device 所有权

OpenGL 对象关联 share group/context，命令要求正确 context current；Vulkan/QRhi 资源依赖 device。销毁窗口/surface 前先停止 render loop 并释放依赖资源，device/context 最后销毁。

Device/Context
├── pipelines/shaders
├── buffers/textures
├── command resources
└── surfaces/framebuffers

GUI 与 render thread

Qt Quick/render backend 可能在独立渲染线程运行；QObject affinity 与 GPU context thread 是不同约束。不要从 GUI slot 直接销毁 render-thread 资源；通过 render job/同步点把操作投递正确阶段。

Buffer 更新策略

static geometry: upload once, reuse
dynamic: ring/staging buffers, avoid overwriting in-flight region
streaming: producer/consumer chunks + budget/backpressure

每帧重新创建大 buffer 会产生分配与同步。双/三缓冲能隔离在途帧，但增加显存，需测量峰值。

Scene 与 GPU cache 分离

Document/domain 保存可序列化几何与结果，render scene 维护 GPU handle/cache：

domain revision -> render extraction -> immutable render packet
 -> GPU cache keyed by resource/revision

设备丢失/窗口重建时 GPU cache 可重建，不能把 GPU handle 当文档权威数据保存。

Picking 与异步 readback

GPU picking/readback 可能几帧后完成；用户已切换文档或 scene revision：

request(scene rev 20, cursor x,y)
 -> GPU completes later
 -> apply only if view/scene generation still matches

同步 readback 会 stall CPU/GPU pipeline，应使用异步 staging/fence 并容忍延迟。

资源预算与淘汰

缓存记录字节、最近使用 fence 和重建成本。只在资源不再 in-flight 后淘汰；超预算时降低 LOD、流式加载或拒绝任务，不能等 driver OOM 后再处理。

Shader/Pipeline 生命周期

编译失败要保留 source variant、driver/device 与日志；热重载先成功创建新 pipeline，再原子替换，旧 pipeline 延迟到在途命令完成后销毁。不要在渲染线程同步编译大量 shader 卡住帧。

关闭状态机

stop accepting scene updates
 -> cancel loaders/compute
 -> stop render submissions
 -> wait fences/device idle at controlled boundary
 -> flush deferred deletion
 -> destroy surface/context/device

连续追问与自测

问：unique_ptr GPUBuffer 析构是否足够？ 答：它管理 CPU wrapper，但实际 GPU 释放仍需正确 device/context 与在途 fence 协议。

问：为什么渲染缓存不能成为 Document 数据？ 答：它依赖设备/上下文且可丢失，应能从领域数据重建。

1. deferred deletion 解决什么？ 答：CPU 不再需要但 GPU 命令仍在使用的时间差。
2. readback 为何携带 generation？ 答：完成时 scene/view 可能已变化。
3. 设备销毁前做什么？ 答：停止提交、等待/处理在途工作并释放依赖资源。

工程深化：把本篇知识落到项目里

这一节不是为了凑篇幅，而是把《OpenGL/VTK 资源生命周期与性能》从“知道概念”推进到“能在项目里稳定使用”。 阅读时可以把每个知识点都追问成四件事：它保护什么边界，失败时有什么现象，怎样最小复现，怎样写进团队流程。

concept -> boundary -> failure signal -> minimal proof -> project rule

工程切片 1：最小可复现样例

**场景。**围绕 事件循环 建一个很小的案例，不要一开始就放进完整业务系统。把问题压缩到一个可以提交给同事的目录，保留源码、构建命令、版本输出和预期现象。

**边界。**先判断这里讨论的是 事件循环、QObject 还是 模型数据 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 事件循环 -> QObject -> 模型数据 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 2：接口边界

**场景。**围绕 QObject 建一个很小的案例，不要一开始就放进完整业务系统。写清调用方能依赖什么、不能依赖什么，并把隐式假设转换成命名函数、配置项或测试。

**边界。**先判断这里讨论的是 QObject、模型数据 还是 线程边界 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> QObject -> 模型数据 -> 线程边界 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 3：失败注入

**场景。**围绕 模型数据 建一个很小的案例，不要一开始就放进完整业务系统。故意制造一个常见错误，让日志、断言或测试先失败，再用修复后的证据说明规则生效。

**边界。**先判断这里讨论的是 模型数据、线程边界 还是 资源生命周期 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 模型数据 -> 线程边界 -> 资源生命周期 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 4：跨平台差异

**场景。**围绕 线程边界 建一个很小的案例，不要一开始就放进完整业务系统。至少比较 Windows、Linux 或不同编译器下的一个差异，记录差异属于标准、实现还是平台约定。

**边界。**先判断这里讨论的是 线程边界、资源生命周期 还是 诊断工具 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 线程边界 -> 资源生命周期 -> 诊断工具 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 5：性能观察

**场景。**围绕 资源生命周期 建一个很小的案例，不要一开始就放进完整业务系统。用小规模和压力规模各跑一次，区分算法成本、同步成本、I/O 成本和工具链配置成本。

**边界。**先判断这里讨论的是 资源生命周期、诊断工具 还是 事件循环 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 资源生命周期 -> 诊断工具 -> 事件循环 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 6：生命周期

**场景。**围绕 诊断工具 建一个很小的案例，不要一开始就放进完整业务系统。标出资源创建、转移、共享、停止和销毁的顺序，特别关注错误返回和提前退出路径。

**边界。**先判断这里讨论的是 诊断工具、事件循环 还是 QObject 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 诊断工具 -> 事件循环 -> QObject -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 7：诊断证据

**场景。**围绕 事件循环 建一个很小的案例，不要一开始就放进完整业务系统。保留命令、日志、符号、栈、测试输出或截图，让结论可以被另一个环境重新验证。

**边界。**先判断这里讨论的是 事件循环、QObject 还是 模型数据 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 事件循环 -> QObject -> 模型数据 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 8：维护策略

**场景。**围绕 QObject 建一个很小的案例，不要一开始就放进完整业务系统。把一次性经验沉淀到 README、CI、脚本、示例工程或检查表里，避免只存在个人记忆中。

**边界。**先判断这里讨论的是 QObject、模型数据 还是 线程边界 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> QObject -> 模型数据 -> 线程边界 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 9：版本演进

**场景。**围绕 模型数据 建一个很小的案例，不要一开始就放进完整业务系统。为未来变更预留兼容策略：版本号、特性位、弃用窗口、迁移脚本和回滚入口。

**边界。**先判断这里讨论的是 模型数据、线程边界 还是 资源生命周期 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 模型数据 -> 线程边界 -> 资源生命周期 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 10：最小消费者

**场景。**围绕 线程边界 建一个很小的案例，不要一开始就放进完整业务系统。从使用者角度写一个小程序或小工程，只依赖公开接口，验证安装包、头文件和运行时行为。

**边界。**先判断这里讨论的是 线程边界、资源生命周期 还是 诊断工具 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 线程边界 -> 资源生命周期 -> 诊断工具 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 11：边界复盘

**场景。**围绕 资源生命周期 建一个很小的案例，不要一开始就放进完整业务系统。用一张表说明问题发生在源码、编译、链接、加载、运行、关闭或发布中的哪一层。

**边界。**先判断这里讨论的是 资源生命周期、诊断工具 还是 事件循环 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 资源生命周期 -> 诊断工具 -> 事件循环 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 12：反例训练

**场景。**围绕 诊断工具 建一个很小的案例，不要一开始就放进完整业务系统。写出一个看似能工作但不可维护的方案，再说明它在规模、团队协作或发布时会怎样失败。

**边界。**先判断这里讨论的是 诊断工具、事件循环 还是 QObject 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 诊断工具 -> 事件循环 -> QObject -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 13：最小可复现样例

**场景。**围绕 事件循环 建一个很小的案例，不要一开始就放进完整业务系统。把问题压缩到一个可以提交给同事的目录，保留源码、构建命令、版本输出和预期现象。

**边界。**先判断这里讨论的是 事件循环、QObject 还是 模型数据 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 事件循环 -> QObject -> 模型数据 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 14：接口边界

**场景。**围绕 QObject 建一个很小的案例，不要一开始就放进完整业务系统。写清调用方能依赖什么、不能依赖什么，并把隐式假设转换成命名函数、配置项或测试。

**边界。**先判断这里讨论的是 QObject、模型数据 还是 线程边界 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> QObject -> 模型数据 -> 线程边界 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 15：失败注入

**场景。**围绕 模型数据 建一个很小的案例，不要一开始就放进完整业务系统。故意制造一个常见错误，让日志、断言或测试先失败，再用修复后的证据说明规则生效。

**边界。**先判断这里讨论的是 模型数据、线程边界 还是 资源生命周期 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 模型数据 -> 线程边界 -> 资源生命周期 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 16：跨平台差异

**场景。**围绕 线程边界 建一个很小的案例，不要一开始就放进完整业务系统。至少比较 Windows、Linux 或不同编译器下的一个差异，记录差异属于标准、实现还是平台约定。

**边界。**先判断这里讨论的是 线程边界、资源生命周期 还是 诊断工具 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 线程边界 -> 资源生命周期 -> 诊断工具 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 17：性能观察

**场景。**围绕 资源生命周期 建一个很小的案例，不要一开始就放进完整业务系统。用小规模和压力规模各跑一次，区分算法成本、同步成本、I/O 成本和工具链配置成本。

**边界。**先判断这里讨论的是 资源生命周期、诊断工具 还是 事件循环 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 资源生命周期 -> 诊断工具 -> 事件循环 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 18：生命周期

**场景。**围绕 诊断工具 建一个很小的案例，不要一开始就放进完整业务系统。标出资源创建、转移、共享、停止和销毁的顺序，特别关注错误返回和提前退出路径。

**边界。**先判断这里讨论的是 诊断工具、事件循环 还是 QObject 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 诊断工具 -> 事件循环 -> QObject -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 19：诊断证据

**场景。**围绕 事件循环 建一个很小的案例，不要一开始就放进完整业务系统。保留命令、日志、符号、栈、测试输出或截图，让结论可以被另一个环境重新验证。

**边界。**先判断这里讨论的是 事件循环、QObject 还是 模型数据 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 事件循环 -> QObject -> 模型数据 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 20：维护策略

**场景。**围绕 QObject 建一个很小的案例，不要一开始就放进完整业务系统。把一次性经验沉淀到 README、CI、脚本、示例工程或检查表里，避免只存在个人记忆中。

**边界。**先判断这里讨论的是 QObject、模型数据 还是 线程边界 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> QObject -> 模型数据 -> 线程边界 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 21：版本演进

**场景。**围绕 模型数据 建一个很小的案例，不要一开始就放进完整业务系统。为未来变更预留兼容策略：版本号、特性位、弃用窗口、迁移脚本和回滚入口。

**边界。**先判断这里讨论的是 模型数据、线程边界 还是 资源生命周期 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 模型数据 -> 线程边界 -> 资源生命周期 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 22：最小消费者

**场景。**围绕 线程边界 建一个很小的案例，不要一开始就放进完整业务系统。从使用者角度写一个小程序或小工程，只依赖公开接口，验证安装包、头文件和运行时行为。

**边界。**先判断这里讨论的是 线程边界、资源生命周期 还是 诊断工具 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 线程边界 -> 资源生命周期 -> 诊断工具 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

本篇收束

掌握《OpenGL/VTK 资源生命周期与性能》的标志，不是记住所有名词，而是能把 事件循环、QObject、模型数据、线程边界、资源生命周期、诊断工具 放进一条可验证的工程链路。 先用最小样例建立判断，再用测试和脚本固定判断，最后把失败证据留给未来的自己和团队。