做Qt开发这些年，被问得最多的问题之一就是：我到底该装哪个版本的Qt？这个问题看似简单，实际上坑特别多。有人装了Qt 6之后发现串口模块不见了，有人用Qt 5.15.2编译出来的程序在另一台机器上直接报“cannot mix incompatible Qt library”，还有人做嵌入式交叉编译时被Kit配置折磨到怀疑人生。版本选择不只是“下载哪个安装包”的问题，它直接决定了你的开发环境能不能跑通、第三方库能不能接进来、最终软件打包发布会不会翻车。尤其是现在Qt 5和Qt 6并行维护，LTS版本、商业版、开源版、离线包、在线安装器搅在一起，新手很容易一上来就选错。这篇文章面向所有正在做Qt项目的人，不管你是刚接触Qt的桌面开发新手，还是正在做嵌入式、工业上位机、数据可视化工具的老手，我都会把版本选择背后的逻辑、常见场景的选型建议、安装配置细节和故障排查经验拆开讲清楚，帮你少走弯路。

1. Qt版本选择到底在选什么

1.1 从版本号里读出关键信息

Qt的版本号不是随便编的，格式通常是“主版本.次版本.补丁版本”，比如5.15.2、6.2.4、6.5.3。主版本决定了大框架，Qt 5和Qt 6之间的差异不是小修小补，而是模块拆分、构建系统、图形渲染架构都变了。次版本一般带来新功能和少量API调整，补丁版本主要是修bug和安全问题。很多新手看到“5.15.2”和“6.5.3”会下意识觉得6.5.3更新，肯定更好，但实际项目里不一定。Qt 5.15.2是Qt 5系列里被用得最多的一个版本，生态成熟，第三方库支持广，很多工业软件、医疗设备上位机、老项目维护都停留在这一版。Qt 6.2 LTS和Qt 6.5 LTS则是Qt 6里适合长期维护的版本，新项目如果不需要兼容旧代码，可以从这两个里选。关键是要明白：版本号高不等于适合你，得看你的项目依赖什么。

我一般会先问三个问题：这个项目是全新开发还是维护老代码？目标平台是Windows、Linux还是嵌入式？有没有必须用的第三方库，比如Halcon、PROJ、OpenCV、QCustomPlot？这三个问题的答案基本能框定版本范围。比如你要调用Halcon，Halcon的C++接口对Qt版本和编译器版本有明确对应关系，乱选版本很可能链接失败。再比如你要做嵌入式，交叉编译工具链和Qt版本的匹配度比桌面环境苛刻得多，Qt 6对C++17的要求、对OpenGL ES的依赖，都可能让旧硬件跑不起来。

1.2 选错版本会引发哪些连锁反应

版本选错的代价往往不是立刻报错，而是开发到一半才暴露。最常见的是模块缺失。Qt 5.15之后的在线安装器默认不勾选Qt Serial Port、Qt Modbus等附加模块，如果你装的时候没注意，后面写串口通信时直接报“unknown module(s) in qt: serialport”。这时候你以为是代码问题，其实是安装时没装对应模块。再比如Qt 6把QChart从核心模块移到了Qt Charts附加模块，如果你用CMake构建却没写find_package(Qt6Charts)，编译就会失败。

第二个连锁反应是运行时库冲突。你机器上可能同时装了Qt 5.9、Qt 5.15.2和Qt 6.5，环境变量PATH里优先找到了某个版本的qmake，但运行时又加载了另一个版本的Qt5Core.dll，于是程序启动就弹“cannot mix incompatible Qt library (5.15.3) with this library (5.15.2)”。这种问题在打包发布时更常见，因为你开发机上有多个Qt，打包工具可能抓错了依赖。

第三个连锁反应是构建系统不兼容。Qt 5时代很多项目用qmake，.pro文件写惯了；Qt 6主推CMake，虽然也支持qmake，但新特性基本围绕CMake展开。如果你把一个Qt 5的qmake项目直接切到Qt 6的Kit上，可能会遇到一堆语法和模块名变化。所以版本选择不只是选一个安装包，而是选一整套工具链、构建方式和依赖生态。

1.3 Qt 5与Qt 6的核心分水岭

下面这张表可以帮你快速判断自己该留在Qt 5还是转向Qt 6。注意表格里的建议是基于常见项目类型，不是绝对规则，具体还要看你的依赖库。

