简介：这份面向 C/C++ 初学者及具备基础 Eclipse 操作经验开发者的开发文档，聚焦 Windows 平台下借助 Eclipse、CDT 与 MinGW 搭建可用的 C 语言开发环境，重点解决编译器缺失、环境变量设置、CDT 参数不匹配以及首个工程难以跑通等入门障碍。压缩包内共 1 个 docx 文件，大小约 903KB，以图文结合的配置说明为主体，便于离线查阅与按主题检索。目前已有 2217 人学习，反映出该配置主题在入门阶段仍有较高关注度。文档围绕 Eclipse、CDT 与 MinGW 的协同使用展开，内容覆盖软件准备、安装配置、环境变量调整、CDT 参数设置、工程创建、编译运行及调试思路，并对常见配置错误给出针对性提示，能够帮助读者理解各组件之间的依赖关系，建立从环境搭建到工程成功运行的完整认知，适合课程实验、个人自学、机房环境部署及教学备课参考。

1. 为什么还在用 Eclipse 写 C：一份能照着敲的环境文档

接手别人留下的老工程时，最耗时间的往往不是读代码，而是把编译链在一台干净机器上重新拉起来。手上这份Eclipse 搭建 C 语言开发环境的开发文档，解决的正是这件事：它把 Eclipse 本体、CDT 插件、MinGW 编译器三者的下载、解压、环境变量、CDT 参数和首个工程的创建串成一条线，按顺序走完就能得到一个能自动编译、能在控制台看到输出的 C/C++ 工作区。它适合两类人：一类是机器上本来只拿 Eclipse 写 Java、想顺手把 C 也接进去的人；另一类是在没有大型构建系统的条件下维护一批单文件或小规模 C 程序的人。文档基于 Eclipse SDK + CDT 与 MinGW 的组合写成，Windows 路径分隔符、PE 解析器、make 命令替换这些细节都落在具体操作上，而不是泛泛而谈。

2. 三件套的选型逻辑：Eclipse、CDT、MinGW 谁管什么

很多人第一次配这套环境失败，不是因为手笨，而是没分清三个部件各自的职责边界，出问题时不知道往哪一层查。Eclipse 是壳，CDT 是壳里那套 C/C++ 业务逻辑，MinGW 才是真正把.c变成.exe的人。这三者任何一层没接上，表现都是「点了构建没反应」或者「构建成功但跑不起来」，症状相似、病因完全不同。

2.1 Eclipse 本体与 CDT 插件的关系

Eclipse 的本质是一个插件平台加一个工作台（Workbench）。它自己不认识printf，也不认识#include，所有跟 C/C++ 有关的能力都由 CDT（C/C++ Development Tools）提供。CDT 往里塞的东西大致分五块：项目类型（Managed Make 工程和 Makefile 工程）、带语法高亮和索引的编辑器、构建器（Build）、错误解析器（Error Parser）、调试器前端（对 GDB 的封装）。

关键认知在这里：CDT 只负责「组织构建」，它把源文件列表、头文件搜索路径、编译选项翻译成一条条命令行，然后交给外部程序去执行。真正调用cc1、as、ld的是 MinGW 里的 gcc。所以会出现一种很典型的现象——Eclipse 里 C/C++ 菜单齐全，新建工程也正常，一构建就报找不到编译器。这时候去折腾 CDT 的设置是白费力气，问题在系统 Path 上。

还有一层容易被忽略：CDT 版本必须和 Eclipse 主版本配套。文档里给的方案是从 Eclipse SDK 官网下载页拿主程序，再到 CDT 下载页拿与之匹配的版本。版本错配的典型表现是 Eclipse 启动直接弹出一屏红字，说某个org.eclipse.cdt.*插件依赖无法解析，然后工作台起不来。这时候唯一的办法是换回匹配的 CDT，而不是去改eclipse.ini里的内存参数。

2.2 MinGW 提供的到底是编译器还是运行时

MinGW 全称是 Minimalist GNU for Windows，它提供的不是单一程序，而是一整套工具链：gcc-core（C 编译器驱动）、gcc-g++（C++ 前端）、binutils（as汇编器、ld链接器、ar打包工具等）、mingw32-make（构建工具）、mingw-runtime与w32api（Windows 平台的头文件和导入库）。

