第一次在 Windows 上装好 MinGW写了个经典的printf(hello)然后gcc hello.c -o hello.exe一敲回车生成的 exe 居然好几十 KB双击能跑人也麻了——我明明只写了三行代码编译器到底往里塞了什么这是很多新手接触 gcc 后很快就会碰到的问题C 文件的 exe 太大了怎么才能变小。这个问题看起来简单但背后的门道不少。体积问题不只是“加一个 -O2 就完事”它牵扯到链接方式、运行库、符号表、甚至编译器的发行版选择。这篇文章我就从实际踩坑的角度把 exe 体积从“几十 KB”一路压到“几 KB”的完整思路和方法讲清楚包括每一步的原理、命令、实测效果以及那些新手最容易踩的坑。适合刚开始在 Windows 上用 gcc 编译 C 语言的朋友也适合写小工具想分发给别人、却不想让压缩包太难看的老手。1. 先别急着压缩弄清楚体积是从哪来的很多人第一步就喜欢到处找编译器参数但如果不理解 exe 里到底装了什么压缩很容易变成瞎试。我先帮你把体积来源看清楚。1.1 你写的只有几行链接器却打包了一车“运营物资”你的 C 源码经过编译先生成目标文件.o这个文件本身非常小可能只有几百字节。但 exe 不是直接把目标文件拼起来而是要把你的代码和 C 运行库C Runtime链接在一起。问题就出在这里。一个最简单的printf底层牵扯到标准输入输出库的实现、格式化字符串解析、控制台窗口的初始化、程序启动代码入口函数到 main 之间的那层胶水等等。MinGW 在默认情况下为了让你生成的 exe 在别人的电脑上也能直接跑会把涉及到的库函数实现“静态链接”进 exe——也就是说把这些功能对应的机器码原原本本地复制了一份到你的 exe 里面。这就好比你在网上点了一份蛋炒饭平台为了保证你拿到手能吃直接把整个厨房设备连带锅碗瓢盆全塞进了外卖盒。你的“程序本体”反而只占了很小一部分剩下的全是运行框架和库函数。所以一个纯逻辑的 hello world 动不动就几十 KB是正常现象不是坏了。1.2 三个最常见的“体积刺客”搞清楚默认链接已经带了“厨房”之后再看具体是什么在占体积。根据我自己的经验把 exe 撑胖的因素主要有三个第一个是调试信息。如果你在 IDEA、VSCode 的 task 配置里用了-g参数编译器会把源文件路径、行号、变量符号等调试信息全部写进 exe。这个膨胀效果非常明显一个原本 40KB 的程序加了-g可能直接翻倍甚至更大。VSCode 的 C/C 插件很多生成的默认 task 命令里就带-g很多新手没注意就莫名其妙多出来了体积。第二个是线程模型和异常处理库。MinGW-w64 在官网下载时会让你选 posix 还是 win32 线程模型。posix 版本为了兼容 pthread 接口会引入一个叫 winpthread 的库哪怕你的代码完全没用多线程链接阶段也可能把相关代码带进去。这就是为什么有些人编译出来的 hello world 体积比别人大而且还会看见依赖libwinpthread-1.dll之类的文件。异常处理模型seh、sjlj、dwarf在 C 里影响更大纯 C 相对小一些但如果是 posix 版本分分钟多出十几 KB 不意外。第三个是标准输入输出函数的“全家桶效应”。C 语言的printf、scanf这些函数看着简单背后是一整套格式化引擎包括浮点数转换、字符串处理、缓冲区管理。只要你用了其中一个这部分代码就可能被链进来。这也是为什么有时候你把printf换成 Win32 API 的MessageBox之后exe 体积会肉眼可见地掉一大截——不是 API 神奇而是你不再需要背那么重的格式化引擎了。2. 基础瘦身三板斧编译链接参数立竿见影先别急着上黑科技最简单的三个参数组合就能帮你压掉不少体积。这一步不需要换编译器、不需要碰代码改一下编译命令就行。2.1 用 -Os 告诉编译器“我们为体积服务”gcc 的优化选项不少-O0是不优化-O1是基础优化-O2是常规优化-O3是激进优化还有一个很容易被忽略的-Os意思是“在优化时不牺牲代码体积尽量生成更小的目标代码”。-O2和-O3为了性能有时候会把循环展开、内联短函数、复制一些公共代码块这些都是以膨胀体积为代价的。-Os会把这些对体积不友好的优化关掉优先让代码更紧凑。对于大多数命令行工具、脚本性质的小工具-Os带来的性能损失几乎没有体感差异但体积上能看出区别。不过这里要给你泼一盆冷水如果程序本身就是十几行代码-Os的作用可能只有几 KB甚至不明显。因为刚才说了大头在 C 运行库不在你的逻辑代码。所以-Os是基础但别指望它是唯一解。gcc -Os hello.c -o hello.exe2.2 strip 一下把符号“脱干净”符号表说白了就是一份“函数名、变量名、地址”的映射表。平时调试程序、崩溃的时候看堆栈都需要符号表但发布版本根本不需要把它留在 exe 里。MinGW 自带一个叫strip的工具可以把符号表和调试段从可执行文件里删掉立竿见影。strip 有两种用法一种是用strip命令处理已经编译出的 exe另一种是直接在 gcc 链接时加-s参数效果一样strip hello.exe gcc -s -Os hello.c -o hello.exe一个 40KB 左右、没有加-g的 exestrip 之后可能掉到 10KB 附近。如果之前带着-g那掉得更多。strip 之后程序体积降了功能完全不受影响真要用就一把梭发布时基本都会带这个参数。注意strip 之后的 exe 不能再拿来 gdb 调试崩溃日志里也不会再有文件名和行号。所以我自己的习惯是开发阶段的调试版本不加 strip做发布构建时才 strip两边参数分开。2.3 死代码消除组合拳 -ffunction-sections -fdata-sections --gc-sections这一步是很多老手推荐的一招。它解决的问题是链接器静态链接库的时候不知道你具体用了哪些函数经常会把一整个 .o 文件里的代码都塞进来。-ffunction-sections和-fdata-sections让编译器把每个函数、每个全局数据单独放到一个 section段里然后配合-Wl,--gc-sections让链接器扫描一遍把没被引用到的 section 直接丢弃。这个组合对单文件的小程序作用有限但在项目里有多个源文件、或者链接了静态库时效果非常明显。比如一个程序引用了某个库里的三个函数但那个库的一个目标文件里塞了二十个函数没有--gc-sections之前可能全部被带进来有了这个组合就只保留你真正调用的部分。完整命令是这样gcc -Os -s -ffunction-sections -fdata-sections hello.c -o hello.exe -Wl,--gc-sections我自己的实测数据一个用 MinGW-w64win32 线程模型静态链接默认运行库编译的 hello world编译方式大概体积gcc hello.c -o hello.exe约 40KBgcc -Os hello.c -o hello.exe约 36KBgcc -Os -s hello.c -o hello.exe约 12KB再加上-ffunction-sections -fdata-sections -Wl,--gc-sections约 10KB看到没有strip 带来的收益往往比前面几个都大这招一定要学会。不同版本的 gcc、不同的 MinGW 发行版具体数字会有浮动但趋势是一致的。3. 换一种链接方式体积直接下一个台阶参数调完之后如果你还嫌大那就要动“链接方式”的脑筋了。这是整个瘦身过程里最立竿见影的一步也是很多新手完全没有意识到的地方。3.1 让程序借用 Windows 系统自带的 msvcrt.dll前面说的 MinGW 默认把 C 运行库静态链接进 exe所以体积大。但如果改成“动态链接”也就是让 exe 在运行时去调用系统目录里已有的 DLL那体积就能一下子掉到几 KB。Windows 系统从很老的版本开始就内置了一个叫msvcrt.dll的 C 运行库提供printf、malloc、memcpy这一大堆标准函数。如果你的 exe 在运行时去调用这个 DLL而不是把它们编译进 exe 里那代码体积当然小得多。问题在于你用的 MinGW-w64 默认多数情况下是静态链接 C 运行库的所以即使你写出花来那个底子依然有几 KB 到十几 KB 的库代码在里面。这时候最简单的办法是换一个更倾向“动态链接”的 gcc 发行版。业内常用的是 TDM-GCC。它的特点之一就是默认链接到系统的msvcrt.dll生成的 exe 天生很小。同样的 hello world用 TDM-GCC 编译-Os -s一条龙下来有时候能压到 2KB 到 4KB非常夸张。动态链接之后你写的是什么exe 里就基本是什么干干净净。gcc -Os -s hello.c -o hello.exe需要说明TDM-GCC 的版本相较于 MinGW-w64 会旧一些但对学 C 语言、做命令行小工具、写 Windows API 程序来说完全够用。如果你平时只是编译 C 语言作业、写点小工具这个方案省心又省体积。3.2 动态链接的兼容性边界看到这里你可能兴奋了那我全都换动态链接不就好了别急动态链接也有自己的代价。msvcrt.dll确实从 Windows 98 到 Windows 11 几乎都存在这是它最大的优势。但如果你用了比较新的 UCRTUniversal C Runtime那就另当别论了Win10 及以上系统原生支持但 Win7 上可能需要打补丁才能跑。还有一个更常见的问题动态链接出来的 exe如果依赖某个特定版本的 DLL而目标机器上没有就会在启动时弹窗报“缺少 DLL”错误非常尴尬。所以逻辑很清楚只在自己机器上跑或者不打算大范围分发直接用动态链接体积最小。要做成绿色软件发给一群不特定的人静态链接更稳缺点是体积大但不会在别人电脑上出现“缺DLL”事故。想要体积小又想兼容性稳那就先用动态链接把体积降下来最后再用 UPX 压缩一层当成妥协方案。3.3 更硬核的玩法没有标准库也能跑如果你的程序只是调用 Windows API不依赖 C 标准库的printf、scanf、memcpy这类函数那可以用-nostdlib把标准启动代码和运行库全部踢掉连 CRT Startup 都不要。这里放一个最小示例弹一个消息框就退出#include windows.h void entry(void) { MessageBoxA(0, Hello, Hi, 0); ExitProcess(0); }编译命令gcc -Os -s -nostdlib -Wl,--entryentry -mwindows tiny.c -o tiny.exe -lkernel32 -luser32这个方案生成的 exe 体积可以压到 1KB 到 2KB放在 FAT32 的 U 盘上都看不出占用空间。但注意代价是你失去了整个 C 标准库printf、malloc、字符串函数全部不可用程序入口也不是标准main整个开发方式基本回到“裸写”状态。这个玩法主要用来做极低体积的实验工具或者真正要塞进极小镜像里的场景。如果你刚接触这些不建议一上来就用容易把自己绕进去。我先给你留个印象等你把常规手段都熟悉了再回来试这个东西会轻松很多。4. 终极方案UPX 一压了之前面所有方法都是在“编译链接”阶段缩减体积。如果你已经做到动态链接、strip、该死代码的也消除了还是不满足那就只剩一招对最终 exe 做“壳压缩”。最常见的工就是 UPX。4.1 UPX 怎么用压缩效果能到多少UPX 的原理简单说就是把你 exe 里的代码和数据压缩一遍再塞一个解压器进去。程序运行时先在内存里自解压然后再执行主程序。它对体积的压缩效果非常可观通常能压到原来的 40% 甚至更低。如果前面已经用动态链接把体积压到几 KB再 UPX 压一下几乎就是几百字节到 1KB 级别完全可以放到“远古时代”的软盘里。安装 UPX 很简单Windows 上可以直接用包管理器winget install UPX # 或者 choco install upx如果你是在 Linux 上交叉编译也可以用系统包管理器装。使用方法更是傻瓜式upx --best hello.exe--best是最强压缩压缩率最高但处理时间稍长担心解压慢的话用默认upx hello.exe也行。一次压缩之后你会看到 UPX 在输出里列出压缩前后的体积对比。4.2 UPX 的三个坑误报、启动慢、签名失效UPX 不是银弹我用它的时候踩过不少坑第一条就是杀软误报。UPX 加壳后exe 的入口代码和正常编译出来的程序差异很大特征非常明显很多杀毒软件会直接把它当成“疑似病毒”处理尤其是国内环境下误报率相当感人。你辛辛苦苦压到 2KB 的程序发给别人结果对方电脑直接给隔离了那种心情我不想你再体验一遍。第二条是启动变慢。UPX 程序运行时需要先在内存里解压如果程序本身只有几 KB那这个时间差可以忽略不计但如果是一个几 MB 的大程序解压耗时会肉眼可见地增加。而且压缩壳还会增加崩溃排查的难度原本可以看堆栈定位问题加壳之后就不好搞了。第三条是数字签名问题。如果你用给 exe 签过名比如 Authenticode 签名再用 UPX 压缩会直接把签名破坏掉得先压缩再重新签名。顺序搞错的话Windows SmartScreen 弹窗警告跑都跑不掉。我的习惯是只有那种“一定要发到别人电脑上、又特别在意体积”的小工具才用 UPX。自己用的程序、要长期维护的工程、可能被安全扫描的商业项目我基本不用省心比省那几 KB 重要得多。5. 常见问题排查与避坑速查聊到这里你应该已经对 exe 为啥大、怎么变小有了完整认知。但实操中大家会遇到一些“看起来莫名其妙”的情况我列一份排查速查表帮你少走弯路。问题常见原因解决办法同样代码我编译出来就是比别人大用的是 posix 线程模型或者带了调试信息换 win32 线程模型检查编译命令里有没有-gstrip 之后还是很“大”大头是静态链接的运行库不是符号换动态链接方案比如 TDM-GCC编译出来的 exe 依赖libwinpthread-1.dllgcc 是 posix 线程模型且动态链接了 winpthread换 win32 线程模型版本或静态链接该库VSCode 编译出的 exe 比命令行编译的大task.json 默认带了-g调试参数去掉-g或用 Release 任务的参数用了-Os但没明显变小程序逻辑体量小于运行库体积用-sstrip或换动态链接方式UPX 压缩后被报毒UPX 壳特征明显放弃 UPX改用动态链接 strip程序传到别人电脑报缺 DLL动态链接了某个非系统 DLL改用静态链接或把 DLL 一起分发排查时还有个小工具很实用——用 objdump 查看 exe 到底依赖了哪些 DLLobjdump -p hello.exe | grep DLL Name这样就能一眼看出你的 exe 依赖的是msvcrt.dll、ucrtbase.dll还是乱七八糟的libwinpthread-1.dll。知道依赖了谁就知道体积和兼容性问题大概率出在哪里。如果项目是用 CMake 管理的可以把这些瘦身参数集中放到 Release 配置里省得每次手敲set(CMAKE_C_FLAGS_RELEASE -Os -s -ffunction-sections -fdata-sections) set(CMAKE_EXE_LINKER_FLAGS_RELEASE -Wl,--gc-sections)这个写法和 Makefile 里的 CFLAGS/LDFLAGS 大同小异不同工具链也都能套用。核心思路就一个平时开发保留调试信息发布构建统一加-Os -s和死代码消除。6. 我现在的固定套路最后分享一个我日常真实在用的构建方案你可以直接抄。如果你只是自己练手或写点内部脚本级别的工具我基本用这条命令gcc -Os -s hello.c -o hello.exe简单、够用、体积不会离谱几分钟就能出结果。如果是做一个要发给同事、发给朋友的小工具我会先用动态链接的编译器比如 TDM-GCC 或已经确认是动态的运行环境编译再用 strip 一下必要时 UPX 压一遍。编译脚本会写成类似这样CC gcc CFLAGS -Os -s -ffunction-sections -fdata-sections LDFLAGS -Wl,--gc-sections SRC hello.c hello.exe: $(SRC) $(CC) $(CFLAGS) $(SRC) -o $ $(LDFLAGS) clean: rm -f hello.exe如果是商业项目我的优先级会反过来稳定性第一、体积第二。静态链接保兼容-Os -s尽量减重但绝不上 UPX 压缩壳防止杀软误报给客户带来困扰。从 40KB 到 2KB靠的不是某个神仙参数而是“减少链接内容、去除无效信息、压缩最终产物”这一套组合拳。我个人在实际操作中最大的体会是先弄清楚一遍 exe 的组成比盲目试各种“压缩神器”有用得多。等你下次再看到“为什么我的 gcc 编译出来 exe 这么大”的提问你心里就该很清楚——这根本不是什么 bug而是你的程序和整个运行环境之间的一次坦诚相见我们只需要告诉编译器哪些东西这次用不上可以不带。 Windows 下 gcc 编译的 exe 太大？从 40KB 到 2KB 的完整瘦身指南
第一次在 Windows 上装好 MinGW写了个经典的printf(hello)然后gcc hello.c -o hello.exe一敲回车生成的 exe 居然好几十 KB双击能跑人也麻了——我明明只写了三行代码编译器到底往里塞了什么这是很多新手接触 gcc 后很快就会碰到的问题C 文件的 exe 太大了怎么才能变小。这个问题看起来简单但背后的门道不少。体积问题不只是“加一个 -O2 就完事”它牵扯到链接方式、运行库、符号表、甚至编译器的发行版选择。这篇文章我就从实际踩坑的角度把 exe 体积从“几十 KB”一路压到“几 KB”的完整思路和方法讲清楚包括每一步的原理、命令、实测效果以及那些新手最容易踩的坑。适合刚开始在 Windows 上用 gcc 编译 C 语言的朋友也适合写小工具想分发给别人、却不想让压缩包太难看的老手。1. 先别急着压缩弄清楚体积是从哪来的很多人第一步就喜欢到处找编译器参数但如果不理解 exe 里到底装了什么压缩很容易变成瞎试。我先帮你把体积来源看清楚。1.1 你写的只有几行链接器却打包了一车“运营物资”你的 C 源码经过编译先生成目标文件.o这个文件本身非常小可能只有几百字节。但 exe 不是直接把目标文件拼起来而是要把你的代码和 C 运行库C Runtime链接在一起。问题就出在这里。一个最简单的printf底层牵扯到标准输入输出库的实现、格式化字符串解析、控制台窗口的初始化、程序启动代码入口函数到 main 之间的那层胶水等等。MinGW 在默认情况下为了让你生成的 exe 在别人的电脑上也能直接跑会把涉及到的库函数实现“静态链接”进 exe——也就是说把这些功能对应的机器码原原本本地复制了一份到你的 exe 里面。这就好比你在网上点了一份蛋炒饭平台为了保证你拿到手能吃直接把整个厨房设备连带锅碗瓢盆全塞进了外卖盒。你的“程序本体”反而只占了很小一部分剩下的全是运行框架和库函数。所以一个纯逻辑的 hello world 动不动就几十 KB是正常现象不是坏了。1.2 三个最常见的“体积刺客”搞清楚默认链接已经带了“厨房”之后再看具体是什么在占体积。根据我自己的经验把 exe 撑胖的因素主要有三个第一个是调试信息。如果你在 IDEA、VSCode 的 task 配置里用了-g参数编译器会把源文件路径、行号、变量符号等调试信息全部写进 exe。这个膨胀效果非常明显一个原本 40KB 的程序加了-g可能直接翻倍甚至更大。VSCode 的 C/C 插件很多生成的默认 task 命令里就带-g很多新手没注意就莫名其妙多出来了体积。第二个是线程模型和异常处理库。MinGW-w64 在官网下载时会让你选 posix 还是 win32 线程模型。posix 版本为了兼容 pthread 接口会引入一个叫 winpthread 的库哪怕你的代码完全没用多线程链接阶段也可能把相关代码带进去。这就是为什么有些人编译出来的 hello world 体积比别人大而且还会看见依赖libwinpthread-1.dll之类的文件。异常处理模型seh、sjlj、dwarf在 C 里影响更大纯 C 相对小一些但如果是 posix 版本分分钟多出十几 KB 不意外。第三个是标准输入输出函数的“全家桶效应”。C 语言的printf、scanf这些函数看着简单背后是一整套格式化引擎包括浮点数转换、字符串处理、缓冲区管理。只要你用了其中一个这部分代码就可能被链进来。这也是为什么有时候你把printf换成 Win32 API 的MessageBox之后exe 体积会肉眼可见地掉一大截——不是 API 神奇而是你不再需要背那么重的格式化引擎了。2. 基础瘦身三板斧编译链接参数立竿见影先别急着上黑科技最简单的三个参数组合就能帮你压掉不少体积。这一步不需要换编译器、不需要碰代码改一下编译命令就行。2.1 用 -Os 告诉编译器“我们为体积服务”gcc 的优化选项不少-O0是不优化-O1是基础优化-O2是常规优化-O3是激进优化还有一个很容易被忽略的-Os意思是“在优化时不牺牲代码体积尽量生成更小的目标代码”。-O2和-O3为了性能有时候会把循环展开、内联短函数、复制一些公共代码块这些都是以膨胀体积为代价的。-Os会把这些对体积不友好的优化关掉优先让代码更紧凑。对于大多数命令行工具、脚本性质的小工具-Os带来的性能损失几乎没有体感差异但体积上能看出区别。不过这里要给你泼一盆冷水如果程序本身就是十几行代码-Os的作用可能只有几 KB甚至不明显。因为刚才说了大头在 C 运行库不在你的逻辑代码。所以-Os是基础但别指望它是唯一解。gcc -Os hello.c -o hello.exe2.2 strip 一下把符号“脱干净”符号表说白了就是一份“函数名、变量名、地址”的映射表。平时调试程序、崩溃的时候看堆栈都需要符号表但发布版本根本不需要把它留在 exe 里。MinGW 自带一个叫strip的工具可以把符号表和调试段从可执行文件里删掉立竿见影。strip 有两种用法一种是用strip命令处理已经编译出的 exe另一种是直接在 gcc 链接时加-s参数效果一样strip hello.exe gcc -s -Os hello.c -o hello.exe一个 40KB 左右、没有加-g的 exestrip 之后可能掉到 10KB 附近。如果之前带着-g那掉得更多。strip 之后程序体积降了功能完全不受影响真要用就一把梭发布时基本都会带这个参数。注意strip 之后的 exe 不能再拿来 gdb 调试崩溃日志里也不会再有文件名和行号。所以我自己的习惯是开发阶段的调试版本不加 strip做发布构建时才 strip两边参数分开。2.3 死代码消除组合拳 -ffunction-sections -fdata-sections --gc-sections这一步是很多老手推荐的一招。它解决的问题是链接器静态链接库的时候不知道你具体用了哪些函数经常会把一整个 .o 文件里的代码都塞进来。-ffunction-sections和-fdata-sections让编译器把每个函数、每个全局数据单独放到一个 section段里然后配合-Wl,--gc-sections让链接器扫描一遍把没被引用到的 section 直接丢弃。这个组合对单文件的小程序作用有限但在项目里有多个源文件、或者链接了静态库时效果非常明显。比如一个程序引用了某个库里的三个函数但那个库的一个目标文件里塞了二十个函数没有--gc-sections之前可能全部被带进来有了这个组合就只保留你真正调用的部分。完整命令是这样gcc -Os -s -ffunction-sections -fdata-sections hello.c -o hello.exe -Wl,--gc-sections我自己的实测数据一个用 MinGW-w64win32 线程模型静态链接默认运行库编译的 hello world编译方式大概体积gcc hello.c -o hello.exe约 40KBgcc -Os hello.c -o hello.exe约 36KBgcc -Os -s hello.c -o hello.exe约 12KB再加上-ffunction-sections -fdata-sections -Wl,--gc-sections约 10KB看到没有strip 带来的收益往往比前面几个都大这招一定要学会。不同版本的 gcc、不同的 MinGW 发行版具体数字会有浮动但趋势是一致的。3. 换一种链接方式体积直接下一个台阶参数调完之后如果你还嫌大那就要动“链接方式”的脑筋了。这是整个瘦身过程里最立竿见影的一步也是很多新手完全没有意识到的地方。3.1 让程序借用 Windows 系统自带的 msvcrt.dll前面说的 MinGW 默认把 C 运行库静态链接进 exe所以体积大。但如果改成“动态链接”也就是让 exe 在运行时去调用系统目录里已有的 DLL那体积就能一下子掉到几 KB。Windows 系统从很老的版本开始就内置了一个叫msvcrt.dll的 C 运行库提供printf、malloc、memcpy这一大堆标准函数。如果你的 exe 在运行时去调用这个 DLL而不是把它们编译进 exe 里那代码体积当然小得多。问题在于你用的 MinGW-w64 默认多数情况下是静态链接 C 运行库的所以即使你写出花来那个底子依然有几 KB 到十几 KB 的库代码在里面。这时候最简单的办法是换一个更倾向“动态链接”的 gcc 发行版。业内常用的是 TDM-GCC。它的特点之一就是默认链接到系统的msvcrt.dll生成的 exe 天生很小。同样的 hello world用 TDM-GCC 编译-Os -s一条龙下来有时候能压到 2KB 到 4KB非常夸张。动态链接之后你写的是什么exe 里就基本是什么干干净净。gcc -Os -s hello.c -o hello.exe需要说明TDM-GCC 的版本相较于 MinGW-w64 会旧一些但对学 C 语言、做命令行小工具、写 Windows API 程序来说完全够用。如果你平时只是编译 C 语言作业、写点小工具这个方案省心又省体积。3.2 动态链接的兼容性边界看到这里你可能兴奋了那我全都换动态链接不就好了别急动态链接也有自己的代价。msvcrt.dll确实从 Windows 98 到 Windows 11 几乎都存在这是它最大的优势。但如果你用了比较新的 UCRTUniversal C Runtime那就另当别论了Win10 及以上系统原生支持但 Win7 上可能需要打补丁才能跑。还有一个更常见的问题动态链接出来的 exe如果依赖某个特定版本的 DLL而目标机器上没有就会在启动时弹窗报“缺少 DLL”错误非常尴尬。所以逻辑很清楚只在自己机器上跑或者不打算大范围分发直接用动态链接体积最小。要做成绿色软件发给一群不特定的人静态链接更稳缺点是体积大但不会在别人电脑上出现“缺DLL”事故。想要体积小又想兼容性稳那就先用动态链接把体积降下来最后再用 UPX 压缩一层当成妥协方案。3.3 更硬核的玩法没有标准库也能跑如果你的程序只是调用 Windows API不依赖 C 标准库的printf、scanf、memcpy这类函数那可以用-nostdlib把标准启动代码和运行库全部踢掉连 CRT Startup 都不要。这里放一个最小示例弹一个消息框就退出#include windows.h void entry(void) { MessageBoxA(0, Hello, Hi, 0); ExitProcess(0); }编译命令gcc -Os -s -nostdlib -Wl,--entryentry -mwindows tiny.c -o tiny.exe -lkernel32 -luser32这个方案生成的 exe 体积可以压到 1KB 到 2KB放在 FAT32 的 U 盘上都看不出占用空间。但注意代价是你失去了整个 C 标准库printf、malloc、字符串函数全部不可用程序入口也不是标准main整个开发方式基本回到“裸写”状态。这个玩法主要用来做极低体积的实验工具或者真正要塞进极小镜像里的场景。如果你刚接触这些不建议一上来就用容易把自己绕进去。我先给你留个印象等你把常规手段都熟悉了再回来试这个东西会轻松很多。4. 终极方案UPX 一压了之前面所有方法都是在“编译链接”阶段缩减体积。如果你已经做到动态链接、strip、该死代码的也消除了还是不满足那就只剩一招对最终 exe 做“壳压缩”。最常见的工就是 UPX。4.1 UPX 怎么用压缩效果能到多少UPX 的原理简单说就是把你 exe 里的代码和数据压缩一遍再塞一个解压器进去。程序运行时先在内存里自解压然后再执行主程序。它对体积的压缩效果非常可观通常能压到原来的 40% 甚至更低。如果前面已经用动态链接把体积压到几 KB再 UPX 压一下几乎就是几百字节到 1KB 级别完全可以放到“远古时代”的软盘里。安装 UPX 很简单Windows 上可以直接用包管理器winget install UPX # 或者 choco install upx如果你是在 Linux 上交叉编译也可以用系统包管理器装。使用方法更是傻瓜式upx --best hello.exe--best是最强压缩压缩率最高但处理时间稍长担心解压慢的话用默认upx hello.exe也行。一次压缩之后你会看到 UPX 在输出里列出压缩前后的体积对比。4.2 UPX 的三个坑误报、启动慢、签名失效UPX 不是银弹我用它的时候踩过不少坑第一条就是杀软误报。UPX 加壳后exe 的入口代码和正常编译出来的程序差异很大特征非常明显很多杀毒软件会直接把它当成“疑似病毒”处理尤其是国内环境下误报率相当感人。你辛辛苦苦压到 2KB 的程序发给别人结果对方电脑直接给隔离了那种心情我不想你再体验一遍。第二条是启动变慢。UPX 程序运行时需要先在内存里解压如果程序本身只有几 KB那这个时间差可以忽略不计但如果是一个几 MB 的大程序解压耗时会肉眼可见地增加。而且压缩壳还会增加崩溃排查的难度原本可以看堆栈定位问题加壳之后就不好搞了。第三条是数字签名问题。如果你用给 exe 签过名比如 Authenticode 签名再用 UPX 压缩会直接把签名破坏掉得先压缩再重新签名。顺序搞错的话Windows SmartScreen 弹窗警告跑都跑不掉。我的习惯是只有那种“一定要发到别人电脑上、又特别在意体积”的小工具才用 UPX。自己用的程序、要长期维护的工程、可能被安全扫描的商业项目我基本不用省心比省那几 KB 重要得多。5. 常见问题排查与避坑速查聊到这里你应该已经对 exe 为啥大、怎么变小有了完整认知。但实操中大家会遇到一些“看起来莫名其妙”的情况我列一份排查速查表帮你少走弯路。问题常见原因解决办法同样代码我编译出来就是比别人大用的是 posix 线程模型或者带了调试信息换 win32 线程模型检查编译命令里有没有-gstrip 之后还是很“大”大头是静态链接的运行库不是符号换动态链接方案比如 TDM-GCC编译出来的 exe 依赖libwinpthread-1.dllgcc 是 posix 线程模型且动态链接了 winpthread换 win32 线程模型版本或静态链接该库VSCode 编译出的 exe 比命令行编译的大task.json 默认带了-g调试参数去掉-g或用 Release 任务的参数用了-Os但没明显变小程序逻辑体量小于运行库体积用-sstrip或换动态链接方式UPX 压缩后被报毒UPX 壳特征明显放弃 UPX改用动态链接 strip程序传到别人电脑报缺 DLL动态链接了某个非系统 DLL改用静态链接或把 DLL 一起分发排查时还有个小工具很实用——用 objdump 查看 exe 到底依赖了哪些 DLLobjdump -p hello.exe | grep DLL Name这样就能一眼看出你的 exe 依赖的是msvcrt.dll、ucrtbase.dll还是乱七八糟的libwinpthread-1.dll。知道依赖了谁就知道体积和兼容性问题大概率出在哪里。如果项目是用 CMake 管理的可以把这些瘦身参数集中放到 Release 配置里省得每次手敲set(CMAKE_C_FLAGS_RELEASE -Os -s -ffunction-sections -fdata-sections) set(CMAKE_EXE_LINKER_FLAGS_RELEASE -Wl,--gc-sections)这个写法和 Makefile 里的 CFLAGS/LDFLAGS 大同小异不同工具链也都能套用。核心思路就一个平时开发保留调试信息发布构建统一加-Os -s和死代码消除。6. 我现在的固定套路最后分享一个我日常真实在用的构建方案你可以直接抄。如果你只是自己练手或写点内部脚本级别的工具我基本用这条命令gcc -Os -s hello.c -o hello.exe简单、够用、体积不会离谱几分钟就能出结果。如果是做一个要发给同事、发给朋友的小工具我会先用动态链接的编译器比如 TDM-GCC 或已经确认是动态的运行环境编译再用 strip 一下必要时 UPX 压一遍。编译脚本会写成类似这样CC gcc CFLAGS -Os -s -ffunction-sections -fdata-sections LDFLAGS -Wl,--gc-sections SRC hello.c hello.exe: $(SRC) $(CC) $(CFLAGS) $(SRC) -o $ $(LDFLAGS) clean: rm -f hello.exe如果是商业项目我的优先级会反过来稳定性第一、体积第二。静态链接保兼容-Os -s尽量减重但绝不上 UPX 压缩壳防止杀软误报给客户带来困扰。从 40KB 到 2KB靠的不是某个神仙参数而是“减少链接内容、去除无效信息、压缩最终产物”这一套组合拳。我个人在实际操作中最大的体会是先弄清楚一遍 exe 的组成比盲目试各种“压缩神器”有用得多。等你下次再看到“为什么我的 gcc 编译出来 exe 这么大”的提问你心里就该很清楚——这根本不是什么 bug而是你的程序和整个运行环境之间的一次坦诚相见我们只需要告诉编译器哪些东西这次用不上可以不带。