这张表里最容易被忽略的是“第三方库兼容”。我见过一个项目用Qt 6.5开发了三个月，最后发现必须用的一个工业相机SDK只提供Qt 5.9的示例和库文件，结果只能回退。所以选版本之前，先把所有必须依赖的第三方库列出来，逐个查它们的官方文档支持到哪个Qt版本，这一步花半小时，能省后面几周。

2. 不同场景下的Qt版本选型实战

2.1 桌面工具与上位机：稳定优先，LTS为王

桌面工具、工业上位机、测试软件这类项目，我的建议非常明确：优先选Qt 5.15.2或者Qt 6.5 LTS，不要追最新的非LTS版本。原因很简单，上位机软件通常要长期运行，可能几年都不大改，稳定性和可维护性比新特性重要得多。Qt 5.15.2虽然官方开源支持已经到期，但商业LTS还在维护，社区资料极其丰富，遇到问题一搜就有答案。Qt 6.5 LTS则是新项目的合理起点，支持周期长，CMake构建更现代，对高DPI屏幕的支持也更好。

具体操作上，如果你做的是Windows上位机，安装时至少勾选以下组件：Qt 5.15.2的MinGW 8.1 64-bit或MSVC 2019 64-bit、Qt Creator、Qt Serial Port、Qt Charts、Qt Data Visualization。如果做数据采集，串口和图表模块几乎是标配。很多人装完Qt才发现没有串口模块，就是因为在线安装器里这些附加模块默认折叠，需要手动展开勾选。离线安装包相对省事，但Qt 5.14之后的离线包官方不再对开源用户提供完整版本，所以如果你拿到的是Qt 5.14离线安装包，可以用，但要知道它比5.15.2少了后续补丁。

对于“qt自定义进度条”“qt界面设计”这类需求，Qt 5和Qt 6的差异不大，QPainter、QStyle、QWidget体系都保留着。但Qt 6对QWidget的渲染有一些底层改动，如果你用了比较冷门的样式表技巧，迁移时可能需要微调。我的经验是：新做的桌面项目如果没有任何历史包袱，直接上Qt 6.5 LTS；如果是接手老项目或者要复用大量现有代码，留在Qt 5.15.2更省心。

2.2 嵌入式与交叉编译：工具链匹配是硬门槛

嵌入式是Qt版本选择最容易翻车的领域。你在Ubuntu 20.04上装Qt交叉编译环境，不是随便下个Qt安装包就能用，必须先把目标板的工具链、sysroot、Qt源码版本三者对齐。常见流程是：从芯片厂商或板卡厂商拿到交叉编译工具链，比如arm-linux-gnueabihf-gcc，然后用Qt源码手动编译，或者用Boot2Qt、Yocto、Buildroot集成。Qt 5.15.2在嵌入式里用得非常多，因为很多旧BSP和工具链只支持到C++11，而Qt 6要求C++17，工具链太老就编不过。

如果你用的是Qt 6做嵌入式，要特别注意图形后端。Qt 6默认可能尝试用OpenGL ES或者Vulkan，但很多嵌入式GPU只支持OpenGL ES 2.0，你需要配置QT_QUICK_BACKEND=software或者指定eglfs平台插件。交叉编译时，qmake的配置参数很关键，比如：

./configure -release -opengl es2 -device linux-arm-generic-g++ \ -device-option CROSS_COMPILE=arm-linux-gnueabihf- \ -sysroot /opt/sysroot \ -prefix /usr/local/qt5 \ -opensource -confirm-license -make libs -nomake examples -nomake tests

这段配置里，-sysroot指向目标板的根文件系统，-prefix是安装路径，-opengl es2指定图形后端。每一步都要和你的硬件匹配，错一个参数就可能编译失败或者运行时黑屏。我踩过的坑是：工具链的glibc版本比sysroot里的高，导致链接时找不到符号。解决办法是让工具链和sysroot来自同一个BSP包，不要混用。

另外，嵌入式项目选Qt版本时，先查板卡厂商的SDK里自带哪个Qt版本。如果厂商已经提供了Qt 5.12的预编译库，你硬上Qt 6.5，就得自己解决所有依赖，工作量翻倍。除非有明确的新功能需求，否则跟随厂商推荐的版本是最稳妥的。

2.3 绘图与数据可视化：QChart、QCustomPlot与OpenGL的取舍