一条.c走到.exe的链路是这样的：gcc 驱动读命令行 →cc1做预处理和编译生成汇编 →as汇编成目标文件 →ld按顺序链接运行时库和系统导入库 → 输出 PE 格式的可执行文件。任何一环缺件都会在链接阶段炸出来，最常见的报错是undefined reference to 'xxx'，看着像代码写错，实际是库没链上或者库的顺序不对。

MinGW 和另一类 POSIX 模拟环境的最大区别在于：它生成的是原生 Windows 程序，不依赖中间层 DLL 去做系统调用翻译，跑起来跟用 MSVC 编出来的东西在系统层面没差别。这也是文档选它作为 CDT 后端的原因——CDT 的错误解析器对 gcc 风格的输出最熟，而 MinGW 输出的就是标准 gcc 格式。

至于LIBRARY_PATH、C_INCLUDE_PATH、CPLUS_INCLUDE_PATH这几个变量，职责是给编译器指路：去哪找.a/.lib库文件、去哪找 C 头文件、去哪找 C++ 标准库头文件。严格说，gcc 装在标准位置时会自动去自己安装目录下的include和lib里找，这几个变量更多是给「机器上有多套工具链」或者「装在非标准路径」的场景兜底。文档把它们都列出来，属于把边界情况一次性配齐的思路。

2.3 两条下载路线：SDK+CDT 与打包版 IDE

文档给了两条路线，选哪条取决于你机器上是否已经有 Eclipse。

路线 A 的操作要点是「合并」而不是「替换」。Eclipse SDK 解压到C:\下会得到一个eclipse文件夹，CDT 解压出来同样是一个叫eclipse的文件夹，里面有plugins和features。解压时选择合并覆盖，让 CDT 的插件文件落进同一个plugins目录；如果手滑选成整目录替换，原来的 Eclipse 主程序就被覆盖没了，启动直接失败。

路线 B 简单得多，压缩包解开就能用，里面已经含了配套的 CDT。缺点是你没法控制 CDT 的具体版本，遇到需要特定 CDT 行为的场景就只能换包。

无论走哪条路线，都有一个前置条件：机器上得有可用的 JDK，并且JAVA_HOME和Path配好。Eclipse 自己是 Java 程序，缺 JDK 的表现是双击eclipse.exe之后弹一个对话框说找不到 Java 运行时，然后退出。这一步在文档里被放在「下载准备」里，篇幅不大，但它是唯一一个「不做就完全起不来」的前置。

3. 装机与环境变量：Path、LIBRARY_PATH、C_INCLUDE_PATH 一次配对

安装这一段是整套流程里最容易留下隐患的地方，因为大部分步骤是「解压即完成」，看不出对错，真正的问题会在几天后某个新工程里突然冒出来。我的习惯是把安装拆成三步走：先定目录、再配变量、最后在命令行独立验证。第三步不能省，它是后面所有排错的分界线。

3.1 解压式安装的目录约定

Eclipse 和 CDT 都是免安装的绿色包，解压到哪就在哪运行。文档假设解压到C:\，于是得到C:\eclipse\，里面包含eclipse.exe、eclipse.ini、plugins\、features\、configuration\。这个configuration目录存的是 OSGi 框架的运行时状态，第一次启动时生成，后面如果启动异常，删掉它让 Eclipse 重建，能解决相当一部分「昨天还好好的今天打不开」的问题。

eclipse.ini是启动参数文件，控制 JVM 路径、堆大小、GC 策略。改它之前先备份，因为格式要求很死——-vm参数必须单独占一行，JVM 路径必须写在下一行，写在同一行会被忽略且不报错。

MinGW 走的是安装程序，装到C:\MinGW，装完目录下会有bin、include、lib、libexec四个关键目录。bin里是可执行文件，include里是头文件，lib里是静态库和导入库。装完之后建议先在资源管理器里点进去确认bin目录下确实有gcc.exe和mingw32-make.exe，有些精简包会缺g++，等到写 C++ 才发现就晚了。

工作区（workspace）的位置不要放在C:\eclipse下面。原因很实际：将来升级 Eclipse 时最省事的做法是删掉旧目录解压新的，工作区放在里面就一起没了。

注意：整套路径里不要出现空格和中文。C:\Program Files\这种带空格的路径会让 CDT 生成的构建命令行在引号处理上出岔子，中文路径则在错误解析和链接阶段都可能出问题，且报错信息往往指向别处。

3.2 系统变量 Path 与用户变量三件套

