简介MinGW for Win64 是面向 Windows 64 位平台的 GCC 编译器工具链资源适合在本地学习 C、希望摆脱大型 IDE 依赖的开发者与编程初学者。它解决的是在 Windows 环境下直接编写、编译和调试 C 程序的问题无需虚拟机或复杂配置即可上手。压缩包为 zip 格式整体约 156.05MB包内以 GCC 编译器、libstdc 标准库、Binutils 链接与汇编工具、Make 构建工具及配套头文件和库为主覆盖从源码编译到可执行程序生成的完整链路。资源中的 TDM-GCC-64 是 MinGW 分支针对 64 位系统优化集成较新的 GCC 版本支持 C11/14/17 及部分 C20 特性。已有 115 人学习下载适合想通过命令行理解编译过程、追求轻量级开发环境的读者参考使用。1. 为什么我劝你先别急着装 Visual StudioMinGW for Win64 到底解决了什么如果你在 Windows 上写 C大概率遇到过这种场景只是想验证一段 20 行的算法或者给某个开源库写个最小复现结果为了一个g命令被迫下载了十几个 GB 的 IDE 全家桶。装完之后环境变量、SDK 版本、MSVC 运行时又搅在一起换台机器就得重来一遍。MinGW for Win64 就是冲着这个痛点来的——它把 GCC 工具链裁剪成一套能在 64 位 Windows 上直接跑的精简环境解压、配路径、敲命令三步之内就能让g吐出第一个.exe。这套东西适合谁一类是刚接触 C、不想被 IDE 绑架的新手想先把「编译→链接→运行」这条链路摸清楚另一类是做跨平台开发的老手需要在 Windows 上快速验证 Linux 风格的构建脚本或者给 CI 流水线塞一个轻量的编译节点。它不替代 Visual Studio 的调试器和 Windows SDK 深度集成但在「快速拿到一个能跑的二进制」这件事上MinGW for Win64 的启动成本低得离谱。下面我从工具链构成、安装配置、编译实操到踩坑排查把这条链路完整拆一遍。2. MinGW for Win64 的工具链拆解从 bin 目录里到底装了什么说起2.1 不是「一个编译器」而是一整套 GNU 工具集很多人以为 MinGW 就是g.exe一个文件解压完发现 bin 目录里躺着几十个可执行文件瞬间懵了。实际上 MinGW for Win64 是一组工具的集合核心成员包括文件名作用典型调用场景gcc.exeC 编译器驱动编译.c文件g.exeC 编译器驱动编译.cpp文件cpp.exe预处理器查看宏展开结果as.exe汇编器把.s转成.old.exe链接器合并目标文件和库ar.exe静态库打包生成.a归档gdb.exe调试器单步、断点、查看栈mingw32-make.exe构建工具执行 Makefilewindres.exe资源编译编译.rc资源脚本这里有个容易混淆的点gcc和g不是两个独立的编译器它们只是驱动前端真正干活的是cc1和cc1plus。g在链接阶段会自动带上libstdc而gcc不会——这就是为什么用gcc编译 C 文件经常报undefined reference to std::cout这类错误。常见做法是C 代码用gccC 代码一律用g别混着来。2.2 为什么选 MinGW 而不是 MSVC 或 Clang选型这件事没有绝对优劣只有场景匹配。我把三个常见选项拉平了对比MSVC和 Windows SDK 绑定最深调试体验最好但命令行调用需要vcvarsall.bat初始化环境换版本就得重新配。适合做 Windows 原生 GUI 和 DirectX 开发。Clang for Windows错误信息可读性最强但默认链接的是 MSVC 的运行时库配置不当会出现 ABI 不兼容。MinGW for Win64生成的是原生 PE 文件不依赖额外运行时 DLL静态链接时命令行即开即用和 Linux 下的 GCC 用法几乎一致。适合算法验证、跨平台库编译、教学演示。我一般会这样建议如果你的项目最终要跑在 Windows 上并且需要深度系统调用MSVC 更稳如果你只是想要一个「像 Linux 一样」的编译环境MinGW for Win64 的迁移成本最低。注意MinGW 生成的二进制默认动态链接libgcc_s_seh-1.dll和libstdc-6.dll分发时要么把这些 DLL 一起带上要么加-static静态链接。2.3 安装与 PATH 配置三个必须检查的路径MinGW for Win64 通常是压缩包形式解压到一个没有空格和中文的路径下比如D:\dev\mingw64。目录结构大致是mingw64/ ├── bin/ # 可执行文件 ├── include/ # 头文件 ├── lib/ # 库文件 ├── libexec/ # 内部程序 └── share/ # 文档和许可证配置环境变量时只需要把D:\dev\mingw64\bin追加到系统Path里。但这里有个血泪经验如果你之前装过其他版本的 GCC 或者 Git 自带的 MinGWPath里可能存在多个g.exe命令行调用的到底是谁完全看顺序。验证方法是在 CMD 里执行where g g --versionwhere会按Path顺序列出所有匹配项第一条才是实际生效的。--version输出的第一行会告诉你版本号和目标平台确认是x86_64-w64-mingw32才算对。如果输出的是i686开头说明你装的是 32 位版本编译 64 位程序会出问题。提示改完Path后一定要新开一个终端窗口旧窗口的环境变量是启动时快照的不会自动刷新。3. 从源码到 exe用 g 跑通第一个 64 位程序3.1 编译单文件四个参数决定输出形态先写一个最小示例保存为hello.cpp// hello.cpp #include iostream #include vector int main() { std::vectorint nums {1, 2, 3, 4, 5}; int sum 0; for (int n : nums) { sum n; } std::cout sum sum std::endl; return 0; }最基础的编译命令g hello.cpp -o hello.exe这条命令背后发生了四件事预处理展开#include和宏、编译生成汇编、汇编生成目标文件.o、链接合并库并生成.exe。如果想看每一步的中间产物可以加-save-tempsg -save-temps hello.cpp -o hello.exe执行后会多出hello.i预处理结果、hello.s汇编、hello.o目标文件。排查宏展开问题时直接看.i文件比在代码里猜快得多。常用参数我整理成了一张表按使用频率排序参数含义什么时候用-o指定输出文件名几乎每次都用-Wall -Wextra开启警告写新代码时必开-g生成调试信息需要 gdb 调试时-O2二级优化发布版本-stdc17指定标准用到新特性时-static静态链接分发单文件 exe-I追加头文件搜索路径引用第三方库-L追加库搜索路径链接第三方库-l链接指定库如-lpthread3.2 多文件与静态库把编译和链接拆开单文件编译只是热身真实项目往往是多个.cpp加若干.h。假设有两个源文件math_utils.cpp和main.cpp头文件math_utils.h// math_utils.h #pragma once int add(int a, int b); int multiply(int a, int b);// math_utils.cpp #include math_utils.h int add(int a, int b) { return a b; } int multiply(int a, int b) { return a * b; }// main.cpp #include iostream #include math_utils.h int main() { std::cout add(3, 4) std::endl; std::cout multiply(3, 4) std::endl; return 0; }分步编译# 第一步各自编译成目标文件-c 表示只编译不链接 g -c math_utils.cpp -o math_utils.o -Wall -O2 g -c main.cpp -o main.o -Wall -O2 # 第二步链接所有目标文件 g main.o math_utils.o -o app.exe这样做的好处是改一个文件只需要重新编译那一个.o不用全量重编。如果math_utils要被多个项目复用可以打包成静态库# 用 ar 把目标文件打包成 .a 归档 ar rcs libmath_utils.a math_utils.o # 链接时指定库路径和库名 g main.o -L. -lmath_utils -o app.exe注意-lmath_utils会自动去找libmath_utils.a或libmath_utils.dll.a前缀lib和后缀不用写。-L.表示在当前目录找库文件。如果链接时报cannot find -lmath_utils先确认.a文件确实在-L指定的目录里再确认文件名拼写。3.3 用 Makefile 管住编译流程文件一多手敲命令迟早翻车。MinGW for Win64 自带mingw32-make.exe可以直接跑 Makefile。一个够用的模板# Makefile CXX g CXXFLAGS -Wall -Wextra -O2 -stdc17 TARGET app.exe OBJS main.o math_utils.o $(TARGET): $(OBJS) $(CXX) $(OBJS) -o $(TARGET) %.o: %.cpp $(CXX) $(CXXFLAGS) -c $ -o $ clean: del /Q *.o $(TARGET)执行mingw32-make就会自动推导依赖并编译。这里有个坑Makefile 里的缩进必须是 Tab 字符空格会报missing separator。另外clean目标里用的是 Windows 的del命令如果你在 Git Bash 里跑得换成rm -f。注意mingw32-make和 GNUmake在 Windows 路径处理上有细微差别如果 Makefile 里写了/路径通常没问题但涉及盘符时要小心。4. 避坑与排查那些让新手卡半天的报错4.1 现象g: command not found但 bin 目录里明明有原因通常有三种一是Path没配或配错二是改了Path但没重开终端三是路径里有空格导致解析截断。解决方法是先用绝对路径调用一次D:\dev\mingw64\bin\g.exe --version如果能跑通说明工具链本身没问题问题出在Path。检查Path里是否写成了D:\dev\mingw64\bin\末尾反斜杠在某些情况下会出问题以及是否被其他条目覆盖。用where g确认实际命中的是哪一个。4.2 现象编译通过运行时报libstdc-6.dll缺失原因MinGW 默认动态链接 C 运行时库生成的 exe 依赖同目录或系统路径下的 DLL。解决方式有两种一是把mingw64\bin下的libstdc-6.dll、libgcc_s_seh-1.dll、libwinpthread-1.dll复制到 exe 同目录二是编译时加-static静态链接g main.cpp -o app.exe -static -static-libgcc -static-libstdc静态链接的 exe 体积会大几百 KB 到几 MB但分发时不用带一堆 DLL适合做小工具。注意-static和-static-libgcc同时用时某些第三方库可能仍然动态链接需要逐个确认。4.3 现象中文输出乱码控制台显示问号原因源码文件编码、编译器执行字符集、控制台代码页三者不一致。MinGW 默认按 UTF-8 处理源码但 Windows 控制台默认代码页是 GBK936。解决方式是在编译时指定执行字符集g main.cpp -o app.exe -fexec-charsetGBK或者在源码里用SetConsoleOutputCP(65001)把控制台切到 UTF-8。我一般会统一用 UTF-8 源码加-fexec-charsetGBK这样在 CMD 和 PowerShell 里都能正常显示。如果用的是 Windows Terminal默认就是 UTF-8可以不加这个参数。4.4 现象链接第三方库时报undefined reference但头文件能找到原因头文件路径由-I控制库文件路径由-L控制两者是独立的。头文件能找到只说明编译阶段过了链接阶段找不到符号说明库没链上。排查步骤先用nm查看库文件里有没有那个符号nm libfoo.a | grep 函数名如果符号存在但链接失败检查-l的顺序——GCC 链接器是从左到右解析依赖的被依赖的库要放在依赖它的目标文件后面。比如g main.o -lfoo -lbar如果foo依赖bar顺序不能反。4.5 现象mingw32-make报missing separator原因Makefile 里用了空格而不是 Tab 缩进。这是最经典的翻车点因为肉眼几乎看不出区别。解决方法是在编辑器里开启「显示空白字符」把所有命令行前的缩进统一换成 Tab。VS Code 右下角可以切换缩进类型改成「Tab 缩进」后重新保存。5. 进阶技巧用 gdb 调试和条件断点定位玄学问题编译期的问题相对好查运行期的玄学才折磨人。MinGW for Win64 自带gdb.exe配合-g编译选项就能单步调试。先编译一个带调试信息的版本g -g -O0 main.cpp -o app_debug.exe然后启动 gdbgdb app_debug.exe进入 gdb 交互界面后常用命令如下命令简写作用break 文件名:行号b设置断点runr启动程序nextn单步跳过steps单步进入print 变量p打印变量值backtracebt查看调用栈continuec继续运行quitq退出条件断点是排查循环内异常的利器。比如怀疑某个数组在第 50 次迭代时越界break main.cpp:23 if i 50这样程序只会在i等于 50 时停下来不用手动按 50 次continue。如果崩溃时没有断点可以用bt看调用栈再用frame N切换到具体栈帧p查看局部变量。注意-O2优化会打乱变量和行号的对应关系调试时一律用-O0。还有一个容易被忽略的点gdb 在 Windows 上对中文路径支持不好如果源码放在中文目录下断点可能设不上。我一般会把项目放在纯英文路径下比如D:\work\demo省去这类麻烦。从那以后我每次新建项目第一件事就是确认路径里没有空格和中文这个习惯帮我省掉了至少十次莫名其妙的报错。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/15 20:18:27 · 阅读 1.2k MinGW for Win64 入门指南：从安装配置到 g++ 编译与 gdb 调试
简介MinGW for Win64 是面向 Windows 64 位平台的 GCC 编译器工具链资源适合在本地学习 C、希望摆脱大型 IDE 依赖的开发者与编程初学者。它解决的是在 Windows 环境下直接编写、编译和调试 C 程序的问题无需虚拟机或复杂配置即可上手。压缩包为 zip 格式整体约 156.05MB包内以 GCC 编译器、libstdc 标准库、Binutils 链接与汇编工具、Make 构建工具及配套头文件和库为主覆盖从源码编译到可执行程序生成的完整链路。资源中的 TDM-GCC-64 是 MinGW 分支针对 64 位系统优化集成较新的 GCC 版本支持 C11/14/17 及部分 C20 特性。已有 115 人学习下载适合想通过命令行理解编译过程、追求轻量级开发环境的读者参考使用。1. 为什么我劝你先别急着装 Visual StudioMinGW for Win64 到底解决了什么如果你在 Windows 上写 C大概率遇到过这种场景只是想验证一段 20 行的算法或者给某个开源库写个最小复现结果为了一个g命令被迫下载了十几个 GB 的 IDE 全家桶。装完之后环境变量、SDK 版本、MSVC 运行时又搅在一起换台机器就得重来一遍。MinGW for Win64 就是冲着这个痛点来的——它把 GCC 工具链裁剪成一套能在 64 位 Windows 上直接跑的精简环境解压、配路径、敲命令三步之内就能让g吐出第一个.exe。这套东西适合谁一类是刚接触 C、不想被 IDE 绑架的新手想先把「编译→链接→运行」这条链路摸清楚另一类是做跨平台开发的老手需要在 Windows 上快速验证 Linux 风格的构建脚本或者给 CI 流水线塞一个轻量的编译节点。它不替代 Visual Studio 的调试器和 Windows SDK 深度集成但在「快速拿到一个能跑的二进制」这件事上MinGW for Win64 的启动成本低得离谱。下面我从工具链构成、安装配置、编译实操到踩坑排查把这条链路完整拆一遍。2. MinGW for Win64 的工具链拆解从 bin 目录里到底装了什么说起2.1 不是「一个编译器」而是一整套 GNU 工具集很多人以为 MinGW 就是g.exe一个文件解压完发现 bin 目录里躺着几十个可执行文件瞬间懵了。实际上 MinGW for Win64 是一组工具的集合核心成员包括文件名作用典型调用场景gcc.exeC 编译器驱动编译.c文件g.exeC 编译器驱动编译.cpp文件cpp.exe预处理器查看宏展开结果as.exe汇编器把.s转成.old.exe链接器合并目标文件和库ar.exe静态库打包生成.a归档gdb.exe调试器单步、断点、查看栈mingw32-make.exe构建工具执行 Makefilewindres.exe资源编译编译.rc资源脚本这里有个容易混淆的点gcc和g不是两个独立的编译器它们只是驱动前端真正干活的是cc1和cc1plus。g在链接阶段会自动带上libstdc而gcc不会——这就是为什么用gcc编译 C 文件经常报undefined reference to std::cout这类错误。常见做法是C 代码用gccC 代码一律用g别混着来。2.2 为什么选 MinGW 而不是 MSVC 或 Clang选型这件事没有绝对优劣只有场景匹配。我把三个常见选项拉平了对比MSVC和 Windows SDK 绑定最深调试体验最好但命令行调用需要vcvarsall.bat初始化环境换版本就得重新配。适合做 Windows 原生 GUI 和 DirectX 开发。Clang for Windows错误信息可读性最强但默认链接的是 MSVC 的运行时库配置不当会出现 ABI 不兼容。MinGW for Win64生成的是原生 PE 文件不依赖额外运行时 DLL静态链接时命令行即开即用和 Linux 下的 GCC 用法几乎一致。适合算法验证、跨平台库编译、教学演示。我一般会这样建议如果你的项目最终要跑在 Windows 上并且需要深度系统调用MSVC 更稳如果你只是想要一个「像 Linux 一样」的编译环境MinGW for Win64 的迁移成本最低。注意MinGW 生成的二进制默认动态链接libgcc_s_seh-1.dll和libstdc-6.dll分发时要么把这些 DLL 一起带上要么加-static静态链接。2.3 安装与 PATH 配置三个必须检查的路径MinGW for Win64 通常是压缩包形式解压到一个没有空格和中文的路径下比如D:\dev\mingw64。目录结构大致是mingw64/ ├── bin/ # 可执行文件 ├── include/ # 头文件 ├── lib/ # 库文件 ├── libexec/ # 内部程序 └── share/ # 文档和许可证配置环境变量时只需要把D:\dev\mingw64\bin追加到系统Path里。但这里有个血泪经验如果你之前装过其他版本的 GCC 或者 Git 自带的 MinGWPath里可能存在多个g.exe命令行调用的到底是谁完全看顺序。验证方法是在 CMD 里执行where g g --versionwhere会按Path顺序列出所有匹配项第一条才是实际生效的。--version输出的第一行会告诉你版本号和目标平台确认是x86_64-w64-mingw32才算对。如果输出的是i686开头说明你装的是 32 位版本编译 64 位程序会出问题。提示改完Path后一定要新开一个终端窗口旧窗口的环境变量是启动时快照的不会自动刷新。3. 从源码到 exe用 g 跑通第一个 64 位程序3.1 编译单文件四个参数决定输出形态先写一个最小示例保存为hello.cpp// hello.cpp #include iostream #include vector int main() { std::vectorint nums {1, 2, 3, 4, 5}; int sum 0; for (int n : nums) { sum n; } std::cout sum sum std::endl; return 0; }最基础的编译命令g hello.cpp -o hello.exe这条命令背后发生了四件事预处理展开#include和宏、编译生成汇编、汇编生成目标文件.o、链接合并库并生成.exe。如果想看每一步的中间产物可以加-save-tempsg -save-temps hello.cpp -o hello.exe执行后会多出hello.i预处理结果、hello.s汇编、hello.o目标文件。排查宏展开问题时直接看.i文件比在代码里猜快得多。常用参数我整理成了一张表按使用频率排序参数含义什么时候用-o指定输出文件名几乎每次都用-Wall -Wextra开启警告写新代码时必开-g生成调试信息需要 gdb 调试时-O2二级优化发布版本-stdc17指定标准用到新特性时-static静态链接分发单文件 exe-I追加头文件搜索路径引用第三方库-L追加库搜索路径链接第三方库-l链接指定库如-lpthread3.2 多文件与静态库把编译和链接拆开单文件编译只是热身真实项目往往是多个.cpp加若干.h。假设有两个源文件math_utils.cpp和main.cpp头文件math_utils.h// math_utils.h #pragma once int add(int a, int b); int multiply(int a, int b);// math_utils.cpp #include math_utils.h int add(int a, int b) { return a b; } int multiply(int a, int b) { return a * b; }// main.cpp #include iostream #include math_utils.h int main() { std::cout add(3, 4) std::endl; std::cout multiply(3, 4) std::endl; return 0; }分步编译# 第一步各自编译成目标文件-c 表示只编译不链接 g -c math_utils.cpp -o math_utils.o -Wall -O2 g -c main.cpp -o main.o -Wall -O2 # 第二步链接所有目标文件 g main.o math_utils.o -o app.exe这样做的好处是改一个文件只需要重新编译那一个.o不用全量重编。如果math_utils要被多个项目复用可以打包成静态库# 用 ar 把目标文件打包成 .a 归档 ar rcs libmath_utils.a math_utils.o # 链接时指定库路径和库名 g main.o -L. -lmath_utils -o app.exe注意-lmath_utils会自动去找libmath_utils.a或libmath_utils.dll.a前缀lib和后缀不用写。-L.表示在当前目录找库文件。如果链接时报cannot find -lmath_utils先确认.a文件确实在-L指定的目录里再确认文件名拼写。3.3 用 Makefile 管住编译流程文件一多手敲命令迟早翻车。MinGW for Win64 自带mingw32-make.exe可以直接跑 Makefile。一个够用的模板# Makefile CXX g CXXFLAGS -Wall -Wextra -O2 -stdc17 TARGET app.exe OBJS main.o math_utils.o $(TARGET): $(OBJS) $(CXX) $(OBJS) -o $(TARGET) %.o: %.cpp $(CXX) $(CXXFLAGS) -c $ -o $ clean: del /Q *.o $(TARGET)执行mingw32-make就会自动推导依赖并编译。这里有个坑Makefile 里的缩进必须是 Tab 字符空格会报missing separator。另外clean目标里用的是 Windows 的del命令如果你在 Git Bash 里跑得换成rm -f。注意mingw32-make和 GNUmake在 Windows 路径处理上有细微差别如果 Makefile 里写了/路径通常没问题但涉及盘符时要小心。4. 避坑与排查那些让新手卡半天的报错4.1 现象g: command not found但 bin 目录里明明有原因通常有三种一是Path没配或配错二是改了Path但没重开终端三是路径里有空格导致解析截断。解决方法是先用绝对路径调用一次D:\dev\mingw64\bin\g.exe --version如果能跑通说明工具链本身没问题问题出在Path。检查Path里是否写成了D:\dev\mingw64\bin\末尾反斜杠在某些情况下会出问题以及是否被其他条目覆盖。用where g确认实际命中的是哪一个。4.2 现象编译通过运行时报libstdc-6.dll缺失原因MinGW 默认动态链接 C 运行时库生成的 exe 依赖同目录或系统路径下的 DLL。解决方式有两种一是把mingw64\bin下的libstdc-6.dll、libgcc_s_seh-1.dll、libwinpthread-1.dll复制到 exe 同目录二是编译时加-static静态链接g main.cpp -o app.exe -static -static-libgcc -static-libstdc静态链接的 exe 体积会大几百 KB 到几 MB但分发时不用带一堆 DLL适合做小工具。注意-static和-static-libgcc同时用时某些第三方库可能仍然动态链接需要逐个确认。4.3 现象中文输出乱码控制台显示问号原因源码文件编码、编译器执行字符集、控制台代码页三者不一致。MinGW 默认按 UTF-8 处理源码但 Windows 控制台默认代码页是 GBK936。解决方式是在编译时指定执行字符集g main.cpp -o app.exe -fexec-charsetGBK或者在源码里用SetConsoleOutputCP(65001)把控制台切到 UTF-8。我一般会统一用 UTF-8 源码加-fexec-charsetGBK这样在 CMD 和 PowerShell 里都能正常显示。如果用的是 Windows Terminal默认就是 UTF-8可以不加这个参数。4.4 现象链接第三方库时报undefined reference但头文件能找到原因头文件路径由-I控制库文件路径由-L控制两者是独立的。头文件能找到只说明编译阶段过了链接阶段找不到符号说明库没链上。排查步骤先用nm查看库文件里有没有那个符号nm libfoo.a | grep 函数名如果符号存在但链接失败检查-l的顺序——GCC 链接器是从左到右解析依赖的被依赖的库要放在依赖它的目标文件后面。比如g main.o -lfoo -lbar如果foo依赖bar顺序不能反。4.5 现象mingw32-make报missing separator原因Makefile 里用了空格而不是 Tab 缩进。这是最经典的翻车点因为肉眼几乎看不出区别。解决方法是在编辑器里开启「显示空白字符」把所有命令行前的缩进统一换成 Tab。VS Code 右下角可以切换缩进类型改成「Tab 缩进」后重新保存。5. 进阶技巧用 gdb 调试和条件断点定位玄学问题编译期的问题相对好查运行期的玄学才折磨人。MinGW for Win64 自带gdb.exe配合-g编译选项就能单步调试。先编译一个带调试信息的版本g -g -O0 main.cpp -o app_debug.exe然后启动 gdbgdb app_debug.exe进入 gdb 交互界面后常用命令如下命令简写作用break 文件名:行号b设置断点runr启动程序nextn单步跳过steps单步进入print 变量p打印变量值backtracebt查看调用栈continuec继续运行quitq退出条件断点是排查循环内异常的利器。比如怀疑某个数组在第 50 次迭代时越界break main.cpp:23 if i 50这样程序只会在i等于 50 时停下来不用手动按 50 次continue。如果崩溃时没有断点可以用bt看调用栈再用frame N切换到具体栈帧p查看局部变量。注意-O2优化会打乱变量和行号的对应关系调试时一律用-O0。还有一个容易被忽略的点gdb 在 Windows 上对中文路径支持不好如果源码放在中文目录下断点可能设不上。我一般会把项目放在纯英文路径下比如D:\work\demo省去这类麻烦。从那以后我每次新建项目第一件事就是确认路径里没有空格和中文这个习惯帮我省掉了至少十次莫名其妙的报错。希望帮到你。本文还有配套的精品资源点击获取