“qt绘图效率比较”“qchart实现图片缩放+qt”“qt绘制三维曲线”这些热搜词说明很多人在做数据可视化时纠结版本和库的选择。Qt自带的QChart模块在Qt 5.7引入，Qt 6里继续保留，但性能一直是被吐槽的点。如果你只是画几条曲线、刷新率要求不高，QChart够用，而且和Qt Designer集成好，上手快。如果你要画几十条实时曲线，刷新频率几十赫兹，QChart可能会卡，这时候常见方案是QCustomPlot或者Qwt。QCustomPlot是单个头文件和源文件，不依赖Qt版本太多，Qt 5和Qt 6都能用，但Qt 6下需要把一些过时的API替换掉，比如QRegExp换成QRegularExpression。

“qt曲线刷新能放在另一个线程里面吗”这个问题很典型。答案是：数据准备可以放子线程，但GUI绘制必须在主线程。QChart和QCustomPlot都不是线程安全的，你不能在子线程里直接调用addData或者update。正确做法是在子线程里采集和计算数据，通过信号槽把数据块发给主线程，主线程再更新图表。如果数据量很大，可以用队列缓冲，避免主线程被高频信号淹没。Qt 5和Qt 6在这个模式上没有本质区别，但Qt 6的信号槽底层实现有优化，跨线程通信效率略好。

“qt绘制三维曲线”的话，Qt 5可以用Qt Data Visualization模块，Qt 6也有对应模块但API有变化。如果只是简单三维线框，用QOpenGLWidget自己画更灵活，但需要处理OpenGL版本兼容。嵌入式上如果只有OpenGL ES 2.0，Qt Data Visualization可能跑不起来，建议改用QPainter做二维投影或者用第三方库。

2.4 串口、Modbus与硬件通信：模块缺失的预防与修复

“unknown module(s) in qt: serialport”和“error while building/deploying project qtmodbus”这两个报错在Qt社区里出现频率极高。根本原因通常是安装Qt时没有勾选Qt Serial Port和Qt Modbus模块，或者.pro文件里没有正确添加模块。Qt 5和Qt 6的模块名称基本一致，但Qt 6用CMake时写法不同。

如果你已经装了Qt但发现没有串口模块，不用重装整个Qt。打开Qt维护工具，找到对应版本的“Additional Libraries”，勾选Qt Serial Port和Qt Modbus，让它补装即可。如果维护工具里找不到，说明你装的是精简版或者离线包不包含这些模块，那就需要重新下载完整包或者单独编译模块。单独编译Qt Serial Port源码也可以，但比较麻烦，适合有经验的开发者。

.pro文件里要写：

QT += serialport QT += serialport modbus

如果用CMake：

find_package(Qt6 REQUIRED COMPONENTS SerialPort Modbus) target_link_libraries(myapp PRIVATE Qt6::SerialPort Qt6::Modbus)

很多人只写了QT += serialport，但忘了Qt Modbus需要单独加modbus，结果构建qtmodbus项目时报错。另外，Qt 5.9.9 MinGW这个组合比较老，如果你用的是Qt 5.9.9，确保安装包里包含这些模块，因为老版本离线包有时候默认不带。构建失败时，先检查Kit里的qmake路径是否指向了包含该模块的Qt版本，再检查.pro或CMakeLists里的模块声明。

3. Qt安装与多版本共存实操

3.1 在线安装器、离线包与镜像源的取舍

Qt官方现在主推在线安装器，好处是灵活，想装哪个版本、哪个模块自己勾选；坏处是网络不稳定时下载很慢，而且默认不勾选附加模块，容易漏装。离线安装包适合网络环境差或者需要批量部署的场景，但Qt 5.14之后官方对开源用户的离线包越来越少，网上流传的“qt离线安装包下载5.14”往往来源不明，安全性和完整性没法保证。我的建议是：优先用官方在线安装器，如果网络慢，可以配置国内镜像源，比如清华、中科大、阿里云的Qt镜像，下载速度会快很多。

安装时最关键的步骤是选择组件。以Qt 5.15.2为例，至少勾选：MinGW 8.1 64-bit、Qt Creator、Qt Serial Port、Qt Charts、Qt Data Visualization、Qt Network Authorization（如果用到）。如果你用MSVC，还要勾选对应的MSVC 2019 64-bit套件，并确保本机装了Visual Studio的C++工作负载。很多人装完Qt Creator后发现没有编译器，就是因为只装了Qt库没装MinGW或者MSVC。

“qt 5.15.2下载安装”和“qt安装教程”这类内容网上很多，但不少教程让你直接下一步下一步，最后缺模块。我的习惯是：装完后立刻打开Qt Creator，新建一个空Widgets项目，在.pro里加QT += serialport charts，编译运行。如果能通过，说明基础模块齐全；如果报unknown module，再回去补装。这个自检流程花五分钟，能避免后面开发时才发现缺东西。