Path 的作用是让系统在任何目录下都能找到gcc.exe。在「系统属性 → 高级 → 环境变量」里编辑系统变量Path，在末尾追加C:\MinGW\bin;。这里有个细节文档特意强调了：如果原来的 Path 值不是以分号结尾，追加时必须在C:\MinGW\bin;前面补一个分号做分隔，否则最后两段路径会粘成一个不存在的路径。

图形界面操作容易手滑，我一般用 PowerShell 直接改，顺便规避另一个坑——setx命令在值超过 1024 个字符时会静默截断，Path 稍微长一点就会中招，而且不可逆。

# 以管理员身份运行 PowerShell $mingwBin = 'C:\MinGW\bin' $oldPath = [Environment]::GetEnvironmentVariable('Path', 'Machine') # 先判断是否已经存在，避免重复追加导致 Path 越来越长 if ($oldPath -notlike "*$mingwBin*") { # 用 .NET 方法写入，不受 setx 的 1024 字符限制 [Environment]::SetEnvironmentVariable('Path', "$oldPath;$mingwBin", 'Machine') Write-Host "已追加 $mingwBin" } else { Write-Host "Path 中已存在，跳过" }

这段脚本做了三件事：读取机器级 Path、做幂等判断、写回。'Machine'这个作用域参数对应「系统变量」，如果换成'User'就是用户变量。幂等判断看着多余，但调试期间反复执行几次就会明白它的价值——重复追加会让 Path 变成一长串重复项，排查时非常干扰视线。

接下来是三个用户变量。文档给的取值是：LIBRARY_PATH为C:\MinGW\lib，C_INCLUDE_PATH为C:\MinGW\include，CPLUS_INCLUDE_PATH为一串以分号分隔的目录。最后这个变量的值最需要注意：

# C++ 标准库头文件分布在不同层级的目录里，必须全部列出 [Environment]::SetEnvironmentVariable('LIBRARY_PATH', 'C:\MinGW\lib', 'User') [Environment]::SetEnvironmentVariable('C_INCLUDE_PATH', 'C:\MinGW\include', 'User') # 注意：c++ 后面的版本号目录（示例中的 3.2.3）随 gcc 版本变化， # 必须去 C:\MinGW\include\c++\ 下看一眼实际目录名再填 $cxxInclude = @( 'C:\MinGW\include\c++', 'C:\MinGW\include\c++\3.2.3', 'C:\MinGW\include\c++\3.2.3\mingw32', 'C:\MinGW\include\c++\3.2.3\backward', 'C:\MinGW\include' ) -join ';' [Environment]::SetEnvironmentVariable('CPLUS_INCLUDE_PATH', $cxxInclude, 'User')

CPLUS_INCLUDE_PATH里那个带版本号的目录是硬编码的，装完新版本 MinGW 之后旧值就失效了，而且不会报错，表现是某些 C++ 标准头找不到。我一般会把C:\MinGW\include\c++这一层也加进去，多一层兜底。

还有一点必须说清楚：改完环境变量，已经打开的 Eclipse 不会自动感知。Eclipse 在启动时把当时的进程环境整份继承下来，之后系统变量怎么改都跟它无关。所以改完变量的第一件事是彻底退出 Eclipse 再重新启动，不是关窗口，是确认进程真的退出了。

3.3 命令行验证工具链是否真的通了

在打开 Eclipse 之前，先用命令行把工具链单独验一遍。这一步是整个排错体系的锚点：如果命令行能编，问题就在 Eclipse 配置层；如果命令行都编不了，问题就在系统和 MinGW 本身，压根不用打开 Eclipse 浪费时间。

:: 1. 确认路径解析到的是哪一份可执行文件（机器上有多套工具链时尤其重要） where gcc where g++ where mingw32-make :: 2. 看版本和内置的搜索路径，输出里会列出 include 和 library 的实际搜索顺序 gcc -v mingw32-make -v :: 3. 确认 JDK 可用（Eclipse 自身的运行前提） java -version

where比gcc -v更值得先跑，因为它告诉你系统到底找到的是哪一个gcc.exe。机器上装过其他编译器套件的话，Path 里排在前面的会赢，这时候你配的C:\MinGW\bin就是个摆设。gcc -v的输出末尾会打印一串搜索目录，那才是编译时真正生效的路径，比对着环境变量猜测靠谱得多。

命令行能出版本号只是第一步，还要实际编一个文件。准备一个最小用例：

/* hello.c —— 只依赖标准库，用来验证工具链端到端可用 */ #include <stdio.h> int main(void) { printf("hello from mingw\n"); return 0; }

