1. Qt版本选择到底在选什么
Qt版本选择这件事，表面上看是在一堆数字里挑一个，5.12、5.14、5.15.2、6.2、6.5、6.8，像在菜单上点菜。但真正做过几个项目的人都知道，这一刀切下去，切的是你后面一年到三年的维护成本。我见过太多项目组，前期随手装了个当时最新的Qt，等到要对接硬件SDK、要交叉编译到板子、要过客户的等保审查，才发现版本这道坎根本绕不过去，只能推倒重来。
先说结论性的认知：Qt版本选择从来不是单选一个库版本，而是同时锁定四样东西——Qt库本身、编译套件Kit、C++标准、以及可用模块清单。这四样是一根绳上的蚂蚱，动一个就得重新评估其余三个。很多人踩的坑，比如编译报unknown module(s) in qt: serialport、运行时报cannot mix incompatible Qt library (5.15.3) with this library (5.15.2)，本质上都不是"代码写错了"，而是这四样东西没对齐。
这篇文章面向的人群很明确：正在准备启动一个新Qt项目、或者在维护一个老项目考虑要不要升级、或者被嵌入式交叉编译的环境配置折磨过的人。不管你是刚装完Qt Creator的新手，还是已经带过团队的老兵，接下来的内容都能直接拿去当选型参考——我会把每个版本区间的适用边界、安装时的目录规划、多版本共存的配置方法、以及那些官方文档不会写的报错溯源思路，一条条摊开说。
1.1 版本号背后绑定的四件事
先拆解第一件事，Qt库版本。这个最直观，但也最容易被误解。Qt 5.15.2 里的三个数字分别是主版本、次版本、补丁版本。主版本变更是破坏性变更，5 到 6 的迁移量远超很多人预期；次版本是功能增量，比如 5.14 到 5.15 引入了不少新API；补丁版本只修bug。所以"5.15.2"和"5.15.9"在API层面是兼容的，但"5.14"和"5.15"之间就可能有不兼容的小改动——虽然官方声称次版本二进制兼容，实践中第三方库经常打破这个承诺。
第二件事，编译套件Kit。这是新手最容易忽略、老手最容易翻车的地方。同一个Qt 5.15.2，官方会同时提供 MSVC 2019 32位、MSVC 2019 64位、MinGW 8.1 32位、MinGW 8.1 64位等多个构建。你装的Qt库和你的编译器必须严格配套，MinGW 编译的程序不能链接 MSVC 编译的 Qt 库，反之亦然。项目里一旦引入一个用另一套工具链编出来的第三方静态库，链接阶段就是一场灾难。
第三件事，C++标准。Qt 5 系列默认按 C++11 编译，虽然你可以手动开 C++14/17，但库本身的实现没有依赖新标准。Qt 6 则强制要求 C++17，这一点直接决定了你的开发机编译器版本——Visual Studio 2017 之前的版本基本没戏，GCC 要 9 以上，Clang 要 10 以上。如果你手上有一台锁死在 VS2015 的产线编译机，那Qt 6这条路基本就堵死了。
第四件事，可用模块清单。这是最隐蔽的一条。Qt 的附加模块（Charts、SerialPort、Multimedia、WebEngine、DataVisualization）在不同版本里的供给状态完全不同。Qt 6.0 刚发布时，Charts、DataVisualization 这些模块都还没回归，直到 6.2 才陆续补齐。而 WebEngine 在 Qt 6 的早期版本里干脆是缺席的。如果你做的项目强依赖某个附加模块，选版本的第一步不是看主版本号，而是先查这个模块在目标版本里到底有没有。
提示：选版本之前，先把你项目要用的所有 Qt 模块列一张清单，逐个到官方模块文档里确认目标版本是否包含，这一步能省掉后面80%的返工。
1.2 LTS与非LTS的取舍逻辑
Qt 的版本策略里，LTS（长期支持）是个绕不开的概念。简单说，LTS 版本会获得更长时间的补丁维护，非 LTS 版本在下一个次版本发布后基本就停止更新了。历史上被广泛使用的 LTS 包括 Qt 5.9、5.12、5.15，以及 Qt 6.2、6.5、6.8。
这里有个很关键的行业现实要说清楚：Qt 5.15 之后的补丁版本，官方不再提供免费的开源二进制安装包。也就是说，你能从官方安装器里直接勾选下载的 Qt 5 系列，止步于 5.15.2。如果项目需要 5.15 后续的安全补丁，要么走商业授权，要么自己从源码编译并维护补丁分支。这一点直接影响了大量还在用 Qt 5 的项目——很多团队其实是被"锁"在 5.15.2 上的，升级路径要么是往 Qt 6 走，要么是接受不再更新补丁。
非 LTS 版本是不是完全不能用？倒也不是。如果你做的是内部工具、生命周期短、不对外发布的项目，用个非 LTS 的新版本尝鲜完全可以。但凡是产品要交付给客户、要维护三年以上的，我的建议很直接：优先选 LTS，其次选 LTS 的最后一个补丁。比如 Qt 5.15 系列里，5.15.2 是免费用户能拿到的最后一个版本，Qt 6 系列里 6.2、6.5 都是成熟的 LTS。
补丁版本的挑选也有讲究。刚发布的 LTS 主版本（比如 6.2.0）往往带着一堆已知问题，通常要等到 .4 或 .5 补丁才相对稳定。所以如果时间允许，等 LTS 出到第四个补丁再上车，是个稳妥策略。
1.3 用依赖倒推法定版本，而不是拍脑袋
我在实际项目里用的方法叫"依赖倒推法"，顺序和大多数人反着来。大多数人是先定Qt版本，再去解决依赖问题；正确做法是先摸清所有硬约束，再倒推出唯一可行的版本区间。
硬约束一般有这几类。第一类是硬件与SDK，比如某款工业相机、某块运动控制卡的厂商SDK只提供 MSVC 2015 编译的库，那你的工具链就被钉死在 MSVC 2015 上，而 MSVC 2015 又限制了你能用的 Qt 版本区间。第二类是客户环境，客户产线上的机器装的是 Windows 7，那 Qt 6 直接出局，因为 Qt 6 官方支持从 Windows 10 起。第三类是第三方依赖库，比如 Halcon、OpenCV、各种协议栈，它们对 Qt 版本和编译器同样有要求。第四类是团队能力，如果团队里没人熟悉 CMake，那 Qt 6 的构建体系会给项目带来额外的学习成本。
把这四类约束梳理成一张表，取交集，剩下的就是你的可行版本集合。很多情况下交集里只剩一两个选项，选择困难自然就消失了。
2. 逐个版本体检：从5.9到6.8该选谁
把主流版本拉出来挨个体检，比泛泛讲"新版好还是旧版好"有用得多。下面按时间线走一遍，每个版本我都说清楚它的定位、适合谁、以及明显的坑在哪里。
2.1 Qt 5.9 与 5.12：老工业项目的舒适区
Qt 5.9 是个很有代表性的 LTS，很多工业上位机、医疗设备界面至今还跑在它上面。它的优势是稳定、兼容性好、对老编译器的容忍度高，MSVC 2013 都能编。缺点是模块和API都比较旧，高DPI支持不完善，如果你要做4K屏幕上的界面，用 5.9 会明显感觉到缩放处理很别扭，需要手动处理一堆 DPI 相关的环境变量和属性设置。
Qt 5.12 是 5.9 之后的下一个 LTS，也是我个人认为 Qt 5 系列里"最舒服"的一代。它引入了更完善的高DPI支持，qmake 和 CMake 都能正常用，MinGW 7.3 和 MSVC 2017 都是标配。大量开源项目和第三方库对 5.12 的支持度非常好，QCustomPlot、Qwt、各类串口和Modbus库在这个版本上验证得最充分。如果你维护的是一个存量项目，且没有必须升级的理由，停在 5.12 是完全合理的选择。
这两个版本的共同风险在于生态正在萎缩。新出的第三方库越来越多地只提供 Qt 6 支持，一些开源项目的最新版本已经明确要求 Qt 6。所以如果你现在还在 5.9 或 5.12 上，要有心理准备：以后想引入新库，可能得自己动手改源码适配。
2.2 Qt 5.14 与 5.15.2：大多数人的最优解
Qt 5.14 是个非 LTS 的次版本，但装机量不小，因为它是很多开发板厂商BSP默认带的版本。它的高DPI支持已经默认打开，图表、串口、多媒体这些常用模块都齐全。坑在于它对某些新编译器的支持是"半吊子"状态，比如用较新的 GCC 编译时可能需要手动打补丁。
Qt 5.15.2 是整个 Qt 5 系列的终点站，也是目前存量项目里使用最广的一个版本。它最大的特点就是"什么都有"：MSVC 2019、MinGW 8.1 两套工具链的32/64位构建全都有，附加模块一应俱全，社区资料最多，遇到问题基本能搜到答案。如果你今天要启动一个以稳定性优先、不需要 Qt 6 新特性的项目，5.15.2 是最省心的答案。
但这个版本有几个必须在选型阶段就知道的坑。第一，它是免费用户的最后一站，之后的开源补丁需要自己编译源码维护。第二，它对高DPI的默认行为在 5.15 里发生了变化，从"需要手动开启"变成"默认开启"，如果你从 5.14 或更早版本迁移过来，界面缩放可能会突然变得不一样，需要重新调整。第三，部分模块在 5.15.2 的 MinGW 构建里是缺失的，比如 WebEngine 只提供 MSVC 版本，选 MinGW 套件时在安装器里根本看不到它。
2.3 Qt 6.x：新项目的默认答案，但代价要算清
Qt 6.2 是 Qt 6 的第一个 LTS，也是我认为"Qt 6 真正可用"的起点。在此之前，6.0 和 6.1 缺模块、缺文档、缺生态，拿来做正式项目风险很大。6.2 补齐了 Charts、DataVisualization、Multimedia 等模块，Qt 6 的基础体验才算完整。
Qt 6.5 是第二个 LTS，在 6.2 的基础上做了大量打磨，Graphics View、Quick 渲染、高DPI 处理都更成熟，是目前新建项目的推荐起点。Qt 6.8 是更新一代的 LTS，引入了不少图形和多媒体方面的新能力，但如果你依赖的第三方库还没跟上，可能需要等一两个季度。
Qt 6 的代价主要体现在三块。构建系统上，官方主推 CMake，qmake 虽然还在但没有新功能，团队要么学 CMake，要么承担后续迁移成本。API 上，一批 Qt 5 里常用的类被移到了 core5compat 模块，包括 QRegExp、QTextCodec、QLinkedList 等，迁移时需要显式链接这个兼容模块，而且它不保证永久保留。交叉编译上，Qt 6 强制要求指定 host 端的 Qt 路径（构建时用-qt-host-path指向宿主机上已安装的 Qt），这和 Qt 5 直接用-xplatform的流程差异很大，嵌入式团队第一次迁移时基本都会卡在这里。
2.4 一张表看清各版本定位
| 版本 | 类型 | 适用场景 | 主要坑点 |
|---|---|---|---|
| 5.9 | LTS | 老工业项目维护、Win7 环境 | 高DPI支持弱、生态萎缩 |
| 5.12 | LTS | 存量项目、第三方库兼容优先 | 新库支持减少 |
| 5.14 | 非LTS | 开发板BSP跟随 | 补丁停止、新编译器适配差 |
| 5.15.2 | LTS | 稳定交付的存量项目首选 | 免费补丁止步、WebEngine仅MSVC |
| 6.2 | LTS | Qt6 入门、模块齐全的起点 | 生态尚在完善 |
| 6.5 | LTS | 新项目推荐起点 | CMake学习成本 |
| 6.8 | LTS | 追新特性、图形密集型 | 第三方库跟进滞后 |
这张表不是让你照抄，而是给你一个快速定位的坐标系。真正的选择还要结合下一节讲的场景维度。
3. 按场景选版本：四类项目四个答案
脱离场景谈版本选择都是空谈。我把常见的Qt项目分成四类，每类的选型逻辑差别很大。
3.1 桌面工具与上位机：稳定压倒一切
这类项目的典型特征是：交付给内部或客户的 Windows 桌面程序，生命周期长，功能迭代慢，对界面美观度有一定要求但不极致。典型代表是各类配置工具、数据查看器、设备调试助手。
这类项目的选型逻辑很直接：能跑就行，别折腾。如果客户环境是 Windows 7/10 混合，Qt 5.15.2 配 MSVC 2019 是稳妥组合；如果客户环境统一是 Windows 10 以上，可以上 Qt 6.5。界面美观度靠 QSS（Qt Style Sheets）解决，自定义进度条、圆角窗口、渐变按钮这些需求，在 Qt 5 和 Qt 6 里用 QSS 都能做，区别不大。唯一的注意点是 Qt 6 对某些 QSS 属性的解析更严格，从 Qt 5 迁移过来时样式表可能需要微调。
打包发布用windeployqt就够，注意 Qt 5 和 Qt 6 的参数略有区别——Qt 6 用--no-opengl-sw替代了 Qt 5 的--no-angle。如果程序要在没有独立显卡的机器上跑，Qt 6 的软件渲染回退机制比 Qt 5 处理得更好。
3.2 嵌入式与交叉编译：版本由BSP决定
嵌入式场景下，Qt版本基本不是你能自由选的，而是由开发板厂商提供的BSP和工具链决定的。厂商的Yocto层里预置了哪个Qt版本，你大概率就用哪个。
这种情况下，能做的是在有限范围内优化。如果厂商给的是 Qt 5.14 或 5.15，直接用，别自己折腾升级，交叉编译环境重配一遍的成本非常高。如果确实需要 Qt 6，要先确认三件事：工具链的 GCC 版本是否达到 9 以上、sysroot 里是否已包含 Qt 6 需要的底层依赖（比如新的图形栈）、以及构建时能否正确指定 host 端 Qt 路径。
交叉编译的 configure 参数是另一个高频踩坑点。平台插件选择（-platform linuxfb、-platform eglfs、-platform xcb）要和板子实际的显示方案对应，选错了程序能起来但界面出不来。Qt 6 里还需要额外关注-qt-host-path的取值，它必须指向宿主机上同一版本的 Qt 安装，版本不一致会导致构建过程中出现莫名其妙的模块查找失败。
3.3 图表与绘图密集型：性能差异明显
如果你的项目里有大量实时曲线、动态图表、自定义绘图，版本选择对性能的影响会非常直观。
Qt 自带的 Charts 模块走的是 QGraphicsView 体系，在数据点上千、刷新频率几十赫兹的场景下，性能会明显吃紧。这时候常见的替代方案是 QCustomPlot 或 Qwt，两者都是基于 QPainter 直接绘制，性能好很多。QCustomPlot 对 Qt 5.12 到 5.15 的支持最成熟，在 Qt 6 上也能用但需要注意一些 API 调整。Qwt 的维护节奏偏慢，Qt 6 支持要看具体分支。
绘图本身的效率优化有通用套路：把曲线刷新放到独立线程里计算数据、只重绘脏区域、用setAttribute(Qt::WA_OpaquePaintEvent)减少背景填充、避免在 paintEvent 里做内存分配。Qt 6 的图形栈在抗锯齿和高DPI下的渲染效率比 Qt 5 有提升，如果你的项目是图形密集型且能接受迁移成本，Qt 6.5 是个合理选择。
3.4 需要国际化的多语言产品：注意兼容模块
国际化本身在 Qt 5 和 Qt 6 里流程差不多，都是lupdate提取、翻译、lrelease生成.qm文件、运行时用QTranslator加载。核心注意点在于版本迁移时的兼容问题。
Qt 5 里处理字符串编码经常用QTextCodec，这个类在 Qt 6 里被移到了 core5compat 模块，而且官方建议改用 QStringConverter。如果你的代码里有大量QTextCodec::codecForName("GBK")这样的调用，迁移时会比较痛。Qt 6 对源文件编码的处理更严格，默认按 UTF-8 解析，如果项目里还有 GBK 编码的源文件，编译时会直接报错或者出现乱码。
另一个细节是翻译文件的加载路径。Qt 6 在处理资源系统里的.qm文件时行为和 Qt 5 基本一致，但如果你用了QLocale::system()来判断语言，在高版本 Qt 里对系统区域设置的读取更准确，这可能导致之前"默认走中文"的逻辑变成"跟随系统"，测试时要注意。
4. 安装与多版本共存的实操
选定版本之后，安装和目录规划这一步值得认真做。我见过太多人的开发机被折腾成一团乱麻，装了三四个Qt版本，PATH 里一堆路径，最后连自己都说不清项目到底用的是哪个。
4.1 在线安装器还是离线包
官方提供两种获取方式：在线安装器（需要账号登录后勾选组件下载）和离线安装包（一次性下载完整安装镜像）。怎么选取决于你的网络环境和团队规模。
网络条件好的情况下，在线安装器的优势是灵活，可以只勾选需要的版本和套件，磁盘占用小。它的缺点是安装过程中断网就得重来，而且后期想补装组件还得重新跑一遍安装器。离线包的优势是可复用、可内网分发，适合团队统一环境或者需要在隔离网络中部署的场景。缺点是体积大，往往好几个G，而且一个离线包通常只对应一个Qt版本区间。
如果团队有多个人、有统一环境的诉求，我的做法是：用离线包制作一份标准的开发环境镜像，或者把离线包放在内网共享目录，新人入职直接安装。这样能避免"你的Qt版本和我的不一样"这类低级问题。
安装时的组件勾选有几个容易漏的点。Qt Creator本身和 Qt 库版本是独立的，安装器里的 Creator 版本可以单独选，它向下兼容多个 Qt 库版本。Additional Libraries里藏着 SerialPort、Charts、DataVisualization 这些模块，很多人装完发现unknown module(s) in qt: serialport，就是因为这里没勾。Sources组件体积很大，如果你不需要看 Qt 源码或调试进 Qt 内部，可以不装。Debugging Tools里的 CDB 调试器在 Windows 上很有用，配合 MSVC 套件可以做源码级调试。
4.2 多版本共存的目录规划
官方安装器默认把版本放在同一个父目录下，形如Qt/5.15.2/msvc2019_64、Qt/6.5.3/mingw_64。这种结构本身没问题，问题出在环境变量的配置上。
绝对不要把任何 Qt 的 bin 目录加进系统 PATH。这是我踩过的最大一个坑。一旦加了，你在命令行跑qmake -v时得到的版本永远是不确定的，取决于 PATH 里哪个路径排在前面。更糟的是，多个版本的 Qt DLL 混在 PATH 里，程序运行时可能加载到错误版本的库，直接触发cannot mix incompatible Qt library这类崩溃。
正确做法是让 Qt Creator 通过它的 Kit 机制来管理。Creator 里每个 Kit 显式指定 qmake 路径、编译器路径、调试器路径，项目选用哪个 Kit 就用哪套环境，互不干扰。命令行构建时，用 Creator 自带的终端（它会把选定 Kit 的环境变量临时注入），或者手动写一个设置环境变量的批处理脚本，用完就关掉当前终端。
4.3 命令行构建的环境准备
需要脱离 Creator 做命令行构建时（CI 流水线、自动化打包），环境变量必须显式设置。Windows 上的最小集合是：把目标 Qt 的bin放进 PATH 最前面、设置QTDIR指向 Qt 根目录、如果用了 MSVC 套件还要先调用vcvarsall.bat初始化编译环境。
# Windows 命令行示例，假设 Qt 5.15.2 MSVC2019 64位 set QTDIR=D:\Qt\5.15.2\msvc2019_64 set PATH=%QTDIR%\bin;%PATH% call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\Build\vcvarsall.bat" x64 qmake -vLinux 下同理，关键是把 Qt 的bin放在 PATH 前面，并确保LD_LIBRARY_PATH指向正确的 lib 目录。交叉编译时还要额外设置PKG_CONFIG_PATH和工具链的 sysroot。
export QTDIR=/opt/Qt/5.15.2/gcc_64 export PATH=$QTDIR/bin:$PATH export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH qmake -v这个习惯养成之后，你随时能确认当前终端到底在用哪个 Qt，省掉大量"为什么本地能编、CI 上编不过"的排查时间。
4.4 卸载与残留清理
Qt 的卸载是个容易被忽视的环节。官方安装器自带的卸载功能只删除它自己管理的文件，但项目构建产生的中间产物、Creator 的用户配置、以及散落在系统里的 Qt5Core.dll 之类的运行库不会被动。
彻底清理的思路是这样的：先用安装器卸载主程序，然后手动删除 Qt 安装根目录下残留的空文件夹；接着清理 Creator 的配置目录（Windows 在用户目录的 AppData 下，Linux 在~/.config下），这里存着 Kit 配置和最近项目记录；最后检查系统 PATH 里有没有残留的 Qt 路径，以及项目目录里的build-*文件夹和.pro.user文件。这些删干净，重装或者换版本时才不会出现"明明卸载了，怎么还在报旧版本的错"。
5. 高频报错溯源
Qt 的报错信息普遍偏晦涩，很多错误提示只说现象不说原因。这一节我把几个和版本强相关的典型报错拆开讲，每个都给出排查顺序。
5.1 unknown module(s) in qt: serialport
这个报错的完整形态通常是Project ERROR: Unknown module(s) in QT: serialport，或者构建时出现:-1: error: unknown module(s) in qt: serialport。字面意思是"不认识 serialport 这个模块"，但原因有四五种可能，按概率从高到低排查。
第一种，模块根本没安装。在线安装器里的 SerialPort 属于附加模块，默认不勾选。解决方法是重新跑安装器，在Additional Libraries下找到对应版本的 Qt SerialPort 勾上。这个原因占了实际案例的一多半。
第二种，项目文件里没声明。.pro文件里要有QT += serialport，用 CMake 的话要find_package(Qt5 COMPONENTS SerialPort REQUIRED)加target_link_libraries。这一条新手容易漏，但老手基本不会犯。
第三种，Kit 选错了。你的 Qt 5.15.2 里给 MSVC 套件装了 SerialPort，但项目当前选的是 MinGW 套件，那在 MinGW 这套环境里确实"不认识"这个模块。解决方式是切 Kit，或者给 MinGW 套件也装上该模块。
第四种，qmake 路径不对。系统里存在多个 Qt，qmake 命令实际调用的不是你预期的那个版本。用qmake -query QT_INSTALL_PREFIX确认一下当前 qmake 的安装根目录，能立刻判断出来。
第五种，交叉编译的 sysroot 里缺少该模块。嵌入式场景下，Qt 库是为目标板编译的，如果构建时没有把 SerialPort 编进去，目标平台上的 qmake 自然不认识它。这种情况需要重新配置并编译 Qt 源码，加上-qt-serialport之类的配置项。
注意：排查顺序建议从"模块是否安装"开始，这一步最快也最常见，别一上来就怀疑代码。
5.2 cannot mix incompatible qt library
完整的报错是Cannot mix incompatible Qt library (5.15.3) with this library (5.15.2)。这个错误信息其实很有价值，它直接告诉了你两个冲突的版本号。
根本原因是运行时加载了两个不同补丁版本的 Qt 库。补丁版本之间虽然 API 兼容，但 Qt 在内部会做版本校验，一旦检测到混用就直接终止程序，防止出现难以调试的内存问题。
排查思路是查加载路径。Windows 上可以用 Process Explorer 查看进程实际加载的每个 DLL 路径，Linux 上用ldd配合LD_DEBUG=libs观察库的加载顺序。常见的冲突源有几个：PATH 里存在另一个版本的 Qt 目录（这就是前面强调不要往 PATH 里塞 Qt 的原因）；某个第三方 DLL 是用另一个 Qt 版本编译的，并且静态链接了 Qt 的一部分；打包时windeployqt漏拷了某些库，程序回退到系统 PATH 里找，找到了旧版本。
解决方式很直接：保证程序目录下的 Qt DLL 版本完全一致。用windeployqt重新打包一遍是最省事的做法，它会按当前 Qt 版本的依赖关系补齐所有必需库。如果是第三方库引入的冲突，那只能联系库提供方要一个匹配版本，或者自己重新编译。
5.3 MinGW 与 MSVC 混用的连锁反应
这两套工具链的ABI不兼容，混用会产生一连串看起来毫不相关的错误。典型表现包括：链接阶段报一堆undefined reference或者 MSVC 的LNK2019；程序能编译通过但一启动就崩溃；界面能显示但某些功能静默失效。
我遇到过一个典型案例：项目主体用 MSVC 编译，引了一个用 MinGW 编的串口通信库，编译链接全部通过，运行时串口一打开就闪退。排查了很久才发现是库内部的 C++ 异常处理机制在跨 ABI 时失效了。
避免这类问题的方法只有一个：项目内所有组件统一工具链。引入第三方库之前先确认它是用什么编译的，如果拿不到源码只能拿预编译的二进制，那就以这个库的工具链为准，把整个项目迁过去。与其在混用的坑里挣扎，不如一次性统一。
5.4 打包发布时的依赖问题
windeployqt是发布环节的主力工具，但它不是万能的。常见问题是它只扫描直接依赖，动态加载的插件（比如图片格式插件、平台插件、数据库驱动）容易被漏掉。程序在开发机上跑得好好的，拷到客户机器上就报"could not find or load the Qt platform plugin windows"。
排查这类问题的方法是开启QT_DEBUG_PLUGINS=1环境变量再运行程序，它会打印出插件加载的详细过程，包括尝试了哪些路径、为什么失败。找到缺失的插件后，手动把它们拷到程序目录对应的plugins子目录下。
Qt 5 和 Qt 6 在打包参数上有区别，Qt 6 里--no-angle已经不存在了，取而代之的是--no-opengl-sw，控制是否打包软件渲染库。如果你的目标机器可能没有合适的显卡驱动，建议保留软件渲染库，虽然体积大一些，但兼容性更好。
# Qt 5 打包示例 windeployqt --release --no-translations --no-angle myapp.exe # Qt 6 打包示例 windeployqt --release --no-translations --no-opengl-sw myapp.exe6. 版本升级与长期维护
选版本只是开始，怎么在选定版本上安稳地过几年，是另一个话题。
6.1 从Qt 5迁到Qt 6的改动清单
如果决定迁移，先做一份差异清单会比直接动手改代码高效得多。按影响面排序，排在最前面的是构建系统，qmake 到 CMake 的转换是最大的一块工作量，.pro文件里的QT += xxx要翻译成find_package加target_link_libraries的组合，条件编译、自定义构建步骤的写法都要重写。
第二块是被移除的API。QRegExp 改用 QRegularExpression，QTextCodec 改用 QStringConverter，QVector 和 QList 在 Qt 6 里合并了，QLinkedList 被移除，QString 的一些隐式转换被收紧。Qt 提供了 core5compat 模块作为过渡，把 QRegExp、QTextCodec 这些老类暂时放了进去，链接这个模块能让迁移工作量降低不少，但要有心理准备它不会永久存在。
第三块是枚举和类型的变化。Qt 6 里的枚举大量改成了强类型，Qt::AlignLeft这类用法有些需要显式转换。数值类型方面，qint64相关的一些 API 签名有调整。这些改动零散但数量多，编译器的报错会一个个指出来，耐心清完就行。
第四块是高DPI行为。Qt 6 里高DPI缩放是强制的，AA_EnableHighDpiScaling这个属性已经不再生效，如果代码里有针对它的判断逻辑，需要清理掉。相关的还有QApplication::setAttribute里一批属性的废弃，建议逐个查文档确认。
实际操作时，我的建议是分阶段推进：先把构建系统切过去，保证能编出可执行文件；再处理编译器报错的API替换；最后跑一遍完整的回归测试，重点看界面布局和图形渲染这两块，这两处最容易出现视觉上的偏差。
6.2 团队版本统一的落地办法
团队里版本不统一是个隐形成本黑洞。同一个bug，别人的环境复现不了，你这边必现，最后发现是Qt版本差了一个补丁。
落地的办法有几个层次。最轻的是文档约定，在项目 README 里明确写清 Qt 版本、编译器版本、Creator 版本，新人照做。这个层次成本最低但约束力最弱。
中间一层是环境脚本化，把安装步骤写成脚本或者配置清单，包括离线包地址、组件勾选列表、环境变量设置，一键完成。这样能把人为疏忽降到最低。
最重的一层是容器化或者虚拟机镜像，开发环境做成统一镜像分发。这个在嵌入式交叉编译场景下尤其值得做，因为交叉编译环境的配置极其繁琐，镜像化之后能省掉每个人的重复劳动。代价是镜像维护本身需要有人负责。
我个人在中小团队里的建议是走中间路线：准备一份带注释的安装清单，配一个初始化环境变量的脚本，把它放进项目的tools目录里跟着代码走。这样版本信息本身就是代码的一部分，不会因为人员流动而丢失。
Concurrency 上补充一点，如果是多平台项目（Windows 开发、Linux 部署），两个平台的 Qt 版本尽可能对齐到同一个主次版本，能避免大量平台相关的诡异问题。
最后说个我在实际项目里反复验证过的小经验：新项目立项时，先把 Qt 版本号写进项目的技术选型文档并锁定，之后任何一次版本变更都要走一次评估流程。我见过太多项目是开发到一半因为某个库不兼容临时升级 Qt，结果引发一连串连锁反应，最后花的时间比一开始慎重选择多出好几倍。版本这件事，前期多花半天查资料，后期能省几周的返工。