3.2 同一台机器装多个Qt版本的目录规划

做Qt开发时间长了，机器上不可能只有一个Qt版本。老项目要5.9，维护项目要5.15.2，新项目要6.5，三个版本共存很常见。但多版本共存最大的问题是环境变量和Kit配置混乱。我的做法是：安装时把每个版本装到独立目录，比如：

D:\Qt\5.9.9\mingw53_32 D:\Qt\5.15.2\mingw81_64 D:\Qt\6.5.3\mingw_64

注意Qt 6的目录命名和Qt 5不一样，6.5.3下面是mingw_64而不是mingw81_64。安装路径里不要有中文和空格，否则qmake和构建工具可能出问题。环境变量PATH里只放Qt Creator的路径或者不放Qt的bin目录，让Qt Creator通过Kit来指定qmake，而不是依赖系统PATH。如果你在命令行里用qmake，就用绝对路径或者写bat脚本切换，不要全局改PATH。

“卸载qt”也要注意。Qt在线安装器安装的版本，最好通过维护工具卸载，不要直接删文件夹，因为注册表和开始菜单快捷方式可能残留。维护工具里可以单独卸载某个版本和模块，比手动删干净。如果你要彻底清理，删完文件夹后还要检查环境变量、Qt Creator的配置文件（通常在AppData或.config里），避免旧Kit信息残留导致新建项目时选错版本。

3.3 Qt Creator的Kit配置与编译套件排错

Qt Creator的Kit是版本选择落地的核心。一个Kit由Qt版本、编译器、调试器、CMake或qmake组成。你装了多个Qt版本后，需要在“工具-选项-Kits”里手动配置。常见错误包括：qmake路径指向了错误版本、编译器不匹配、调试器缺失。比如你选了Qt 6.5的qmake，但编译器还是MinGW 8.1，而Qt 6.5需要MinGW 11.2，构建时就会报错。Qt 6.5通常自带MinGW 11.2，安装时勾选对应套件即可。

配置Kit的步骤：先确认Qt Versions里每个qmake都被识别；再确认Compilers里MinGW和MSVC都被识别；然后新建Kit，选择对应的Qt版本和编译器；最后在项目的“构建套件”里选择这个Kit。如果构建时报“error while building/deploying project qtmodbus (kit: desktop qt 5.9.9 mingw)”，先检查这个Kit的qmake路径是否真的存在，再检查项目是否需要的模块在这个Qt版本里已安装。Qt 5.9.9的MinGW版本是5.3.0，比较老，如果项目用了C++14以上特性可能编不过。

另外，Qt 6默认用CMake，Qt Creator新建项目时可以选择构建系统。如果你打开的是老qmake项目，Qt Creator可能提示“Cannot use CMake”，这时候要么把项目转成CMake，要么在Kit里坚持用qmake。转换不是必须的，但Qt 6对qmake的支持会逐渐减弱，新项目建议直接CMake。

3.4 与VS Code、Qt Designer、命令行工具的协同配置

很多人喜欢用VS Code写Qt，因为轻量、插件多。“vscode配置qt designer”和“vs code + qt 5.9 如何配置”是常见需求。基本思路是：在VS Code里安装C/C++插件和Qt相关插件，配置c_cpp_properties.json里的includePath指向Qt的include目录，配置tasks.json调用qmake和make，配置launch.json指定调试器。Qt Designer可以独立安装，也可以从Qt Creator的安装目录里找到designer.exe，在VS Code里配置外部工具打开.ui文件。VS Code适合习惯命令行和轻量编辑器的开发者，但Kit管理和调试体验还是Qt Creator更完整。

命令行工具方面，qmake、make、mingw32-make、windeployqt、linuxdeployqt这些要熟悉。比如打包Windows程序：

windeployqt --release --no-translations myapp.exe

这个命令会自动把依赖的Qt DLL复制到exe旁边。但前提是windeployqt的版本和编译程序用的Qt版本一致，否则可能复制错DLL。Linux下用linuxdeployqt或者手动copy依赖。嵌入式下通常用目标板的根文件系统直接部署，不需要windeployqt。

“qt命令行”和“qt console connect”可能涉及在命令行里编译和运行。你可以写一个简单的build.bat：

set QTDIR=D:\Qt\5.15.2\mingw81_64 set PATH=%QTDIR%\bin;%PATH% qmake myproject.pro mingw32-make -j8