cd /d C:\work\hello :: -Wall 打开常用警告，-g 生成调试符号，这两项建议从第一个工程就带上 gcc -Wall -g hello.c -o hello.exe :: 直接运行产物，确认 exe 能起得来 hello.exe

三条命令走通、屏幕上打出hello from mingw，说明编译器、链接器、运行时库、Path 全部正常。这一步编不过的话，去看gcc -v打印的搜索路径和where gcc的结果，八成是路径没生效或者 MinGW 装漏了组件。

4. CDT 参数配置与第一个工程：从 PE Parser 到自动编译

工具链在命令行层面验证通过之后，剩下的工作都是「让 CDT 正确调用它」。这一层出问题的表现形式很固定：构建时提示找不到make、构建成功但可执行文件不被识别、运行菜单里没有本地应用选项。这三个症状对应三个不同的配置点，逐个处理就行。

4.1 Preferences 里的 Binary Parser 与 Make 命令

先解决 make。CDT 发起构建时，默认调用的命令名是make，而 MinGW 提供的构建工具叫mingw32-make.exe。名字对不上，构建直接失败，控制台里会看到类似Cannot run program "make"的提示。

文档给的解法很务实：不去改每个工程的构建命令，而是把C:\MinGW\bin\mingw32-make.exe复制一份，改名成make.exe。这样 CDT 的默认命令名不用动，所有新建工程开箱即用。

:: 复制一份并改名为 make，让 CDT 的默认命令名能找到它 copy C:\MinGW\bin\mingw32-make.exe C:\MinGW\bin\make.exe :: 验证：两个名字都应该能出版本号 make -v mingw32-make -v

这个做法的代价要说清楚：升级或重装 MinGW 时，make.exe会被覆盖掉，得重新复制一遍；而且如果机器上还有别的构建工具也提供了make.exe且排在 Path 前面，你调到的就不是这一份。所以复制完之后立刻用where make确认路径，别等到出问题再回头查。

另一条路是改工程配置：右键工程 → Properties → C/C++ Build → Builder Settings，把 Build command 从make改成mingw32-make。这条路干净，但每个新工程都要改一次，托管工程还得进.cproject里翻。两种做法各有取舍，我一般在新机器上用复制法快速起步，等项目稳定了再切回改配置的写法。

再解决 Binary Parser。CDT 构建完之后要去读产物文件，解析出里面的符号和段信息，用于错误定位、可执行文件识别、断点设置。解析器要跟产物的二进制格式匹配：Windows 下 gcc 产出的是 PE/COFF 格式，所以必须选 PE Windows Parser。

入口在 Window → Preferences → C/C++ → New CDT Project Wizard → Makefile Project → Binary Parser（不同 CDT 版本的菜单层级略有差异，认准 Binary Parser 这一项即可）。勾选PE Windows Parser，把ELF Parser等其他选项取消掉。文档明确要求「将其他选项取消选择」，原因是不取消的话 CDT 会依次尝试多个解析器，遇到不匹配的格式时在错误日志里刷一堆解析失败的信息，干扰真正的错误。

提示：这个 Preferences 只对新建工程生效。已经建好的工程要单独改：右键工程 → Properties → C/C++ Build → Settings → Binary Parsers，同样勾 PE Windows Parser。改了首选项却发现老工程还是认不出 exe，十有八九是漏了这一步。

4.2 新建托管工程与 Hello World 的目录结构

Eclipse 里所有代码都必须挂在一个 Project 下，不能对着一个孤立的.c文件直接编译。这是它的项目模型决定的，也意味着「临时写两行试试」这种场景得先建个工程。

新建入口是 File → New → C Project（或 C++ Project）。对话框里有几个关键选择：

Project type 分两类。Executable下的Hello World C Project属于托管工程（Managed Make），CDT 会根据你选的工具链自动生成 makefile，源文件增删、编译选项改动都自动反映到构建里，不用手写一行 makefile。Makefile project则要求你自己维护 makefile，CDT 只负责调用。新手直接用托管工程，省掉一整套 makefile 语法学习成本。

Toolchain 要选MinGW GCC。这一步如果没选对，后面构建时会调到一个不存在的编译器，报错信息跟 Path 没配好的表现几乎一样。

建完之后看左侧 Project Explorer，目录结构大致是这样：

