简介QT 5.15.16编译包基于Windows 10与Visual Studio 2019环境构建面向需要开发跨平台GUI应用的C工程师可同时产出32位与64位架构支持。整个压缩包共2000个文件体积约753.36MB其中包含1548个C头文件覆盖QtCore、QtGui、QtTest、QtCharts等核心模块声明另有若干json与pri文件用于辅助配置目录结构清晰集成include、lib、plugins、bin四大模块。include内头文件提供函数、类与宏声明是调用Qt框架的必要接口lib内预编译库文件供链接器合并生成可执行程序plugins提供可扩展插件bin则包含部署调试工具。已有866人学习下载适用于希望跳过源码编译、直接获得可用Qt库的开发者能够在VS2019中快速链接并搭建应用程序显著节省环境配置与依赖管理时间。1. QT 5.15.16编译win10vs2019下自己动手值不值Qt 5.15.16 这个版本号对做桌面开发的人并不陌生5.15 是开源版里最后一个长期支持的稳定序列5.15.16 则是这条分支上的修补版本修了不少崩溃和兼容性问题。麻烦在于 5.15 之后开源版想拿到官方现成的二进制安装包越来越难很多团队直接选择自己编译。在 win10 上用 vs2019 工具链编一套 Qt 5.15.16看着流程很长真正走通后你会发现它就是 configure、nmake、install 三步循环难点全在参数取舍和环境坑。下面按实际操作顺序来讲先配环境再给 configure 参数清单接着并行编译和安装最后列五个高频报错的排查路径。适合要换 Qt 版本、定制编译参数、被旧版 bug 卡住的开发者新手照步骤也能完成。2. 编译前规划源码、工具链与磁盘空间一次配齐编译 Qt 最怕的不是代码本身而是环境里缺东西。许多人 configure 跑一半报错回头一查是 PATH 里没有正确的工具链。所以这一章先把环境要求讲清楚再动手。2.1 源码包与vs2019工具链的匹配关系Qt 官方发布的源码包分两类一类是只包含核心库的 qtbase 单模块包另一类是 qt-everywhere 整包。对 5.15.16 来说既然要自己编译建议直接拉整包省得后面发现缺模块再回头补。整包会把 qtbase、qtdeclarative、qtmultimedia、qtwebengine 等模块全部包含编译时用 -skip 参数按需切除即可。单模块包的优点是体积小、下载快缺点是模块间的依赖关系要自己梳理。比如你只要 QtGui但它依赖 QtCore、QPA 平台插件等一堆基础组件单包模式下你不得不逐个下载编译折腾的时间比省下的下载量多得多。整包虽然第一步解压很慢但 configure 会统一处理依赖后续维护更省心。工具链方面vs2019 对应的编译器是 MSVC v142 工具集Qt 官方 msvc2019 二进制版本用的就是这一套。自己编译时不需要刻意匹配某个内部版本号只要确保 vs2019 安装了「使用 C 的桌面开发」工作负载并且包含 MSVC 编译器、Windows SDK 和 CMake 工具。这三个组件默认会随工作负载装上但如果你当初只装了 VS 的 IDE就不能编译 Qt。Windows SDK 的版本不需要精确对齐某一年份最新的 Win10 SDK 配合 vs2019 的更新补丁就能通过 Qt 5.15 的编译检测。这里有个经验与其纠结 SDK 的补丁号不如把 vs2019 的组件更新到最新因为 Qt 源码里的生成脚本对新版本头文件的兼容性通常更好反过来和旧版 SDK 的坑更多。2.2 用开发者命令行确认编译器、perl与python的可见性编译 Qt 还需要三个外部程序MSVC 编译器cl.exe、Perl、Python。Perl 主要用于生成翻译文件和构建脚本Python 是部分模块辅助脚本的依赖。缺 Perl 或 Pythonconfigure 会在检测阶段直接报错或默默跳过对应模块所以提前确认它们都在 PATH 里。检查方式就是打开 vs2019 自带的「x64 Native Tools Command Prompt for VS 2019」开发者命令行依次执行下面几条where cl where nmake where perl where python如果 cl 和 nmake 能输出路径说明工具链正确。perl 和 python 显示为「未找到」的话需要先安装。安装 Perl 时勾选「Add Perl to the PATH」Python 同样勾选加入 PATH。装完务必重开命令行再验证一次因为 PATH 的修改不会自动同步到已打开的窗口。这里有个常见坑有人图省事从系统的应用商店装 Pythonwhere python 能输出路径但执行 python --version 却打开商店安装页。这种玄学问题很好躲直接装官方 Python 安装包选「Customize installation」确认勾选「Add python.exe to Path」装到 C:\Python39 这种纯英文路径即可别用默认的用户目录。2.3 源码目录与安装前缀的路径规划Qt 编译对路径有两个硬性要求全英文、无空格。源码目录和最终的安装目录都不能含中文或空格否则生成脚本里的路径拼接容易出错尤其是 WebEngine 这类模块路径带空格会导致工具链解析失败报错信息还很不直观。我习惯把源码放在 C:\qt\src安装前缀设在 C:\qt\5.15.16-msvc2019。两个目录分开有实际好处configure 的 -prefix 参数指定最终安装位置源码目录保持独立意味着参数调整或重编时删除源码目录不影响已安装版本反过来安装目录坏了也能重新走 install 步骤恢复不用重新编译。磁盘空间也要提前打算。完整编译整包、同时产出 debug 和 release 两套二进制临时文件和最终产物的总量会明显超过直觉。我一般预留 30GB 以上并且把 TMP、TEMP 环境变量指到空间最充裕的盘符set TMPD:\tmp set TEMPD:\tmp这么做是因为 configure 和编译过程会在临时目录里堆积大量中间文件。C 盘一旦写满报错往往不是在写文件的那一刻而是在后续的链接阶段表现为各种「无法解析的外部符号」很误导人。提前把临时目录改到大分区等于给编译上了一道保险。设置完成后在同一个命令行窗口里执行 echo %TEMP% 确认路径已生效再开始 configure。3. 配置与编译configure参数取舍与并行构建实测环境就绪就进入正题。configure.bat 决定编译哪些模块、按什么方式编译、装到哪里参数选得合理后面就是长时间等待参数选得不对编译到一半返工是常有的事。所以 configure 这步值得多花十分钟研究。3.1 configure最小命令与8个常用开关Qt 5.15 在 Windows 上通过 configure.bat 脚本进行配置。切换到源码根目录执行 configure.bat -help 能看到全部参数但几百个参数现场看会晕。实际编译我通常从下面这个最小命令开始cd C:\qt\src\qt-everywhere-src-5.15.16 configure.bat -prefix C:\qt\5.15.16-msvc2019 ^ -opensource -confirm-license ^ -debug-and-release ^ -nomake examples -nomake tests ^ -skip qtwebengine -skip qt3d -mp提示源码目录名以你实际解压结果为准不同发布批次可能略有差异。逻辑说明-prefix 指定安装目录编译完成后所有头文件、库和插件都会拷到这里-opensource 和 -confirm-license 组合表示接受开源许可跳过交互确认-debug-and-release 同时产出调试版和发布版调试版文件名带 d 后缀用于断点跟踪发布版用于最终交付-nomake examples -nomake tests 跳过示例和测试程序能省下不少构建时间-skip 后面跟模块名用于剔除不需要的模块-mp 让 MSVC 开启多进程编译。参数说明里最值得花时间的是 -skip。qtwebengine 编译量极大、对外部环境最敏感业务里不需要内嵌浏览器的话第一次编译务必先跳过。qt3d 依赖 OpenGL 相关组件项目没有 3D 需求也建议跳过。如果机器上同时装了多个 VS 版本configure 可能探测到 vs2022 或 vs2017 的工具链这时加一个 -platform win32-msvc 显式锁定平台并确保当前打开的是 vs2019 的开发者命令行。之后如果想把 WebEngine 补回来不需要从头全量编译。重新运行 configure 时去掉 -skip qtwebengine其他参数保持不变然后进入 qtwebengine 子目录单独执行 jom 即可。这样能避免一上来就被 WebEngine 拖住整个流程。3.2 jom与nmake并行编译的取舍configure 成功之后终端会提示你执行 nmake。nmake 是 vs2019 自带的构建工具单进程执行时全量编译的等待时间会非常长。另一个选择是 jomQt 官方为 Windows 提供的并行构建工具本质是对 nmake 的兼容替代。把 jom.exe 放到任意 PATH 目录比如 C:\qt\tools然后在源码根目录执行jom jom installjom 会自动检测 CPU 核数并并行调度不需要手动传线程数。8 核以上的机器体感差别非常明显。第一次全量编译建议用 jom后续单独编某个模块也统一用它习惯保持一致能少踩不少坑。个别情况下第三方模块生成的 Makefile 对语法要求更严格jom 可能解析不过去。此时换回 nmake 单进程编译该模块即可不要死磕。这属于正常现象不是工具本身有问题。jom 的并行度也不是越大越好。内存小于 16GB 的机器上并行线程过多会频繁发生页面交换编译速度反而下降。确有此情况时给 jom 加 -j 4 这类手动限制参数比默认全核跑更稳。3.3 编译产物检查从lib到dll的目录结构编译结束后jom install 会把产物统一拷贝到 -prefix 指定的目录。先看目录结构再跑任何验证程序能挡住大半问题。常见布局bin 放动态库和可执行文件lib 放导入库include 放头文件plugins 放插件mkspecs 放 qmake 的配置数据。dir C:\qt\5.15.16-msvc2019\bin\Qt5Core.dll dir C:\qt\5.15.16-msvc2019\lib\Qt5Core.lib dir C:\qt\5.15.16-msvc2019\include\QtCore逐个模块确认需要的 dll 都在比直接跑一个 hello world 更可靠。因为某些模块即使编译失败configure 也可能不报错而是生成一个空的导入库糊弄过去。另外用 qmake 自检一下安装前缀C:\qt\5.15.16-msvc2019\bin\qmake.exe -query QT_INSTALL_PREFIX输出的路径应该就是 -prefix 指定的目录。如果输出的是源码目录而不是安装目录说明 install 阶段没有成功拷贝需要检查 install 时使用的命令行窗口权限或杀毒软件拦截。bin 目录下 dll 是否带 d 后缀是快速判断 debug/release 是否同时产出的标志。只编 release 时看到的都是 Qt5Core.dlldebug 和 release 都编了才会同时出现 Qt5Core.dll 与 Qt5Cored.dll。4. 编译避坑5个高频报错的排查路径编译 Qt 时的报错信息往往又长又绕表象五花八门但高频问题其实集中在少数几个根因上。下面按「现象 → 原因 → 解决」列五条都是实际编译中反复遇到的。4.1 configure阶段提示找不到Perl现象configure 跑到中途报 Perl not found或者提示 perl 不是内部或外部命令配置流程直接中断。原因Perl 没有安装或安装时没有加入 PATH。Qt 的构建流程在 configure 阶段就会调用 Perl 生成本地化文件缺了它不会自动跳过而是直接中断。解决到 Perl 官网下载 Windows 版安装包安装时勾选添加到 PATH。装完重开开发者命令行先执行 where perl 确认能找到再重新跑 configure.bat。注意 PATH 修改不会即时生效必须重新打开命令行窗口。4.2 WebEngine模块编译中途失败或耗时过长现象编译 qtwebengine 子目录时进度条卡住一两个小时或出现 ninja: error: missing and unknown target 后停止。原因WebEngine 内部使用 Chromium 的构建体系对工具链和内存要求都很高Python 缺失、目录权限不足、临时空间不够都会在中途失败报错反而不直接。解决第一次全量编译时用 -skip qtwebengine 跳过等核心库稳定集成后再单独补编。补编前确保 Python 可执行、临时目录空间充足。如果业务完全不需要内嵌网页建议永久跳过省下的时间足够再编一轮完整 Qt。4.3 源码路径含中文空格导致乱码现象configure 顺利通过但编译到某个模块时报错无法打开包含文件路径中出现乱码或生成的文件名带问号。原因源码目录或安装前缀含中文、空格字符。Qt 的部分生成脚本不做路径转义遇到非 ASCII 字符时就拼接出错误路径。解决把源码解压到纯英文路径比如 C:\qt\src\qt-everywhere-src-5.15.16。已经踩进去的话删掉旧目录重新解压不要尝试在原位置改名绕过因为大量相对路径已经写在生成的 Makefile 里改名会产生新的不一致。4.4 磁盘被临时文件吃满的隐性信号现象编译到一半出现各种 undefined reference或链接器报错提示磁盘空间不足但检查 C 盘剩余空间还有几个 GB。原因configure 使用的临时目录由 TEMP 环境变量决定。如果 TEMP 指向 C 盘而 C 盘空间不足中间文件写不进去最终报错却常常表现为「无法解析的外部符号」和代码本身毫无关系。解决编译前把 TMP、TEMP 指向大分区盘符并在 configure 之前执行 echo %TEMP% 确认生效。这条规则同样适用于 jom它的缓存目录也受 TEMP 影响。4.5 杀毒软件静默隔离生成的exe/dll现象jom install 正常执行完但 bin 目录下部分 dll 不存在或 Qt5Core.dll 在但程序运行时提示找不到动态库。原因杀毒软件实时防护把编译过程中生成的未签名 exe/dll 当作可疑文件隔离了。Windows 自带的安全中心有时也会对 MSVC 输出误报。解决把源码目录、安装前缀、临时目录加入杀毒软件排除列表。已经发生隔离就先去隔离区恢复文件再重跑 jom install 重新拷贝。最稳妥的方案是编译期间临时关闭实时防护编译完再打开。前提是你确认源码来自官方渠道安全性有保障。5. 集成验证把编译好的QT挂进vs2019工程编译只是第一步让 vs2019 真正认得出、跑得来才算闭环。这一章把验证路径串起来建议按顺序走一遍别跳过。5.1 在Qt VS Tools里配置编译器前缀vs2019 里安装好「Qt Visual Studio Tools」扩展后菜单栏会出现 Qt VS Tools。进入 Qt VS Tools → Qt Versions新增一条配置Version 名称填 5.15.16-msvc2019Path 指向安装前缀 C:\qt\5.15.16-msvc2019。扩展会自动读取 qmake.exe 的版本信息能正确显示版本号说明目录结构没问题。这里有个细节扩展读取的是 mkspecs 目录的信息如果 configure 时用了自定义 -platform扩展可能识别不到。此时直接看 C:\qt\5.15.16-msvc2019\mkspecs\qconfig.pri 里的配置即可不必重编。注意 vs2019 里装 Qt VS Tools 扩展时选与当前 VS 匹配的版本不要装最新的跨 VS 版本否则扩展可能找不到 v142 工具集。扩展装完需要重启 vs2019 才能生效。5.2 用CMake独立工程验证编译与运行扩展配置好之后最直接的验证是建一个最小 CMake 工程不依赖扩展直接用编译好的 Qt 库。这样能确认编译产物本身自洽排除扩展配置的干扰。工程放两个文件cmake_minimum_required(VERSION 3.16) project(helloqt LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_PREFIX_PATH C:/qt/5.15.16-msvc2019) find_package(Qt5 COMPONENTS Core Widgets REQUIRED) add_executable(helloqt main.cpp) target_link_libraries(helloqt Qt5::Core Qt5::Widgets)main.cpp 内容#include QApplication #include QLabel int main(int argc, char** argv) { QApplication app(argc, argv); QLabel label(Qt 5.15.16 compiled with vs2019); label.show(); return app.exec(); }在开发者命令行里执行构建cmake -S . -B build -G Visual Studio 16 2019 -A x64 cmake --build build --config Release逻辑说明CMAKE_PREFIX_PATH 让 find_package 能定位到 Qt5 的 CMake 配置目录路径里的斜杠方向按 CMake 习惯写-G 指定生成 vs2019 工程-A x64 指定 64 位目标。能成功编译出窗口说明 Qt5Core、Qt5Widgets 模块可用。构建时注意一个点这里只验证了 Release 模式。如果 configure 阶段只编译了 debug 库而这里用 --config Release 构建链接会失败提示无法打开 Qt5Core.lib。应对方式是让构建配置和编译库的模式保持一致或者在 CMake 工程里直接看 CMAKE_BUILD_TYPE 的值。用 CMake 工程验证的好处是零扩展依赖能真实反映 Qt 库本身状态若这一步通过基本可以认定编译产物可用。5.3 排查运行时找不到dll的三种常见情况编译链接都通过运行时却弹窗提示缺少 Qt5Core.dll新手最容易在这里懵。原因基本有三种PATH 环境变量没包含 bin 目录、dll 没有拷贝到可执行文件旁、debug/release 库混用。最省事的方式是用 windeployqt 自动部署依赖C:\qt\5.15.16-msvc2019\bin\windeployqt.exe build\Release\helloqt.exe这个工具会把依赖的 dll、插件、qml 模块都拷到 exe 旁边。拷贝完仍然报缺 dll用 dumpbin 查看 exe 的导入表确认它依赖的是哪个版本dumpbin /dependents build\Release\helloqt.exe输出里会列出 Qt5Core.dll 还是 Qt5Cored.dll。如果 exe 依赖的是 Qt5Cored.dll 而 release 目录里拷进来的是 Qt5Core.dll就是 debug/release 混用。把带 d 后缀的 dll 连同一套插件目录整体拷贝过去问题就解决了。另一个容易被忽略的情况是 plugins 目录缺失。Qt 的 qwindows.dll 平台插件不在 bin 而在 plugins\platforms 下windeployqt 会自动处理手动部署时很容易漏掉。遇到跑起来黑窗口或者窗口闪退先检查 plugins 目录里有没有 platforms而不是去翻代码。6. 二次编译提速按需裁剪与增量构建的小技巧编译过一次之后重编时你会想把等待时间压下来。以下三个技巧是我反复验证过、最值得落地的。第一用 -skip 按需裁剪模块。qtwebengine、qtmultimedia、qtlocation 这类重型模块业务用不到就从 configure 参数里移掉。裁剪列表控制在小幅范围内因为 Qt 模块之间存在交叉依赖裁过头反而要在运行时缺模块回头再补更费劲。第二只保留 release 版本。大多数逻辑问题可以靠日志和断言定位真正需要断点跟踪时再单独编一次 debug 构建。这个取舍能把一次全量编译的时间压掉近一半configure.bat -prefix C:\qt\5.15.16-msvc2019 ^ -release -opensource -confirm-license ^ -nomake examples -nomake tests ^ -skip qtwebengine -mp第三增量构建时只编改动过的模块。全量失败后不需要重新跑 configure回到源码根目录对具体模块执行 jomcd C:\qt\src\qt-everywhere-src-5.15.16 jom module-qtbase这个命令只编译 qtbase 模块及其依赖跳过其他模块速度能快一个量级。代价是模块间头文件版本不一致时可能漏编所以每次补完模块后我会回到第 5 章的 CMake 工程做一遍干净验证再投入业务。这个流程里我最看重的是第一次花二十分钟把环境固定下来后面每次重编都只是重复劳动不再折腾环境。后来换别的 Qt 版本我也沿用同一套目录和环境配置基本没再翻过车。希望帮到你。本文还有配套的精品资源点击获取