QWidget渲染性能瓶颈主要在CPU软渲染流程，包括paintEvent、布局计算、样式解析和QPainter指令生成，且默认不启用GPU加速。
QWidget 渲染性能瓶颈在哪
QWidget 的绘制本质是 CPU 软渲染 + 系统原生控件合成，每帧都要走 paintEvent、布局计算、样式解析、QPainter 指令生成，遇到复杂动画或高频重绘（比如滚动日志、实时波形）就会明显掉帧。它不默认走 GPU 加速，除非你手动启用 QOpenGLWidget 或用 QGraphicsView 配合 QGraphicsScene::setItemIndexMethod 做优化。
常见错误现象：QTimer::singleShot(0, this, &MyWidget::update) 疯狂触发重绘但界面卡顿；自定义 paintEvent 里反复 new/delete QPixmap；在 resizeEvent 中直接调用 repaint() 导致重入。
- 能用
QPixmap::cacheKey()复用离屏缓存就别每次都重绘 - 避免在
paintEvent中做字符串测量、文件读取、网络请求等阻塞操作 - QPainter 启用
setRenderHint(QPainter::Antialiasing, false)可省下 15%~20% CPU 开销（文字/线条锯齿可接受时） - QWidget 树层级超过 8 层后，
show()/hide()的开销会指数上升，建议用QStackedWidget替代频繁setVisible()
QML 在桌面端的真实 GPU 利用率
QML 默认走 QQuickWindow + QRhi（Qt6）或 QSGRenderer（Qt5），只要没禁用，90% 场景下都走 GPU 渲染。但“走 GPU”不等于“性能好”——QML 的 JS 引擎（V4）执行逻辑、属性绑定风暴、过度嵌套的 Repeater 和 Loader，都会让 GPU 等着 CPU，最终帧率卡在 30fps 以下。
典型翻车场景：ListModel 里塞 5000 条数据还绑到 ListView；onWidthChanged: { text = longCalculation() } 这种写法；用 Binding 实现跨组件状态同步却忘了设 when: true。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 桌面端优先用
qtquickcontrols2而非qtquickcontrols（后者是 Qt5.6 旧版，无完整桌面适配） -
Text { renderType: Text.NativeRendering }在高 DPI 下模糊？换Text.QtRendering，但注意字体 hinting 会变弱 - QML 与 C++ 通信别滥用
Q_PROPERTY+NOTIFY，高频信号（如传感器数据）改用QMetaObject::invokeMethod(..., Qt::QueuedConnection)批量投递 - Qt6.5+ 开始，
QQuickWidget（把 QML 嵌进 QWidget）比QQuickView多一层合成开销，纯 QML 应用直接用QGuiApplication+QQuickWindow
混合开发时 C++ 和 QML 的边界怎么划
不是“UI 用 QML、逻辑用 C++”就万事大吉。QML 不适合做：带状态机的协议解析、需要精确内存控制的图像处理、硬实时音频回调、多线程密集计算。C++ 也不该暴露裸指针、STL 容器、未注册元对象类型给 QML。
容易踩的坑：Q_INVOKABLE 函数返回 std::vector<int> 导致 QML 报 Cannot assign to property of type QVariantList；QML 里 Component.onCompleted 就调 cppObj.loadData()，结果 C++ 构造函数还没跑完；用 QQmlContext::setContextProperty 注册单例但忘了加 QML_ELEMENT 宏（Qt6）。
- C++ 对象暴露给 QML 必须继承
QObject，且所有属性/方法加Q_PROPERTY/Q_INVOKABLE，否则运行时静默失败 - 高频数据流（如摄像头帧）用
QQuickImageProvider+Image.source = "image://myprovider/frame"，别走QVariantMap传 QImage - QML 加载慢？用
qt_add_qml_module()（CMake）预编译 .qmlc，或拆分qmldir+Plugin按需加载 - QWidget 和 QML 共存时，
QQuickWidget的setClearBeforeRendering(false)可减少一帧延迟，但要自己确保背景清空
桌面部署时 Qt 版本和渲染后端的实际影响
Qt6.2 之后默认用 QRhi（抽象渲染接口），但 Windows 上 D3D11 是首选，Linux 上 Vulkan 优于 OpenGL，macOS 必须用 Metal。选错后端不会报错，只会性能腰斩——比如在 macOS 上强制 -platform cocoa:gl，GPU 占用率飙到 90% 但帧率只有 12fps。
另一个隐形杀手：QT_QPA_PLATFORM 环境变量被误设为 offscreen 或 minimal，应用启动黑屏且无日志；或者打包时漏掉 libQt6QuickParticles.so（哪怕没用粒子效果，QML 引擎内部也依赖）。
- Windows 发布前必测
qtdiag输出，确认QRhi backend:行显示的是d3d11而非null - Linux 上若用户显卡老旧（如 Intel HD 4000），回退到
QSG_RHI_BACKEND=opengl比硬上 Vulkan 更稳 - Qt6.5+ 的
QQuickWindow::setGraphicsApi(QQuickWindow::OpenGL)已废弃，改用QQuickWindow::setGraphicsApi(QQuickWindow::Vulkan)或环境变量控制 - 静态链接 Qt 时，
QML_IMPORT_PATH必须指向编译时的qml/目录，否则import QtQuick.Controls 2.15报错找不到模块
paintEvent 里做了不该做的事。 