hello/ ├── .project # 工程元数据：工程名、性质（nature）、构建器 ├── .cproject # 工具链配置：编译器路径、包含目录、编译选项、解析器 ├── src/ │ └── hello.c # 源码目录 └── Debug/ ├── src/ # 每个源文件对应的 .o 目标文件 ├── makefile # CDT 自动生成的构建脚本 └── hello.exe # 最终产物

.project和.cproject是两个隐藏文件，它们才是工程的真实定义。.cproject里存了工具链的绝对路径和 ID，所以把整个工程目录拷到另一台机器上经常会失效——那台机器的 MinGW 路径或者 CDT 版本对不上，就得重新配。想跨机器复用，不要拷工程目录，拷源码目录重新建工程更省事。

4.3 编译、运行与输出位置

托管工程的构建是自动触发的：只要 Project → Build Automatically 处于勾选状态，保存文件就会触发一次增量编译。构建信息输出在下方的 Console 视图里（切到 CDT Build Console 页签），编译错误会在编辑器左侧的行号旁打红叉，鼠标悬停能看到完整报错。

自动构建的好处是反馈快，坏处是文件多的时候每次保存都跑一遍，机器慢会卡。工程大起来之后我会把自动构建关掉，改成手动点锤子图标或者按 Ctrl+B。

运行的方式是右键可执行文件 → Run As → Local C/C++ Application，程序的stdout会打到 Console 视图里。这里有个容易被误判的点：如果程序是从 Run 菜单的运行配置启动的，工作目录（Working directory）默认可能是工程根目录而不是Debug目录，程序里用相对路径读文件就会读不到。运行配置的 Arguments 页签里可以显式指定工作目录和命令行参数，需要读外部文件时一定要在这里设。

产物位置也值得记一下：托管工程默认把.o、makefile、.exe全部放在Debug/下。想改成Release或者自定义目录，在 Project Properties → C/C++ Build → Builder Settings 里改 Build directory，同时记得把编译选项从调试版（带-g）换成优化版，否则发布出去的二进制会带着调试信息、体积偏大。

5. 避坑与排查：make 找不到、红叉不消失、控制台空着

这套环境的报错有个共同特点：不同的根因会给出高度相似的提示。所以排查不能靠猜，得按「系统环境 → 命令行 → Eclipse 环境 → 工程配置 → 代码」这个由外到内的顺序逐层排除，每层用一个明确的判据确认通过再往下走。

5.1 五类高频翻车现场

现象一：构建时提示Cannot run program "make": Launching failed，工程上一个文件都没编。

原因：CDT 找不到名为make的可执行文件。可能是C:\MinGW\bin没进 Path，可能是进了 Path 但 Eclipse 是在改 Path 之前启动的，也可能是mingw32-make.exe没被复制成make.exe。

解决：先开一个新的命令行窗口跑where make。有输出说明系统层没问题，那就是 Eclipse 进程环境陈旧，彻底退出重启；没输出说明复制或 Path 这两步有一步没做成，回去补。别在 Eclipse 的错误日志里找线索，这里的信息量不如命令行一条where。

现象二：构建完全成功，Console 里一路绿灯，但右键 exe 时 Run As 菜单里没有 Local C/C++ Application。

原因：CDT 没认出这个文件是可执行程序。绝大多数情况是 Binary Parser 选错了——选成 ELF Parser 去解析 PE 格式的 exe，解析失败后 CDT 就不把它当成可运行产物。

解决：进 Project Properties → C/C++ Build → Settings → Binary Parsers，只勾PE Windows Parser，取消其他全部，然后 Clean 一次重新构建。Clean 这一步不能省，因为解析结果有缓存，改完配置不重新构建的话，界面上的表现不会变。

现象三：程序跑起来了，但 Console 里一个字都没有，或者窗口一闪就没了。

原因分两种。一种是程序本身没有输出或者输出被缓冲没刷出来；另一种是 Console 视图当前停在别的页签上，比如停在 CDT Build Console，程序的标准输出其实在另一个 Console 里。

解决：先看 Console 视图右上角有没有多个 Console 图标，点开切换。确认不是页签问题之后，在main返回前加一行fflush(stdout);或者改用fprintf(stderr, ...)输出——stderr是无缓冲的，能立刻看到。如果连stderr都没输出，那就是程序压根没进main，回去检查运行配置里指定的可执行文件路径是不是旧产物。

现象四：工程放在带中文或者空格的目录下，构建报No rule to make target或者链接阶段报找不到文件。

