简介针对Windows 10MSVC2019环境这份Qt 5.15.15静态编译资源包面向需要免安装分发的桌面开发者可直接链接静态运行时与OpenSSL省去自行配置编译链的繁琐环节。包内共2000个头文件压缩后约672.83MB覆盖Qt Core、GUI、OpenGL等核心模块的公开接口配合静态库即可完成项目构建整体采用标准Qt安装目录布局include、lib、plugins、bin等分区明确便于快速定位所需组件。考虑到静态编译往往伴随可执行文件体积增大和编译时间延长该资源已提前完成整套编译开发者无需再为环境配置与等待耗时。目前已有687人学习浏览适合离线或受限环境中部署Qt应用也适合希望规避运行时依赖问题、简化软件分发的团队使用。借助这份完整产物使用者既能获得开箱即用的静态编译环境也能对照头文件梳理Qt模块的调用关系提升桌面端开发与维护效率。1. 静态编译 Qt 5.15.15把分发时的 DLL 麻烦一次焊死你大概率见过这种现场程序在开发机上跑得好好的拷到客户的 win10 机器上双击后系统弹窗“由于找不到 Qt5Core.dll无法继续执行代码”。问题不在你的代码而在你的 Qt 是动态构建。所谓静态编译 Qt 5.15.15win10 MSVC2019 OpenSSL 静态运行时就是把 Qt 库、OpenSSL 和 VC 运行时全部编进你的 exe让目标机器既不用装 VC 运行库也不用跟着程序带一堆 DLL。说“焊死”一点不夸张——交付物就一个文件拷到哪都能跑。这套方案适合做工具类软件、工业上位机以及所有“客户不会装环境”的分发场景。你需要的是一台装有 Visual Studio 2019 的 Windows 10以及足够的磁盘空间和耐心。2. 环境准备Win10 下的 MSVC2019 工具链与 OpenSSL 静态库2.1 源码、OpenSSL 与磁盘规划先定三条目录铁律拿到 Qt 5.15.15 源码包之后第一件事不是解压而是先把目录规划好。我第一次做静态构建时图省事把源码直接解压到了D:\我的代码\qt 5.15.15这种带中文和空格的路径里configure 跑到一半开始报各种找不到文件的错浪费了一整个下午。静态构建对路径的容忍度比动态构建低得多因为 configure 会生成大量绝对路径写入 .pro 文件和 Makefile路径里有空格时后续 jom 解析依赖规则会直接翻车。我一般会按照三条铁律来准备目录源码目录、OpenSSL 源码目录、最终安装目录三者分开且都不能有中文、空格和特殊符号。我的习惯是D:\Qt\5.15.15-src、D:\thirdparty\openssl-src、D:\Qt\5.15.15-static。源码包下载后先校验哈希再解压。Qt 官方 archive 页面每个压缩包都带 sha256你可以在 PowerShell 里用Get-FileHash核对。这一步很多人跳过但静态构建动辄两小时起步编到一半发现源码包损坏心态直接崩。磁盘空间按 50GB 以上预留。静态构建的中间产物比动态构建大得多特别是 Qt 的 qmake 会为每个模块生成完整的临时文件加上 OpenSSL 的编译输出30GB 是起步价。我还见过同事把源码放在 OneDrive 同步目录里编到一半文件被云同步锁定jom 随机报错最后查了两天才定位到是同步工具的锅。另外提醒一句如果你打算用国内镜像下载源码包尽量选与 5.15.15 版本完全对应的 tag。网上很多旧教程指向的是 5.15.2 的包编出来的库在接第三方代码时会出现路径或 ABI 层面的怪问题后面第 5 章我会专门讲这个坑。2.2 用 vcvars64.bat 固定 MSVC2019 工具链很多新手分不清 msvc 和 mingw 的区别一句话解释MinGW 是 GCC 的 Windows 移植版编出来的程序不依赖 MSVC 运行库但遇到 OpenSSL 官方静态库、Halcon 这类商业 SDK 时人家默认只给 MSVC 版你拿 MinGW 去链大概率对不上 ABI。所以标题里写了 MSVC2019我们就老老实实走 MSVC 工具链。关键一步是在 configure 之前把 MSVC 环境变量加载进来。Visual Studio 2019 安装时提供了vcvars64.bat它会把 cl.exe、nmake.exe、link.exe 以及各种系统库的 include/lib 路径注入当前终端。我不推荐直接在 Qt Creator 或 Visual Studio 里跑 configure那些环境经常混入其他版本的 PATH最常见的现象就是你明明装的是 2019结果 cl 版本显示 2022。call C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat cl执行后应该看到Microsoft (R) C/C Optimizing Compiler Version 19.2x字样19.2x 对应 2019 工具集 v142。如果你装的是 Professional 或 Enterprise把路径里的 Community 对应替换即可。如果你刚重装完 win10 和 VS2019记得在 Visual Studio Installer 里勾选“使用 C 的桌面开发”工作负载否则 vcvars64.bat 都不存在。这里有个容易忽略的细节后续所有编译步骤包括 OpenSSL 的 nmake、Qt 的 configure、jom都必须在同一个已加载 vcvars64.bat 的终端里执行。换个新终端就要重新 call 一次。我见过有人把这一步写进了一个env.bat每次编译前先跑一遍省得反复记路径。2.3 Perl、Python 与 jomconfigure 前必须就位的三件小工具Qt 的 configure 脚本在 Windows 上依赖 PerlOpenSSL 的构建同样依赖 PerlQt 构建系统还需要 Python 来处理部分代码生成任务而 jom 是 Qt 官方提供的并行版 nmake用它能把多核 CPU 用起来否则 nmake 单线程编 Qt 静态库时间直接翻倍。Perl 我建议装 Strawberry Perl装完把C:\Strawberry\perl\bin加入 PATH。安装 ActivePerl 也可以但新版 ActivePerl 对个人用户收紧授权没必要在这上面折腾。Python 装 3.8 到 3.10 之间的版本就行装完同样确认能全局访问。perl -v python --version jom -versionjom 不一定要单独安装。如果你机器上装过 Qt 官方安装包在 Qt 安装目录的Tools\QtCreator\bin下一般就有jom.exe直接把这个目录加入 PATH 即可。安装完之后做一次“环境自检”在一个新终端里先后执行 vcvars64.bat然后依次跑 perl、python、jom 三个命令确认全部能输出版本信息。这一步花不了两分钟但能帮你把后面 configure 阶段“找不到 perl”这类低级错误提前排掉。2.4 OpenSSL 的版本选型与静态库编译标题里的 openssl 是本方案的重头戏。Qt 接入 OpenSSL 有两条路-openssl-runtime是程序运行时动态加载libssl和libcrypto的 DLL-openssl-linked是直接把 OpenSSL 静态库链进 Qt 库再链进你的 exe。既然我们要的是“静态运行时”走-openssl-linked是唯一的干净选择。OpenSSL 的版本选择建议与 Qt 官方测试过的版本对齐。Qt 5.15.x 时代对应的是 OpenSSL 1.1.1 系列网上大量教程用的也是 1.1.1w。如果你手头只有 OpenSSL 3.x也能编但后面接第三方库时版本宏冲突的概率会高不少第 4 章我会写一个真实的报错案例。这里以 1.1.1w 为例源码解压后先编静态库cd /d D:\thirdparty\openssl-src perl Configure VC-WIN64A no-asm no-shared --prefixD:\thirdparty\openssl-static nmake nmake install三个关键参数逐个说明。VC-WIN64A告诉 OpenSSL 用 MSVC 的 64 位工具链no-asm禁用汇编优化能避开不少汇编器版本不匹配的坑代价是加解密性能有少量下降但对绝大多数桌面程序无感no-shared是关键中的关键它让 OpenSSL 只生成静态库不产出 DLL否则 configure 阶段即使你指定-openssl-linked链接时也可能悄悄把 DLL 的导入库给链进去最后分发时还是得带两个 DLL。nmake 编 OpenSSL 的输出会生成在源码目录的lib下而nmake install会把头文件和库统一复制到--prefix指定的目录。这一步做完之后D:\thirdparty\openssl-static\include里是头文件lib里是静态库。留意一下实际生成的库文件名1.1.1 系列在 MSVC 静态构建下一般会带_static后缀比如libssl_static.lib。这个文件名后面配置 Qt 时要直接用到。3. configure 静态方案把 -static、-openssl-linked 与 /MT 一次性定死3.1 configure 参数表这一行命令定了静态方案的骨架环境备齐后进入 Qt 5.15.15 源码根目录执行 configure。下面这行命令是我在多次构建中沉淀下来的“可复现配置”它决定了整个静态方案的骨架cd /d D:\Qt\5.15.15-src configure.bat -platform win32-msvc2019 -static -release -openssl-linked ^ -opensource -confirm-license -prefix D:\Qt\5.15.15-static ^ -mp -nomake examples -nomake tests -no-icu -no-pch ^ -skip qtwebengine -skip qtwebview -skip qtsensors -skip qtserialbus逐个说明关键参数参数作用我的建议-static让 Qt 自身以静态库方式构建输出 .lib 而非 .dll必选-release只构建 Release 版静态 Debug 库体积大且调试意义有限生产交付选它-openssl-linked将 OpenSSL 静态链接进 Qt 网络模块本方案核心-platform win32-msvc2019指定 MSVC2019 工具集与 vcvars64 对应-prefix安装输出目录改成你自己的路径-mp启用多进程编译强烈建议-nomake examples/tests不编译示例和测试能省两小时以上-no-icu关闭 ICU 依赖不需要复杂文本处理就关掉-no-pch关闭预编译头减少静态构建中的诡异编译错误-skip qtwebengine跳过 WebEngine 模块必选见下方说明关于-skip qtwebengine多说一句。Qt WebEngine 基于 ChromiumChromium 本身不支持静态链接configure 时如果保留它编到一半大概率爆出几十个 link 错误而且在静态 Qt 里即使编过了exe 体积也会膨胀到匪夷所思的程度。做桌面工具用不到浏览器内核直接 skip 是业界共识。-skip qtwebview同理它是 WebEngine 的封装。-no-pch是很多人忽略的一个参数。MSVC 的预编译头在静态构建多模块场景下经常触发“fatal error C1010”这类文件级问题关掉它虽然会多编几分钟但能换来源码级的心平气和。3.2 把 mkspec 里的 -MD 改成 -MT静态运行时真正的开关这里必须单独拿出一节来讲因为它是标题里“静态运行时”五个字真正落地的地方也是网上 80% 教程都没讲透的地方。MSVC 编译 C/C 时/MD表示动态链接 CRT即链接到 VCRUNTIME140.dll/MT表示静态链接 CRT把运行时库直接编进目标文件。Qt 的 mkspec 文件默认给的是/MD如果你不修改就算 Qt 库全是 .lib你的最终 exe 仍然会在客户机上弹“缺少 VCRUNTIME140.dll”。这就像你焊死了大门结果发现窗户还开着。在 configure 之前用文本编辑器打开D:\Qt\5.15.15-src\qtbase\mkspecs\win32-msvc2019\qmake.conf找到以下几行并修改QMAKE_CFLAGS_RELEASE -O2 -MT QMAKE_CFLAGS_DEBUG -Zi -MTd QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO -O2 -Zi -MT注意三处都要改Release 用-MTDebug 用-MTdReleaseWithDebugInfo 用-MT。只改第一行是不彻底的因为 Qt 某些辅助工具会以 Debug 配置编译它们链 CRT 的方式如果和最终库不一致后面你的程序链接时就会报LNK2038 mismatch detected for RuntimeLibrary那也是一场血泪排查。改完保存然后再执行 configure。这个顺序不能反——configure 会把 mkspec 里的默认编译选项固化进生成的 qmake 和 Makefile 里事后改不生效。3.3 让 configure 找到 OpenSSL环境变量与常见失误configure 阶段最容易静默失败的就是 OpenSSL。Qt 的 configure 如果找不到 OpenSSL并不会直接报错中断而是悄悄把网络模块的 SSL 支持降级成“无 SSL”状态。等你程序里调用 QSslSocket 时才发现 QTLS 不可用再回头重编 Qt几个小时就没了。在运行 configure.bat 之前的同一个终端里先设置两个环境变量明确告诉 Qt 我们的 OpenSSL 静态库在哪里set OPENSSL_LIBSD:\thirdparty\openssl-static\lib\libssl_static.lib D:\thirdparty\openssl-static\lib\libcrypto_static.lib set OPENSSL_INCDIRD:\thirdparty\openssl-static\includeOPENSSL_INCDIR指向 OpenSSL 安装后的 include 目录configure 编译链接测试程序时从这里找头文件。OPENSSL_LIBS直接指定链接阶段要用的两个静态库的完整路径和文件名。注意文件名一实际生成产物为准如果你编的 OpenSSL 输出是libssl.lib和libcrypto.lib就改成那个名字。两个库必须来自同一次构建绝对不能一个用 1.1.1w 的一个用 3.x 的这会引出第 4 章的版本错配报错。配置完成后执行 configure等它跑完在输出里搜索“OpenSSL”。正常情况下能看到类似OpenSSL: yes (linked)的提示有些版本显示为Using OpenSSL: yes。如果显示的是OpenSSL: no不要急着往下走先回头检查OPENSSL_LIBS的文件路径是否存在、文件名是否写对。这一步是整条链路里最容易出问题的位置花五分钟确认能省后面两小时的返工。4. 编译与安装jom 并行构建与 OpenSSL 版本错配的排查4.1 用 jom 并行编译并安装命令、时间与进度判断configure 顺利完成之后源码根目录下会生成 Makefile 和qmake.conf。此时不要直接敲 nmake单线程编 Qt 静态库在我的机器上要六个小时起步。先确认 jom 可用然后以并行方式编译set PATHD:\thirdparty\jom;%PATH% jom -j8 jom install-j8是并行任务数一般取 CPU 物理核数。i5-8400 六核机器用-j6或-j8都可以内存 16GB 以下不建议超过 8否则会因内存不足触发编译进程被杀。jom 的好处是它自带依赖关系调度能正确处理 Qt 这种多模块之间的编译顺序你可以把它理解成“可并行的 nmake”。关于进度判断我有一条血泪经验不要一直盯着编译输出看Qt 构建动辄输出几十万行日志屏幕刷得飞快你什么也看不出来。正确做法是偶尔按一下 CtrlC 边上的 Pause 键让输出暂停然后拖到滚动条最底部看当前在编哪个目录。如果长时间卡在同一个 .cpp 文件上不动多半是出了问题这时候按 CtrlC 中断重跑时加上-k参数让 jom 跳过出错目标收集完整错误列表。整个 release 静态构建的时间按我个人经验i5 六核 16GB 内存的机器在跳过 WebEngine 和 examples 的前提下大约两到四小时。编完后执行jom installQt 会按--prefix指定的路径安装最终在D:\Qt\5.15.15-static\bin下出现 qmake.exe。看到这个文件说明 Qt 静态库本体已经构建成功。安装完成后做个快速验证set PATHD:\Qt\5.15.15-static\bin;%PATH% qmake -query QT_VERSION qmake -query QT_CONFIGQT_CONFIG的输出里应该能看到static、openssl-linked以及crt-static如果 mkspec 修改生效了会显示。如果没看到openssl-linked说明 configure 阶段 OpenSSL 还是没接上回 3.3 节查环境变量。4.2 编译期报错“openssl version mismatch built against 30000070, you have 38500000”的排查思路这个报错在我第一次做 OpenSSL 相关静态链接时出现过当时查了整整一下午。先解释一下它是什么意思OpenSSL 在编译时会把自己的版本号以十六进制宏OPENSSL_VERSION_NUMBER写进头文件比如 3.0.7 对应30000070而38500000对应的是一套更新版本的 OpenSSL 头文件。报错的意思很直白你程序里某个模块是用 OpenSSL 3.0.7 的头文件编译的但链接时的库是另一套更新版本两边版本宏对不上。这种现象的根源几乎都是“混用了不同来源的 OpenSSL 产物”。典型场景是你用D:\thirdparty\openssl-static编了 Qt 静态库但程序里还链了一个第三方 SDK它内部自带了一份 OpenSSL 3.8 的静态库。链接器碰巧先吃了第三方 SDK 的库又碰了 Qt 里那份 3.0.7 的库于是运行时版本检查直接炸掉。排查步骤我建议按这个顺序来在链接命令行里打印所有 OpenSSL 相关 .lib 的完整路径确认是否出现了两个不同的 OpenSSL 安装目录。检查第三方 SDK 的 lib 目录下是否带了libssl和libcrypto。如果确实混用了二选一要么把整个项目所有 OpenSSL 相关依赖统一替换成你编 Qt 用的那一套要么给你的程序静态库降级选项统一用最新版 OpenSSL 重编 Qt。这里还有个常见误区有人看到 version mismatch 就觉得是 OpenSSL 没编好回头把 Qt 源码全清了重编。结果当然还是报同样的错因为问题根本不在 Qt 的构建产物而在你的最终链接阶段。记住Qt 静态库只是一个中间环节真正做最终链接的是你程序的 nmake 或 CMake 链接命令。4.3 编到一半莫名失败杀软、磁盘与残留路径的排查清单静态编译过程中“编到一半突然失败”是最让人崩溃的因为报错往往毫无规律。我在三台不同机器上踩过同样的坑按出现概率排个序第一是杀毒软件实时扫描。Windows Defender 对大量新生成的 .obj 文件做实时扫描时会和 jom 产生文件锁竞争导致随机性的fatal error C1083: Cannot open compiler intermediate file。解决方案很简单把源码目录和安装目录都加入 Defender 的排除列表。具体路径是「病毒和威胁防护 → 排除项 → 添加文件夹」。这一步能消除 70% 的随机失败。第二是磁盘空间耗尽。静态构建的中间 .obj 文件总和巨大特别是 Qt3D 这类模块编到一半磁盘红了编译器连临时文件都写不出来。我习惯在构建开始前用wmic logicaldisk get size,freespace看一眼剩余空间少于 20GB 就赶紧清理。第三是残留的 Makefile 和 .qmake.stash。如果你第一次 configure 失败或者中途换过编译参数源码目录里会留下旧的 Makefile 和.qmake.stash缓存文件。第二次 configure 时会读取这些缓存导致新参数没生效。解决方法是彻底清理git clean -xdf如果你拿到的源码包没有 .git 目录就手动删除源码根目录下的 Makefile、.qmake.stash以及所有模块目录下残留的 Makefile 和 debug/release 子目录。宁可在清理上多花十分钟也别带着旧缓存硬编否则你会收获一堆“玄学编译失败”。5. 链接静态 Qt 的高频坑与排查清单从闪退到路径污染5.1 qwindows 插件没导入双击闪退典型的“qt崩溃”现场现象程序编译链接全部成功双击 exe闪一下就没了。在命令行里运行输出qt.qpa.plugin: Could not find the Qt platform plugin windows。原因动态 Qt 里平台插件是platforms\qwindows.dll程序启动时从 plugins 目录加载。静态 Qt 下没有 DLL 可分发了qwindows 插件已经被编进 Qt 库但它不会被自动激活需要你在自己的 main 函数所在文件里显式导入。解决在 main.cpp 顶部加上#include QtPlugin Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin)同时在 .pro 文件里显式声明需要链接的插件QTPLUGIN qwindows如果你还用了图片格式插件或数据库驱动插件类似地需要Q_IMPORT_PLUGIN(QJpegPlugin)、Q_IMPORT_PLUGIN(QSqliteDriverPlugin)等。这个坑的隐蔽性在于不是所有插件缺失都会闪退比如 JPEG 插件缺失时程序照样启动但QPixmap::load悄悄返回 false图片全显示不出来且不报任何错误。排查这类问题时我建议把常用插件一次性全部导入省得后续一个个踩。5.2 工具集错配LNK2038 与 msvc2019/2022 混用现象链接时报错LNK2038: mismatch detected for _MSC_VER: value 1928 doesnt match value 1936或者程序能链接成功但一运行就崩溃。原因1928 对应 MSVC2019v1421936 对应 MSVC2022v143。两个工具集编译出来的 C 对象文件其内部名称修饰和标准库布局有差异混链要么直接拒绝要么产出运行即崩的畸形 exe。这种混用最常见于机器上装了 VS2019 和 VS2022你编译 Qt 时用的是 2019 的 vcvars64但编译自己程序时从 VS2022 的开发终端执行了 qmake/nmake。解决开发机环境复杂时把“编译 Qt”和“编译自己的程序”分开写两个脚本每个脚本第一行都强制 call 对应版本的 vcvars64.bat。这样即使你终端开错了脚本也会自动切回 2019 环境。更稳妥的做法是彻底卸载 VS2022只保留 2019环境干净了这类问题就绝迹了。5.3 OpenSSL 版本宏对不上30000070 vs 38500000 的运行时报错现象程序启动或首次发起 HTTPS 请求时崩溃输出openssl version mismatch built against 30000070, you have 38500000。原因这个报错我在 4.2 节详细讲过在运行时出现的本质是Qt 的 QSslSocket 通过静态链接接入了 OpenSSL 3.0.7而你程序里还链了一个第三方库带的 OpenSSL 3.8.x两者在同一个进程空间共存OpenSSL 的运行时全局状态被两套代码同时操作版本检查直接终止进程。解决优先排查第三方依赖。用 dumpbin 查看最终 exe 的依赖和链接的静态库列表确认 OpenSSL 相关符号是否来自你配置的那个 lib。如果确实来自第三方 SDK最干净的做法是放弃那个 SDK 自带的老版本 OpenSSL改用你编 Qt 用的同一套。如果你用的是动态版本的第三方库DLL则要注意静态 OpenSSL 和动态 OpenSSL 不能同时存在于一个进程要么全静态要么全动态混用必炸。5.4 dependent qtwidgets_global.h 不存在路径污染与 .qmake.stash现象编译你自己的 Qt 程序时报错:-1: error: dependent ..\..\..\..\..\..\qt\5.15.2\msvc2019_64\include\qtwidgets\qtwidgets_global.h does not exist原因这个报错指向的路径里带5.15.2和msvc2019_64说明你的构建目录里残留着旧 Qt 环境的缓存。最常见的场景是你之前用 Qt 官方安装包的 5.15.2 动态版本编译过同一个项目后来切换到自编的 5.15.15 静态版本但 qmake 生成 Makefile 时读取了.qmake.stash里缓存的旧路径把INCPATH指向了旧 Qt 的 include 子目录。而那个子目录在官方预编译包里根本不存在头文件其实是平铺在 include 根目录下的于是依赖检查直接失败。解决删除项目构建目录下的所有 Makefile、.qmake.stash、.qmake.cache以及 debug/release 子目录。然后重新执行 qmakeqmake yourproject.pro nmake clean nmake如果还不行换个全新的构建目录重新 qmake。这个报错的根源就是“qmake 缓存污染”和你的代码本身没关系。我在这个坑上浪费过一整天后来养成了一个习惯任何一次切换 Qt 环境后都要先qmake -query QT_VERSION确认当前 qmake 指向的路径再开始编译。5.5 静态运行时没生效VCRUNTIME140.dll 仍挂在依赖里现象程序在开发机上运行正常拷到一台干净的 win10 虚拟机弹出“缺少 VCRUNTIME140.dll”。用 Dependencies 工具查看 exe发现依赖列表里不仅有VCRUNTIME140.dll还有MSVCP140.dll。原因你在第 3.2 节已经把 Qt 的 mkspec 改成了-MT但你自己程序的编译仍然用的默认/MD。也就是说Qt 静态库部分是静态 CRT而你的 exe 部分编译时仍然链接了动态 CRT两者混链的结果是 VCRUNTIME140.dll 依然被引进来。解决在你自己的 .pro 文件里追加编译选项QMAKE_CFLAGS_RELEASE -MT QMAKE_CXXFLAGS_RELEASE -MT QMAKE_LFLAGS_RELEASE /NODEFAULTLIB:MSVCRT其中/NODEFAULTLIB:MSVCRT是为了防止链接器把动态 CRT 的默认库悄悄加回去。改完重新 qmake、clean、重新编译。判断是否生效最快的方法编译完成后打开 exe 的依赖列表只要看不到 VCRUNTIME140.dll 和 MSVCP140.dll就说明静态运行时彻底生效了。这一步做到位你的 exe 才真正达到“拷到任何 win10 都能跑”的交付标准。6. 验证与进阶dumpbin 查依赖、体积控制与 SSL 证书兜底构建完成后验证是最后一道关。我常用的手段是 VS 自带的 dumpbin 工具。打开 2019 的开发者命令行执行dumpbin /dependents release\your_app.exe重点看输出里的 DLL 列表。一个彻底静态化的 Qt 程序除了KERNEL32.dll、USER32.dll、GDI32.dll这些系统基础 DLL 之外不应该再出现任何 Qt5 开头的 DLL、libssl、libcrypto、VCRUNTIME140.dll或MSVCP140.dll。如果 Qt5Core.dll 赫然在列说明你编译自己的程序时 qmake 没有指向自编的静态 Qt回到 5.4 节查路径缓存。体积方面静态 Qt 程序通常 20MB 到 50MB取决于你导入了多少模块。想进一步瘦身可以在 configure 阶段加上-optimize-size让编译器偏向体积优化同时确保链接器开启/OPT:REF和/OPT:ICF这两个选项在 Release 下默认是打开的用于剔除未引用函数和合并相同代码段。我不建议用 UPX 压缩压缩后 exe 确实能小一半以上但杀毒软件对此类壳的误报率极高拿到客户机器上被拦截反而更麻烦。还有一个 SSL 相关的细节容易忽略静态 Qt 不会自动附带 CA 证书库。你的程序如果要用 QNetworkAccessManager 访问 HTTPS 接口默认会因为找不到根证书而报证书错误。我一般会在资源文件里打包一份cacert.pem程序启动时把它写入临时文件或直接加载到内存然后调用QSslSocket::setDefaultCaCertificates。证书文件可以用 OpenSSL 项目维护的cacert.pem定期更新即可。最后说一句我自己的教训我第一次完整走通这套静态构建时兴致勃勃地直接把 exe 拷给同事结果他在一台没装过任何运行库的机器上一跑就报缺 VCRUNTIME140.dll。我当时的反应是“怎么可能”回开发机查了半天发现确实没改 mkspecQt 库虽然是静态的但 CRT 还是动态的。那次之后我固定在构建完的“第一件事”就是 dumpbin 看依赖确认没有任何第三方 DLL 残留然后再开始打包。这套流程已经成了我做 Windows 桌面交付的肌肉记忆。希望帮到你。本文还有配套的精品资源点击获取