简介面向Windows平台Qt开发者的Qt 5.15.16编译成品库基于VS2019工具链构建可直接用于32位与64位桌面应用开发省去自行编译源码的繁琐流程。压缩包共约2000个文件、753.36MB以1548个h头文件为主体覆盖QtCore、QtGui、QtWidgets、QtTest、OpenGL及Vulkan等模块的类声明另含json模块元数据、pri工程配置及少量qxmlstream、qopengl相关头文件配合include、lib、plugins、bin四类目录分别承担头文件引用、库文件链接、插件扩展与部署工具运行等职责。已有874人学习下载适合需要稳定Qt运行库、希望快速搭建开发与调试环境的中级C开发者参考使用可据此完成工程配置、模块裁剪与跨平台应用构建。整体目录结构清晰便于按模块检索与集成。1. 从一次编译翻车说起Qt 5.15.16 在 Win10 VS2019 下的环境搭建去年帮某实验室配一台图像处理工作机需求很明确Qt 5.15.16 源码编译跑在 Win10 上编译器用 VS2019。听起来是套老组合网上教程一抓一大把结果第一次编译到一半直接卡死在nmake报错日志翻了几百行才发现是 Perl 路径里带了空格。这类玄学问题在 Qt 源码编译里太常见了——版本对不上、依赖缺一个、环境变量顺序错一位都能让你在configure阶段耗掉一整个下午。Qt 5.15.16 是 5.15 LTS 系列里比较靠后的维护版本很多还在维护老项目的团队会锁死这个版本而 VS2019 又是 Win10 上兼容性最稳的 MSVC 工具链之一这套组合的检索量一直不低。这篇笔记按我实际装机的顺序走一遍先列清环境再一步步配依赖、跑 configure、编译安装最后给一套验证和排错的办法。新手照着能走通熟手能对照看版本取舍和参数差异。2. 装前把环境列清Qt 5.15.16 的依赖清单与版本取舍2.1 为什么锁 Qt 5.15.16 VS2019 这套组合Qt 5.15 是 Qt5 最后一个 LTS 分支5.15.16 属于该分支后期的维护版本修掉了不少早期 5.15.x 的编译问题同时 API 层面已经稳定不会像 5.15.0/5.15.1 那样在 MSVC 下偶发 moc 生成异常。选它而不是直接上 Qt6主要原因是很多存量项目还在用 Qt5 的模块比如 QtWebEngine、QtCharts 的老接口迁到 Qt6 要改的信号槽和模块拆分成本不低。VS2019 这边MSVC 的 v142 工具集对 C17 支持完整且和 Qt 5.15 的官方构建脚本兼容性最好——Qt 5.15 的configure脚本对 MSVC 版本有探测逻辑v142 是它明确支持的一档再新的 v143VS2022虽然多数情况能编但个别模块会踩到编译器行为差异。版本上还有两个细节要提前定一是源码包用qt-everywhere-src-5.15.16完整源码含所有模块还是只下qtbase子模块。如果项目只用到核心 GUI 和网络qtbase单独编能省一半时间但一旦后面要加 QtWebEngine 或多媒体模块就得回头重编我一般直接上完整包一次到位。二是要不要编静态库。动态库shared是默认编完体积小、调试方便静态库static适合做单文件分发但编译时间长、对第三方库的许可有额外要求除非明确要静态发布否则别碰。2.2 依赖清单这些工具缺一个都编不过Qt 源码编译不是装个 VS 就完事它依赖一整套外部工具。下面这张表是我实际装机时逐项核对过的清单版本是我在这台 Win10 机器上验证通过的组合工具版本要求作用备注Visual Studio 201916.x含 v142 工具集提供 MSVC 编译器与 nmake安装时勾选「使用 C 的桌面开发」Python3.8.x构建脚本、部分模块生成不要用 3.12脚本有兼容问题Perl5.32.x如 Strawberry Perl构建系统依赖安装路径严禁含空格Ruby2.7.x 或 3.0.x部分模块如 QtWebEngine需要不编 WebEngine 可暂缓CMake3.16 以上部分子模块构建加入 PATHjom 或 nmakejom 1.1.x并行编译加速jom 比 nmake 快推荐7-Zip任意较新版本解压源码包源码是 .7z 或 .tar.xz这里有个容易被忽略的点Python 和 Perl 的位数要和编译器一致。VS2019 默认编 64 位那 Python 和 Perl 也必须是 64 位版本否则configure阶段探测脚本会报「找不到解释器」或者更隐蔽的「模块生成失败」。我见过有人装了 32 位 Strawberry Perl结果编译到 QtQml 阶段才炸日志里只有一行Perl exited with error排查半天。2.3 目录规划路径里别留空格和中文Qt 源码编译对路径极其敏感。源码目录、构建目录、安装目录三者的路径都不能含空格、中文、特殊符号。我一般这样规划# 目录规划示例Windows 路径实际在资源管理器或命令行创建 D:\qt-build\src\qt-everywhere-src-5.15.16 # 源码解压目录 D:\qt-build\build # 影子构建目录shadow build D:\qt-build\install # 安装目录为什么用影子构建源码目录外单独建 build 目录因为 Qt 的构建系统会在 build 目录里生成大量中间文件如果直接在源码目录里编清理时容易误删源码而且同一份源码想编不同配置debug/release、静态/动态时影子构建能让你并行维护多套构建产物。configure时用-prefix指定安装目录编完nmake install就会把库和头文件装到那里和系统里已有的 Qt 版本互不干扰。提示如果 D 盘空间紧张构建目录至少预留 30GB。完整源码编译的中间文件加最终产物体积比很多人预想的大得多。3. 配依赖与跑 configureQt 5.15.16 编译参数逐个说清3.1 装 VS2019 与初始化编译环境VS2019 安装时工作负载只勾「使用 C 的桌面开发」就够右侧的安装详细信息里确认「MSVC v142 - VS 2019 C x64/x86 生成工具」和「Windows 10 SDK」被选中。SDK 版本选 10.0.19041 或更新都行Qt 5.15.16 对 SDK 版本不挑但太老的 SDK 可能缺某些头文件。装完之后不要直接开普通 cmd 跑 configure必须先初始化 MSVC 环境。有两种方式我习惯用第二种# 方式一从开始菜单打开 x64 Native Tools Command Prompt for VS 2019 # 这个快捷方式已经帮你跑好了 vcvars64.bat # 方式二在普通 cmd 里手动调用路径按实际 VS 安装位置调整 call C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat # 验证环境是否就绪能输出版本号说明 cl 已进 PATH clvcvars64.bat的作用是把cl.exe、link.exe、nmake.exe以及 Windows SDK 的路径全部注入当前命令行会话的环境变量。这一步没做后面configure会报「Cannot find cl.exe」或者更绕的「编译器测试失败」。注意这个初始化只对当前命令行窗口有效关掉窗口就失效所以每次新开窗口编译都要重新 call 一次。这也是很多人「明明装好了却编不过」的根源——换了个终端忘了初始化。3.2 装 Python、Perl、jom 并配好 PATHPython 装 3.8.x安装时勾选「Add Python to PATH」。装完在命令行验证python --version # 期望输出Python 3.8.xPerl 用 Strawberry Perl 5.32.x 的 64 位 msi 包默认安装路径是C:\Strawberry这个路径没有空格保持默认即可。装完验证perl --version # 期望输出包含This is perl 5, version 32jom 是个独立的可执行文件从 Qt 官方下载页拿到jom.zip后解压到比如D:\tools\jom然后把该目录加进系统 PATH。验证jom /VERSION # 期望输出jom 1.1.xPATH 的配置顺序有个小讲究如果机器上同时装了多个 Python 或多个 Perl确保你要用的那个排在前面。Windows 的 PATH 是从前往后找的排后面的会被忽略。我一般把C:\Strawberry\c\bin、C:\Strawberry\perl\bin和 Python 的 Scripts 目录都显式加进去避免依赖某个安装器自动配的顺序。3.3 configure 参数一份能直接抄的配置进入构建目录调用源码目录里的configure.bat。下面这份参数是我在 Win10 VS2019 下验证通过的组合按需裁剪# 在 D:\qt-build\build 目录下执行 D:\qt-build\src\qt-everywhere-src-5.15.16\configure.bat ^ -prefix D:\qt-build\install ^ -opensource ^ -confirm-license ^ -release ^ -platform win32-msvc ^ -nomake examples ^ -nomake tests ^ -skip qtwebengine ^ -opengl desktop ^ -mp逐项说清楚每个参数在干什么以及什么时候该改-prefix指定安装目录编完jom install会把产物装到这里。-opensource -confirm-license是开源版授权确认不加会交互式提问脚本化构建时容易卡住。-release编发布版调试版用-debug两者都要就写-debug-and-release但编译时间翻倍。-platform win32-msvc指定平台插件VS2019 下就用这个不用改成 msvc2019 之类。-nomake examples -nomake tests跳过示例和测试能省大量时间除非你要参考示例代码。-skip qtwebengine跳过 WebEngine 模块——这个模块依赖 Chromium编译极其耗时且对 Python、Ruby 版本敏感不需要浏览器内核的项目直接跳过。-opengl desktop用桌面 OpenGL 而非 ANGLE在有独显的机器上性能更好如果目标机器显卡驱动老旧可以改成-opengl dynamic让 Qt 运行时选择。-mp开启 MSVC 多进程编译配合 jom 能进一步压榨多核。注意-skip后面跟的是模块名多个模块用空格分隔比如-skip qtwebengine qtwebview。跳过的模块后面想补编得重新跑 configure不能单独补。configure 跑完会输出一份摘要重点看三处一是「Build type」是不是 release二是「Qt modules」列表里你要的模块是否都在三是末尾有没有报错。如果摘要里某个模块显示「no」而你确实需要往上翻日志找原因通常是缺依赖。3.4 编译与安装jom 并行编译的节奏控制configure 通过后直接jom开始编译。完整源码在 8 核机器上大概要 1.5 到 3 小时取决于跳过了多少模块。命令很简单# 在 build 目录下确保当前命令行已初始化 vcvars64 jom # 编译完成后安装到 -prefix 指定的目录 jom installjom默认按 CPU 核心数并行如果机器内存吃紧比如 16GB 以下并行度过高会导致链接阶段内存溢出表现为fatal error C1060: compiler is out of heap space。这种情况加-j4限制并行数jom -j4编译过程中如果中断重新跑jom会从断点继续不用从头来——这是 jom 相比 nmake 的一个实用优势。但要注意如果中断是因为改了 configure 参数那必须清空 build 目录重来增量编译在参数变更后不可靠。4. 编译翻车现场Qt 5.15.16 常见报错与排查4.1 现象configure 报「Cannot find appropriate Python」原因通常是 Python 没进 PATH或者装的是 Microsoft Store 版 Python它的路径在WindowsApps下权限和路径都特殊。解决卸载 Store 版装 python.org 的 3.8.x 官方安装包安装时勾选 Add to PATH然后重开命令行验证python --version。如果 PATH 里有多版本用where python看实际命中的是哪个。4.2 现象编译到 QtQml 阶段报「Perl exited with error」原因多半是 Perl 路径含空格或者装的是 32 位 Perl 配 64 位编译器。解决确认where perl输出的是C:\Strawberry\perl\bin\perl.exe这类无空格路径用perl -V:archname看架构64 位应输出MSWin32-x64-multi-thread。不匹配就重装 64 位 Strawberry Perl。4.3 现象链接阶段报「LNK1104: cannot open file xxx.lib」原因通常是 Windows SDK 版本和 VS2019 不匹配或者 SDK 安装不完整。解决打开 VS Installer修改 VS2019在「单个组件」里确认 Windows 10 SDK 已勾选且版本不低于 10.0.19041然后在 vcvars64 初始化后跑where link确认链接器路径正确。还有一种可能是杀毒软件锁住了中间文件临时关闭实时防护再编一次。4.4 现象jom 跑到一半报「out of heap space」原因是并行编译内存不足尤其在链接大型模块如 QtWebEngine、QtDeclarative时。解决降低并行度jom -j4或jom -j2或者关掉其他吃内存的程序。16GB 内存的机器编完整源码建议-j4起步。4.5 现象编译成功但 install 后程序运行报「找不到 Qt5Core.dll」原因是运行时没找到安装目录的 bin。解决把D:\qt-build\install\bin加进系统 PATH或者在 Qt Creator 的 Kit 里把 Qt 版本指向安装目录。验证方法是在命令行跑D:\qt-build\install\bin\qmake -v能输出版本号说明安装目录结构完整。5. 装完怎么验证三步确认这套 Qt 5.15.16 真的能跑编译装完不等于能用我一般走三步验证缺一步都不放心。第一步验证 qmake 和版本号。在初始化过 vcvars64 的命令行里执行D:\qt-build\install\bin\qmake -v # 期望输出QMake version 3.1 # Using Qt version 5.15.16 in D:/qt-build/install/lib版本号必须是 5.15.16路径必须指向你的安装目录。如果版本号对但路径指向系统里另一个 Qt说明 PATH 顺序有问题把安装目录的 bin 提到前面。第二步编一个最小 GUI 程序验证工具链闭环。建一个临时目录写两个文件# main.cpp #include QApplication #include QLabel int main(int argc, char *argv[]) { QApplication app(argc, argv); QLabel label(Qt 5.15.16 OK); label.show(); return app.exec(); }# 在同目录下生成工程文件并编译 D:\qt-build\install\bin\qmake -project D:\qt-build\install\bin\qmake jom # 运行生成的 release 目录下的 exe能弹出窗口显示文字即通过这一步同时验证了 qmake 工程生成、MSVC 编译链接、Qt 库链接、运行时 DLL 加载四个环节。窗口能弹出来说明整套环境是通的如果编译过但运行报缺 DLL回到 4.5 检查 PATH。第三步验证你要用的具体模块。比如项目用到 QtNetwork就在 main.cpp 里加一行#include QTcpSocket并实例化一个对象重新编译。模块级验证能提前暴露「configure 时漏了某模块」的问题比等到项目集成时才发现要省事得多。验证项命令/操作通过标准qmake 版本qmake -v输出 5.15.16 且路径正确最小 GUI 编译qmake jom生成 exe 且窗口正常显示模块可用性引入目标模块头文件重编编译链接无报错这套流程走完环境基本可以交付使用。从那以后我每次编 Qt 源码都会在 configure 之前先跑一遍where python、where perl、cl三条命令确认环境再开始编译——这三条命令花不了十秒但能挡掉八成以上的翻车。希望帮到你。本文还有配套的精品资源点击获取