原因：CDT 生成的 makefile 和传给 gcc 的命令行参数在路径含空格时，引号转义处理不完整，路径被从空格处截断成了两段。中文路径则可能在编码转换环节出问题，报错信息里的路径看着是对的，实际传给编译器的字节已经变了。

解决：把工作区和工程目录整体挪到纯英文、无空格的路径下，比如C:\work\。这是唯一彻底的办法，改配置绕不过去。挪完之后要在 Eclipse 里重新 Import 工程，不能直接在旧工作区里改路径。

现象五：改了 Path 和环境变量，命令行里gcc -v正常，Eclipse 里构建还是报找不到编译器。

原因：Eclipse 启动时把父进程的环境整份复制走了，之后系统变量怎么改都不影响已经在跑的进程。更隐蔽的一种情况是从任务栏固定图标或者开始菜单启动 Eclipse，它继承的是启动器缓存的环境，比直接从命令行启动更陈旧。

解决：完全退出 Eclipse（任务管理器确认eclipse.exe进程消失），再从命令行启动一次eclipse.exe，这样它继承的是当前 shell 的最新环境。确认这样能行之后，以后再从图标启动就没问题了，因为系统环境已经刷新。

5.2 一份可以照抄的自检顺序

上面五条覆盖了大部分场景，但真正卡住人的往往是「不知道属于哪一条」。这时候按固定顺序走一遍，比对着报错信息瞎猜快得多。

第一步，开一个全新的命令行窗口（不是已经开着的旧窗口），跑where gcc和gcc -v。这一步验证的是系统层，跟 Eclipse 一点关系没有。

第二步，在命令行里手工编译那个最小hello.c。这一步验证编译器、链接器、运行时库是否完整。编不过就到此为止，去修 MinGW。

第三步，跑where make。没有输出说明复制那一步漏了，补上。

第四步，完全重启 Eclipse，新建一个Hello World C Project，工具链选 MinGW GCC，其他全默认，直接构建。新工程能过，说明问题在原工程的.cproject配置上；新工程也过不了，说明 Preferences 层的 Binary Parser 或者 make 命令有问题。

第五步，进 Preferences 确认 PE Windows Parser 已勾选、其他解析器已取消，再进 Project Properties 确认同样的设置，Clean 后重新构建。

这个顺序的价值在于每一步都有一个明确的通过判据，不会出现「改了一堆设置不知道哪个起了作用」的局面。血泪经验是：不要在没做第一步的情况下直接去动 Eclipse 的配置，那样改十次有九次是白改。

6. 把环境验证成可复用模板：编译选项、调试符号与目录约定

环境配通只是起点。真正省时间的是把验证过的配置固化成模板，下一个工程直接复制，不用重新走一遍 Preferences。

我一般会建一个名为c-template的空工程，工具链选 MinGW GCC，然后在 Project Properties → C/C++ Build → Settings → Tool Settings 里把编译选项一次配好，之后所有新工程都从这个模板复制。

这些选项在 Eclipse 里对应的位置分散在 Dialect、Warnings、Debugging、Optimization 四个分类下，配好之后可以只复制.cproject到新工程，比每次手点快得多。不过.cproject里含工具链 ID 和绝对路径，跨机器复制之前得确认目标机器上的 CDT 版本和 MinGW 路径一致，不一致就得重新配一遍。

命令行层面的等价写法是这样，用来验证 Eclipse 里配出来的命令行到底长什么样：

:: 调试版：带符号、无优化、开全套警告 gcc -Wall -Wextra -g -O0 -std=c99 src\hello.c -o Debug\hello.exe :: 发布版：去符号、开优化，体积和速度都会明显变化 gcc -Wall -Wextra -O2 -std=c99 src\hello.c -o Release\hello.exe

对比这两条命令的输出文件大小，能直观看出-g带来的开销。我在排查「Eclipse 里编出来的程序和命令行编出来的行为不一致」这类玄学问题时，就是靠把 Eclipse 的构建命令行打印出来（Project Properties → C/C++ Build → 勾选 Build command 相关选项，或者直接看Debug/makefile）和这两条对照，通常一次就能定位到差异在哪个编译选项上。

从那以后我每次配新环境，都会先在命令行把hello.c编通、把where gcc和where make的结果截图存下来，再打开 Eclipse。这样后面任何一步出问题，都能立刻判断是环境层还是 IDE 层，不至于在一堆设置里反复横跳。希望帮到你。

本文还有配套的精品资源，点击获取