简介：Qt 5.15.16编译包面向Windows 10与Visual Studio 2019环境下的C++开发者，预先完成32位及64位架构编译，省去自行下载源码、配置依赖、处理编译报错等繁琐步骤。包内共2000个文件，其中h头文件多达1548个，覆盖Qt Core、Gui、Widgets、Network、Test等常用模块；另有json配置文件和pri工程文件，便于项目集成与模块管理。压缩包整体约753.36MB，按include、lib、plugins、bin四个目录组织：include存放全部Qt API头文件，lib提供链接所需的库文件，plugins包含可扩展插件，bin内置windeployqt等部署与调试工具。该编译包既适合初学者直接搭建开发环境，也适合中高级开发者按需选用组件，配合VS2019快速构建桌面、移动或嵌入式应用，同时保持Qt的模块化优势，有效控制工程体积；正确配置包含目录与库目录后，即可调用Qt的类与函数完成界面、网络、数据库等常见开发需求。已有863人学习下载，资源结构清晰，可作为Windows下Qt开发的可靠基础。 如果你在 Windows 上用 Visual Studio 2019 开发 Qt 程序，大概率会遇到这样一个尴尬局面：官方安装器只预置了 5.15.2 之类的早期补丁版本，而项目因为安全修复或者某些新特性，需要升到 Qt 5.15.16，官方偏偏没有提供现成的 MSVC2019 二进制包。这时候唯一的出路就是自己拿源码编译一遍。
这篇博文就基于我在 win10 + VS2019 环境下编译 Qt 5.15.16 的完整过程来写，从工具链准备、configure 参数选择、jom 并行编译，到 VS2019 集成、常见报错排查，全部走一遍。内容适配两类读者：一类是刚接触 Qt 源码编译的新手，需要一套能直接照抄的步骤；另一类是已经编过包、但这次想梳理清楚参数含义和排查思路的开发者。
1. 项目概述与版本选型思路
1.1 为什么非要从源码编译
Qt 5.15 系列是 Qt 5 的最后一个 LTS 版本，官方对源码的维护一直持续到 2025 年 5 月左右，5.15.16 就是这条分支里比较靠后的补丁版，修复了不少 Qt 5.15 早中期的崩溃问题和 CVE 安全漏洞。但官方在线安装器里并不会实时同步所有补丁版本，尤其是 MSVC2019 的预编译包，能下到的往往不是你要的那个版本。
另外，预编译包通常只提供默认配置：动态链接、Release + Debug、附带一大堆模块。如果你需要静态链接、自定义裁剪模块、集成自己的 OpenSSL 构建，或者项目里必须用某个具体补丁版本，靠自己编译几乎是唯一可靠的路。拿我这次来说，项目需要升级到 5.15.16，同时想顺手裁掉 webengine 这类体积大头，官方包完全满足不了，所以只能源码走一遍。
1.2 版本与环境的对应关系
动手之前，先把版本对应关系理清楚，这一步能避免一半以上的低级错误。
| 组件 | 推荐版本/要求 | 说明 |
|---|---|---|
| 操作系统 | Windows 10 64 位，21H2 或更新 | 较老版本也能编，但 SDK 兼容性需要额外处理 |
| 编译工具链 | Visual Studio 2019 16.11.x，MSVC v142 | 不要混用 VS2022 的 v143 工具集 |
| Windows SDK | 10.0.19041.0 或更高 | 影响 configure 对系统环境的检测 |
| 源码包 | Qt 5.15.16 (qt-everywhere-opensource-src-5.15.16) | 单文件约 500MB，解开后 2~3GB |
| Perl | Strawberry Perl 5.32 或 ActivePerl 5.28+ | 处理第三方库的构建脚本 |
| Python | Python 3.7~3.10 | 用于新模块的代码生成器 |
| CMake | 3.16 以上 | 部分第三方依赖编译需要 |
| 构建工具 | jom 或 ninja | nmake 单线程太慢，不推荐 |
如果只编译 qtbase（Qt 的核心模块），依赖可以很少，Perl 甚至不一定用得上。但一旦涉及 qtdeclarative、qtquick3d、qtwebengine 等模块，Python、CMake、Perl 全都跑不掉。所以建议一次性装齐，省事。
2. 环境准备与依赖工具链
2.1 VS2019 安装组件勾选
VS2019 安装时，在“工作负载”标签页勾选“使用 C++ 的桌面开发”，这是基础。但很多人装完之后编译 Qt 会报找不到 windows.h 或者某些 SDK 头文件，问题往往出在“单个组件”里的 Windows SDK 没选对。
我常用的勾选组合是：
- 工作负载：使用 C++ 的桌面开发
- 单个组件：Windows 10 SDK（选一个稳定版本，比如 10.0.19041.0，同时勾上对应的 UCRT SDK）
- 单个组件：MSVC v142 - VS 2019 C++ x64/x86 生成工具
- 可选：C++ CMake tools for Windows（如果你打算走 CMake 路线）
这里有一个容易忽略的点：VS 更新到 16.11 之后，默认可能同时装了 v142 和 v143 工具集。编译 Qt 时一定要明确用 v142，否则 configure 阶段可能检测出不同的编译器环境，导致后续链接时出现一堆 msvcp140.dll 版本不匹配的问题。我都是在 x64 Native Tools 命令行里通过环境变量把工具集锁死。
2.2 Perl、Python、CMake 与 Ninja
- Perl：Qt configure 脚本里有些第三方库的构建步骤会调用 perl，比如 libpng、openssl 的处理脚本。建议装 Strawberry Perl，安装后把
C:\Strawberry\perl\bin加到系统 PATH。不装也能编纯 qtbase，但编到 qtimageformats 等模块时可能直接报错。 - Python：Qt5.15 的 qmltyperegistrar 等工具依赖 Python 3，建议装 Python 3.8 或 3.9，同样加入 PATH。我这里特别提醒：如果机器上装了 Maya、Blender 这类自带 Python 的软件，PATH 顺序一定要把正式 Python 放前面，否则 configure 会检测到一个版本号不满足要求的 Python，然后直接失败。
- CMake：Qt 5.15 的主构建系统是 qmake，但部分第三方测试组件和 Chromium 相关模块会用 CMake。装最新稳定版即可，不用特意配环境变量，安装器默认会写入 PATH。
- Ninja / jom：两个并行构建工具，二选一。我后面专门讲这两者的选择，这里只说结论：MSVC 环境下我默认用 jom，Ninja 作为备选。
提示：安装完这些工具后，建议在命令行里逐个执行
perl --version、python --version、cmake --version，确认命令都能识别。如果哪一条显示未知命令，先处理 PATH 问题再继续，不要带着残缺的工具链往下走，Quit.
2.3 命令行环境与目录路径规划
这一点属于老生常谈，但每次写编译教程我都想再强调一遍：在 Windows 上编译 Qt，请从开始菜单打开“x64 Native Tools Command Prompt for VS 2019”，而不是用普通的 PowerShell 或 CMD。因为前者会自动设置INCLUDE、LIB、PATH等环境变量，指向正确的 MSVC 工具链和 SDK 路径。如果你非要在 PowerShell 里一步步 source vcvarsall.bat，容易漏掉某个环境变量，而且 Qt configure 检测环境时对某些变量的敏感度非常高。
目录路径必须满足两个条件：
- 路径不能包含中文，不能包含空格。
- 源码目录、构建目录、安装目录最好三个分开。
我这次用的是：
D:\qt\src # 源码解压目录 D:\qt\build # 构建目录（configure 在源码目录外执行） D:\qt\5.15.16\msvc2019_64 # 最终安装目录（-prefix 指定）为什么要源码/构建/安装三分开？因为 Qt 支持在源码目录之外构建，构建目录里会生成一大堆 obj 文件和临时文件，如果和源码混在一起，后续想换 configure 参数重新编译，或者同时保留 Release 和 Debug 两套构建，基本没法管理。第一次编译的时候图省事把构建目录放在源码目录内部，结果换参数重新 configure 时，各种残留文件导致检测结果错乱，只能重新解压源码，白白浪费半个多小时。
3. 源码获取与目录规划（实操）
3.1 从官方渠道获取 Qt 5.15.16 源码
Qt 5.15.16 的源码可以从两个渠道获取：官方在线安装器里勾选“Source”组件，或者从 Qt 官方 Git 仓库拉取对应分支。我更推荐 Git 方式，因为可以精确 checkout 到指定 tag，还能省去安装器下载整个 Qt 其他组件的额外时间。
git clone https://code.qt.io/qt/qt5.git cd qt5 git checkout v5.15.16 perl init-repositoryinit-repository这一步是 Qt 多仓库项目的关键，它会拉取 qtbase、qtdeclarative、qtsvg 等所有子模块到对应目录。网络不太好的时候，这个过程可能反复失败，我习惯多执行几次，直到所有子模块的状态正常。拉完源码后，用dir /s或者 du 工具看一下整体体积，一般在 2GB 以上。
如果不想走 Git，也可以直接从下载页拿 qt-everywhere-opensource-src-5.15.16.zip，解压后就是一份完整的源码树，不需要再执行 init-repository。两种方式效果差不多，区别在于 Git 仓库后续升级补丁版本更方便。
3.2 磁盘空间估算与 C 盘清理
编译 Qt 需要不少磁盘空间，我先给一个估算值：源码包 2~3GB，构建目录 5~8GB，最终安装目录 2~3GB，整体占用空间约 10~15GB。如果你的 C 盘空间比较紧张，建议先做一轮清理再开始，否则编译到一半报磁盘空间不足，几乎只能删除重来。
C 盘清理的几个实用技巧：
- 用磁盘清理工具清理 Windows 更新缓存和临时文件。
- 把虚拟内存（页面文件）转移到其他盘，或者把它设为系统管理的大小。
- 查看
C:\Users\用户名\AppData\Local\Temp下是否有可清理的大文件。 - 如果之前装过其他 Qt 版本，把不用的安装目录直接删掉。
我这次先把源码和构建目录都放在了 D 盘，编译过程没有碰到磁盘不够的问题。但如果你源码放在 C 盘，请务必确认空间充裕。
3.3 工具链自检与 configure 前置检查
进入命令行环境后，先把目录切换到源码路径，做一次快速自检：
perl --version python --version cmake --version where jom where nmakewhere jom这一步很关键：jom 是独立下载的构建工具，需要手动把可执行文件放到 PATH 里，或者直接放在 Qt 源码根目录下。configure 脚本检测到 jom 存在时，会自动推荐你用 jom 编译，省去后续手动切编译器环境的麻烦。如果检测不到 jom，也没关系，configure 完成时会提示你用nmake，但你要清楚，那个速度会让人怀疑人生。
我这里提前把 jom 解压到了D:\qt\tools\jom，并把该目录加进 PATH，保证 configure 能检测到。
4. configure 与编译参数详解
4.1 configure 参数的选择逻辑
configure 是编译 Qt 最核心的一步，它的作用类似于 Linux 下的 ./configure，负责检测机器环境、生成 Makefile 和 qmake 配置。参数含义不理解，后面很容易在排错时抓瞎。
我这次使用的 configure 命令是：
configure -prefix D:\qt\5.15.16\msvc2019_64 ^ -opensource -confirm-license ^ -release -shared ^ -nomake examples -nomake tests ^ -skip qtwebengine -skip qt3d -skip qtquick3d ^ -mp如果是在 PowerShell 环境，多行连接符从^换成反引号`，或者干脆写成一行。参数拆开解释：
-prefix：最终安装路径。qmake 会把这个路径写死在配置信息里，后期用qmake命令生成 Makefile 时，头文件和库文件的路径都基于它。-opensource -confirm-license：声明使用开源协议并跳过确认。Qt 5.15 系列依然是 GPL/LGPL 协议，商用前要自行评估 License。-release：只生成 Release 版本。如果需要调试 Qt 源码，应该用-debug-and-release，但代价是编译时间和磁盘空间翻倍，我这次用不到调试，所以只编 release。-shared：动态链接方式，默认值。Qt 官方提供的预编译包也是 shared，这个选项基本可以省略，但写出来更明确。-nomake examples -nomake tests：不编译示例和测试程序。这一步能省出不少时间，如果你是学习用途，想看示例代码，可以去掉这两个参数。-skip：跳过指定模块。qtwebengine 是 Chromium 内核，一编译就是几小时起步；qt3d 和 qtquick3d 体积大、依赖多，如果你用不到 3D 相关接口，果断 skip。-mp：是 Qt 自己发明的多进程编译选项，配合 jom 使用可以并行编译多个子模块，比单线程 nmake 快好几倍。
4.2 jom 还是 Ninja
Qt 5.15 的构建系统是 qmake，底层在 Windows 上默认生成 nmake 的 Makefile。nmake 本身不支持并行编译，所以需要额外的工具：
- jom：nmake 的克隆增强版，支持
-j参数并行编译，是 Qt 官方推荐的 Windows 构建工具，兼容性最好。我在实际使用中几乎没出过问题。 - Ninja：需要在 configure 时加上
-make ninja参数，生成 Ninja 的构建规则。Ninja 的并行速度实测比 jom 快 10%~15%，但偶尔会遇到路径解析或环境变量设置的问题，排查起来更麻烦。
我的建议：如果不追求极致速度，直接用 jom。毕竟 Qt 源码编译动不动几千个文件，jom 的-j8已经能把 8 核 CPU 吃满，时间差异在可接受范围内。Ninja 路线更适合平时熟悉 CMake + Ninja 工作流的开发者。
4.3 完整编译执行流程
configure 执行完后，没有任何报错的话，就可以开始正式编译了。我用 jom 的命令：
jom -j8 > build.log 2>&1-j8表示并行任务数，理论上和 CPU 物理核心数相同即可，不需要一味调大。如果 CPU 支持超线程（16 线程），-j16也不会慢太多，但内存占用会明显上升。编译期间记得打开任务管理器关注内存，如果内存占比接近 100%，就要考虑降并发了。
这里还有一个实操技巧：构建过程一定要把日志重定向到文件。编译几十分钟甚至两小时，屏幕滚动是看不完的，最后通过搜索日志里的error关键字来定位问题：
findstr /C:"error" build.log编译耗时参考：8 核 CPU + 16GB 内存的物理机，跳过 webengine 只编常用模块，大约 40~60 分钟。如果是虚拟机 4 核 8GB，可能要 2 小时以上。
提示：configure 完成时会提示你“Qt is now configured for building. Run 'jom' (or 'nmake') to build Qt.”。此时不要急着关窗口，先确认一下提示里推荐的是不是 jom，如果它检测不到 jom 会推荐 nmake，那就需要回到 4.2 处理一下。
5. 运行验证与集成到 VS2019
5.1 验证编译产物
编译结束的画面一般是“Qt is now configured for building”或者时间的回显，具体模块输出各不相同。先不急着高兴，到安装目录D:\qt\5.15.16\msvc2019_64下确认关键产物：
bin\qmake.exe存在lib\cmake\Qt5目录下能看到各模块的 CMake 配置文件mkspecs目录存在，且里面有win32-msvc等目录
最简单可靠的验证方式，是直接用自带的 qmake 编译一个最小测试项目。新建一个文件夹，放一个 main.cpp：
#include <QApplication> #include <QLabel> int main(int argc, char *argv[]) { QApplication app(argc, argv); QLabel label("Qt 5.15.16 build test"); label.show(); return app.exec(); }然后在该目录下执行：
D:\qt\5.15.16\msvc2019_64\bin\qmake -project D:\qt\5.15.16\msvc2019_64\bin\qmake jom如果没有报错，生成的 exe 在相同目录下，双击能弹出一个窗口，说明编译产物基本可用。这一步我在每次编译完成后都会做，它验证的不只是 qmake，还顺带验证了头文件搜索路径、库目录、动态库 DLL 的联动，一步到位。
5.2 VS2019 集成 Qt VS Tools
VS2019 默认不认识 Qt 项目，需要安装扩展“Qt Visual Studio Tools”。打开 VS2019 的“扩展 → 管理扩展”，搜索 Qt，找到“Qt Visual Studio Tools”安装并重启 VS。
重启之后，菜单栏多出“Qt VS Tools”，进入“Qt Versions”页面，添加我们编译好的路径D:\qt\5.15.16\msvc2019_64，VS 会自动识别版本号并显示为 5.15.16。到这里，新建项目时就能看到 Qt Widgets Application、Qt Console Application 等模板，头文件、库路径也会自动配置好。
5.3 与官方预编译包的共存策略
很多开发者的机器上本来就装了官方安装器的 Qt 5.15.2，现在又要加一个自己编译的 5.15.16，没问题，Qt VS Tools 里可以同时列出多个版本，按项目切换。但有一点特别提醒：同一个项目里不要混用自己编译的 Qt 模块和官方预编译包里的 Qt 模块。因为两者的编译选项、运行时库、依赖的 OpenSSL 版本都可能不同，混用容易造成运行时崩溃或者奇怪的链接错误。
另外，我们这次是 Release 版，如果用调试模式跑，可能出现 qwindows.dll 找不到的问题，这是正常的，因为 release 版没有调试符号和调试版插件，需要用-debug-and-release参数重新编译一版。
6. 常见编译报错与排查实录
6.1 qml 编译错误：qmltyperegistrar 无法运行
编译 qtdeclarative 模块时，最常碰到的错误是类似qmltyperegistrar: command not found或者 Python 相关的报错。这个问题的根源基本都在 Python 环境上：Qt 5.15 的 QML 类型注册器依赖 Python 3 来执行代码生成脚本，如果 configure 时检测到的 Python 版本过旧，生成脚本就无法执行。
排查方式：
python --version如果版本号是 2.7，或者系统里同时装了多个 Python 导致 PATH 顺序混乱，把 3.x 的 Python 路径提到最前面，再重新 configure。另外注意，某些 IDE（比如 Anaconda 自带的 Python）也可能干扰检测，稳妥做法是只保留一个 Python 在 PATH 里。
6.2 fatal error C1060: compiler is out of heap memory
这个报错在编译体积特别大的源文件时出现，比如 qtdeclarative 里的某些动画框架源码，或者 qtwebengine 的绑定代码。直接原因就是物理内存不够，编译器没法为中间代码分配足够的堆空间。
处理方案：
- 关闭所有不必要的占内存程序，比如 Chrome 开几十个标签页肯定不行。
- 降低 jom 并行数，从
-j16改到-j8或-j4，内存压力会明显下降。 - 如果根本不需要 webengine，直接在 configure 里
-skip qtwebengine，这个模块是内存大户。
另外还有一种情况：系统页面文件太小。可以在“系统属性 → 高级 → 性能设置 → 高级 → 虚拟内存”里，把 D 盘设置一个足够大的系统管理大小。我在 16GB 物理内存的机器上默认不设置虚拟内存，编译大模块时偶发内存不足，改成系统管理后就没再出现过。
6.3 configure 阶段第三方库下载超时
Qt configure 过程中会自动下载部分第三方依赖包，比如 libpng、openssl、xcb 等。网络状况不好时，经常卡在某个下载步骤，看起来像死了一样。这时候很多人以为是 configure 卡住了，其实是在默默重试。
我的经验是：不要傻等，先看日志。configure 输出中会提示正在下载哪个文件，如果确认是下载卡住，可以手动把该文件放到源码目录下对应的位置。更省事的方案是提前把所有依赖包都放到本地，Qt 会优先检查本地缓存目录。
另外，如果公司网络有下载限制，可以试试走镜像源。这只涉及普通的网络资源配置，不牵扯任何特殊工具，思路就是让 Qt 的下载脚本从更近的地址拉取文件，减少超时概率。
6.4 MSVC 中文注释导致的编译报错
这个虽然不完全是 Qt 编译的问题，但在 VS2019 环境下非常高频。如果源文件里的中文注释是以 UTF-8 无 BOM 格式保存的，MSVC 默认按本地代码页（一般是 GBK）去解读，会触发 C4819 警告或者 C2001 这类语法错误，导致编译直接失败。
解决办法有两条：
- 把所有源文件另存为 UTF-8 with BOM 格式。
- 在项目属性里加上
/utf-8编译选项，强制 MSVC 按 UTF-8 解析源码。
如果你是从 Qt 官网下载的源码，一般不会出现这个问题，但自己动手改过 Qt 源码或者写业务代码时的中文注释，就可能踩这个坑。
6.5 某个模块单独失败，其他模块正常
这是最让人崩溃的报错形态之一：整体编译时 qtbase 通过，qtdeclarative 通过，偏偏 qtsvg 或者 qtimageformats 挂了。排查思路是先不整体编译，单编出现问题的模块，加上详细输出：
cd D:\qt\build\qtsvg jom -j8 -v-v参数能看到每一个子模块的具体编译命令行，错误通常会指向某个缺失的第三方依赖或者某个函数的重定义。如果确实不需要这模块，直接在 configure 里-skip qtsvg，但建议先确认是不是缺依赖，免得影响其他模块的关联功能。
6.6 安装目录命名的小建议
最后说一个不是报错但很多人犹豫的点：-prefix路径的名字怎么起。我习惯写成msvc2019_64，这样在 Qt VS Tools 里看到这个版本号，一眼就知道是什么编译器、什么位数。如果你同时编译了 32 位版，就改成msvc2019，两个版本可以并存，互不干扰。
写在最后
自己编译一次 Qt，本质上是一次对 Windows 工具链的全身体检。VS2019、Windows SDK、Perl、Python、CMake、并行构建工具体系，哪个环节断了都会在编译过程中暴露出来。我最初编译 Qt 是为了解决项目升级版本的问题，后来发现这套流程对理解 qmake 构建系统、Qt 模块之间的依赖关系，帮助特别大。
几个从实际操作中记住的经验：
- 工具链版本一定锁死：VS2019 + MSVC v142 + Win10 SDK，别混用。
- 并行度不建议盲目拉满，物理核心数 +1 就好。
- 日志一定要保留，一切报错从搜索 error 关键字入手，别靠肉眼看滚动。
- 源码、构建、安装三个目录分开，想清清爽爽地换参数重新编译，这个习惯能省很多事。
如果你是因为“官方没有现成 5.15.16 的 MSVC2019 包”才搜到这篇文章，按照上面的步骤走一遍，大概率能顺利编出来。编完之后，后续再遇到其他没有官方预编译包的 C++ 库，基本都能按同一套思路搞定。
本文还有配套的精品资源，点击获取