这样每次打开命令行都能切换到指定Qt版本，比全局改PATH干净。

4. 高频故障排查与版本冲突解决

4.1 “cannot mix incompatible Qt library”完整排查链路

这个报错的意思是程序运行时加载了两个不兼容的Qt库，通常是一个是5.15.3，另一个是5.15.2。虽然次版本号接近，但Qt的ABI不保证跨补丁版本兼容，特别是插件和私有头文件。触发场景很多：你开发机上有多个Qt，PATH里优先找到了A版本的qmake，但运行时动态链接器从系统目录或另一个PATH条目里找到了B版本的Qt5Core.dll。或者你打包时windeployqt从错误版本复制了DLL。

排查步骤：第一，用依赖查看工具确认程序实际加载的Qt DLL路径，Windows用Dependencies或Process Explorer，Linux用ldd。第二，检查环境变量PATH、LD_LIBRARY_PATH、QT_PLUGIN_PATH，确保只指向目标Qt版本。第三，检查Qt Creator的Kit和项目的构建环境，清理后重新构建。第四，如果是打包后出错，把程序放到一个干净目录，用对应版本的windeployqt重新部署。第五，检查系统里是否有其他软件安装了Qt并写入了全局PATH，比如某些开发工具会自带Qt。

我的经验是：永远不要让系统PATH里出现Qt的bin目录，所有Qt路径都通过Kit或脚本显式指定。这样虽然麻烦一点，但能避免90%的版本冲突。另外，Qt 5.15.3和5.15.2混用尤其危险，因为5.15.3可能是商业版补丁，开源版没有，混用会导致插件加载失败。

4.2 unknown module(s) in qt: serialport 的四种解决路径

这个报错在Qt 5和Qt 6里都常见。解决路径按优先级排列：

第一，检查安装。打开Qt维护工具，看对应版本下是否勾选了Qt Serial Port。如果没有，补装。第二，检查.pro或CMakeLists。qmake项目要写QT += serialport，CMake项目要find_package并链接Qt::SerialPort。第三，检查qmake版本。如果你系统里有多个qmake，可能当前Kit用的qmake指向了一个没装串口模块的Qt。在Qt Creator的“项目-构建环境”里确认qmake路径，或者命令行执行qmake -query QT_VERSION和qmake -query QT_INSTALL_LIBS，看模块是否在对应目录。第四，如果以上都对了还报错，可能是模块安装不完整，尝试重新安装该模块或从源码编译。

注意Qt 6里串口模块的CMake包名是Qt6::SerialPort，qmake里仍然是QT += serialport。如果你从Qt 5迁移到Qt 6，.pro文件基本不用改，但CMakeLists需要调整。另外，Qt 5.15之后的在线安装器把串口模块放在“Additional Libraries”里，默认不勾选，这是最常见的漏装原因。

4.3 构建失败：Kit、编译器与qmake路径错位

“error while building/deploying project qtmodbus (kit: desktop qt 5.9.9 mingw)”这类错误信息通常包含Kit名称和项目名。看到这种报错，先点开Qt Creator的“编译输出”看完整日志，通常会指出是找不到qmake、找不到编译器还是缺模块。如果Kit名称里写着“desktop qt 5.9.9 mingw”，说明你用的是Qt 5.9.9的MinGW套件，但这个套件可能没有安装Qt Modbus模块，或者MinGW版本和Qt 5.9.9不匹配。

排查顺序：第一，在“工具-选项-Kits”里选中该Kit，检查qmake路径是否存在，编译器是否自动检测到。第二，在Qt Versions里确认5.9.9的qmake被正确识别。第三，打开项目的.pro文件，确认QT += modbus serialport已添加。第四，清理项目并重新执行qmake。第五，如果还是失败，检查Qt 5.9.9安装目录下是否有modbus模块的库文件和头文件。老版本Qt的模块可能命名或路径不同，必要时手动指定INCLUDEPATH和LIBS。

另一个常见原因是构建目录里有旧版本的Makefile或CMakeCache，导致构建系统还在找旧路径。解决办法是删除构建目录，重新构建。Qt Creator的“清理”不一定能删干净，手动删掉build目录更彻底。

4.4 打包发布阶段的版本依赖陷阱

“qt发布软件”“qt打包成可执行程序”“qt打包”这些操作在版本选择上有个铁律：编译用的Qt版本、windeployqt的版本、目标机器上可能存在的Qt版本，三者必须一致。如果你用Qt 6.5编译，就用Qt 6.5的windeployqt打包，不要用Qt 5.15的windeployqt。打包后，把程序放到一台没有装Qt的干净虚拟机上测试，这是最可靠的验证方法。

Windows下常见问题：程序依赖了MSVC运行库，但目标机器没装，需要一并打包vcredist或者静态链接。MinGW编译的程序依赖libgcc、libstdc++、libwinpthread，windeployqt通常会自动复制，但有时会漏。Linux下要处理glibc版本和Qt插件路径，可以用linuxdeployqt或者手动设置qt.conf。嵌入式下通常直接把可执行文件和Qt库放到目标板文件系统，注意动态链接器路径和插件路径。

“qt崩溃”很多时候就是打包时DLL版本混杂导致的。比如你开发机上同时有5.15.2和6.5，windeployqt自动找到了6.5的DLL，但你的程序是5.15.2编译的，运行就崩。解决办法是在打包脚本里显式指定Qt bin目录，或者用qt.conf锁定插件路径。

5. 进阶话题：国际化、绘图效率与长期维护

5.1 Qt国际化对版本与工具链的要求

“qt国际化”主要涉及tr()函数、.ts文件、lupdate和lrelease工具。Qt 5和Qt 6在这套流程上基本一致，但Qt 6的CMake集成更好，可以用qt_add_translations自动处理。如果你做多语言软件，建议选Qt 6.5 LTS，因为CMake的国际化支持更现代，减少手动步骤。Qt 5.15.2也能做，但需要手动在.pro里写TRANSLATIONS，然后调用lupdate和lrelease。

实操上，代码里用tr("Hello")包裹字符串，然后用lupdate生成.ts文件，用Qt Linguist翻译，最后lrelease生成.qm文件。发布时把.qm放到translations目录，程序启动时用QTranslator加载。注意Qt 6对QTranslator的加载路径有一些变化，如果沿用Qt 5的代码，可能需要调整。另外，高DPI屏幕下国际化字符串长度变化可能导致界面布局错乱，Qt 6的布局系统对动态文本支持更好。

5.2 绘图效率对比：什么时候选QChart，什么时候换库

QChart适合快速原型和中等数据量。它的优点是和Qt Designer集成，API友好，支持动画和交互。缺点是数据量大时性能下降明显，尤其是频繁调用append和update。如果你要画实时曲线，每秒刷新几十次，每条曲线几千个点，QChart会卡。这时候QCustomPlot是更常见的选择，它直接操作绘图设备，性能好很多，而且支持OpenGL加速。Qwt更老牌，但API偏底层，学习曲线陡。

Qt 6对QChart有一些性能改进，但本质架构没变。如果你在Qt 6下做高性能绘图，可以考虑Qt Quick的Canvas或者自定义QQuickItem，利用GPU渲染。但Qt Widgets项目的迁移成本高，所以很多团队还是留在Qt 5 + QCustomPlot。我的建议是：先评估数据量和刷新率，如果QChart能跑满帧率就用它，省开发时间；如果跑不满，尽早换QCustomPlot，别等到项目后期再重构。

“qt绘图”还涉及QPainter的绘制效率。在paintEvent里避免重复创建QPen、QBrush，尽量复用；只重绘需要更新的区域，用update(rect)而不是update()；复杂图形用QGraphicsView框架，它自带图元管理和碰撞检测。这些技巧和Qt版本关系不大，但Qt 6的渲染后端优化会让同样的代码跑得更快。

5.3 项目升级Qt版本的决策清单与回退方案

维护老项目时，什么时候该升级Qt版本？我一般用这个清单来判断：

如果决定升级，先在一个分支上做，不要直接改主分支。升级步骤：备份当前环境，安装新Qt版本，配置新Kit，逐步替换弃用API，编译运行测试。Qt 5到Qt 6的迁移指南官方有文档，但实际坑不少，比如QRegExp、QString::SplitBehavior、QDesktopWidget等都被弃用或移除。回退方案就是保留旧版本的Kit和分支，一旦新版本问题太多，可以快速切回。

我个人在实际操作中的体会是：Qt版本选择没有标准答案，只有适合当前项目的答案。我的机器上长期保留Qt 5.15.2和Qt 6.5.3两个套件，老项目切5.15.2，新项目用6.5.3，遇到必须用旧模块的情况再单独装一个5.9的Kit。这样切换成本不高，也不会因为追新而踩坑。如果你现在还在纠结，先装Qt 5.15.2把第一个项目跑通，再考虑要不要上Qt 6。真正开始写代码之后，你会发现版本只是工具，解决问题才是目的。