企业官网建设流程全解析

简介：这是一份面向Windows开发者的MinGW 64位离线安装包，内嵌GCC 13.1.0工具链，适用于需要在64位系统上编译原生C/C++程序却又受网络条件限制的用户。包体共18725个文件，除编译器、链接器外，还包含以h/hpp头文件、a/lib静态库、dll动态库及py/pyc辅助脚本为主的完整开发组件，并附带大量标准库头文件与终端配置数据，整体约68.89MB，解压后即可在离线环境搭建完整编译环境。已有1645人学习下载。对希望借助最新稳定版GCC特性提升代码效率、需要离线调试或进行跨平台开发的开发者而言，这份资源能一次性提供编译、链接、标准库及基础工具集，省去联网配置的繁琐步骤。

1. 引言：一个版本号串起来的完整工具链

某开发者在搭建 Windows 下的编译环境时，下载了 MinGW-w64 的离线安装包，却发现网上教程里的版本号五花八门：有 posix 也有 win32，有 seh 也有 sjlj，有 ucrt 也有 msvcrt。文件名里一串x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r到底是什么意思？这套离线安装包能解决什么问题？其实这段版本号不是随便拼出来的，它分别锁定了架构、GCC 版本、线程模型、异常处理模型、C 运行时和工具链修订号，每个字段都直接影响到你写出来的 C/C++ 程序能不能编译、能不能运行、能不能带上std::thread。这篇文章就围绕这个版本号展开，从选型到安装、从编译到排错，给你一套拿来就能用的落地路径。

2. 版本号拆解：x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r 到底选了什么

2.1 x86-64 与 13.1.0：架构和 GCC 版本的地基

x86-64指的是目标架构是 64 位，对应的指令集是 AMD64（Intel 和 AMD 在 PC 上通用的 64 位指令集）。这个字段决定了你编译出来的程序是跑在 64 位 Windows 上的，调用的是 64 位的 Windows API，使用 64 位地址空间。反过来，如果你看到i686开头的包，那意味着编译目标是 32 位程序。现在新开发的 PC 软件基本都该选 x86-64，除非你明确知道用户环境是 32 位 Windows 或需要兼容旧系统。

13.1.0是 GCC 编译器的版本号。GCC 13 系列是一个比较大的版本跳跃，它在 C++ 标准支持上进步明显，对 C++20 的特性支持更完整，比如协程、<=>三向比较运算符等，同时引入了-fanalyzer这类静态分析增强选项。如果你要在 Windows 上写 C++20 代码，GCC 13 是一个顺手的选择。GCC 版本字段主要影响两点：一是语言标准支持到什么程度，二是生成的代码质量（优化器能力）。在 MinGW-w64 这个体系里，GCC 版本往往还和配套的 binutils、GDB 调试器版本联动，所以版本号高不完全等于"更激进"，它代表整条工具链的基准线。

2.2 posix vs win32：线程模型直接决定 C++11 线程能不能用

这是整个命名里最容易踩坑的字段。posix指的是线程模型采用 POSIX 线程接口（通过 winpthreads 库实现在 Windows 上提供 pthread API），而win32线程模型直接调用 Windows 原生线程 API。两者的本质区别在于：GCC 的 C++ 标准库 libstdc++ 在实现std::thread、std::mutex、std::condition_variable等 C++11 线程设施时，依赖的是一个 pthread 兼容层。只有线程模型选posix，你的代码里才能正常使用std::thread；选了win32线程模型，std::thread在链接阶段就会报undefined reference to pthread_create之类的错误，因为库内部没有对应的符号实现。

用std::thread写多线程代码已经是现代 C++ 的基本功，所以面向桌面应用开发、中间件开发、服务器程序移植这类场景，直接选posix线程模型。它不会让你的程序变慢，只是在你调用std::thread时，底层映射到 Windows 的CreateThread，中间多一层封装开销，而这层封装几乎可以忽略不计。如果你做的是纯 C 开发、且确定不需要 C++ 线程库，那win32模型也能用，但没必要为了这点去踩std::thread不可用的坑。

2.3 seh：64 位下异常处理模型的正确选择

seh全称 Structured Exception Handling（结构化异常处理），是 Windows 原生提供的异常机制。MinGW-w64 在 64 位下提供两种异常处理模型：seh和sjlj（setjmp/longjmp）。seh的优点是异常分派速度更快，因为不需要像sjlj那样在每次进入 try 块时建立跳转上下文，也不需要维护额外状态；缺点是只支持 x86-64 架构。sjlj兼容 32 位和 64 位 Windows，但异常处理的运行时开销明显更大，尤其在频繁进入/退出 try 块的热路径上，性能差距可能达到数倍。

对你来说，只要目标平台是 64 位 Windows，无脑选seh就是对的。它和 Visual C++ 的异常处理在底层逻辑上同源，虽然不是完全兼容的 ABI，但行为方式更接近 Windows 生态的预期。选sjlj只有一个正当理由——你需要同一份代码在 32 位和 64 位之间无差别切换编译，但更常见的做法是直接下两个包，而不是用 sjlj 包打天下。

2.4 ucrt：新运行时带来的兼容性红利

ucrt是 Universal C Runtime 的缩写，它是 Windows 10 及以后版本系统自带的 C 运行时库。对比旧版的msvcrt（Visual C++ 运行时），ucrt提供了更多兼容 POSIX 和标准 C 的函数实现，也修复了很多历史遗留问题。MinGW-w64 从 GCC 13 构建版本开始，默认就出ucrt变体，这是微软自己也主推的方向——VS2015 之后的 Visual Studio 全都用 UCRT 替代了 msvcrt。

选ucrt意味着你的编译产物依赖ucrtbase.dll和api-ms-win-*这类系统组件，而这些在 Windows 10/11 系统里都是现成的，不需要自己带，也不用安装任何运行库。反过来，msvcrt变体的产物是依赖老版msvcrt.dll，兼容 Windows 7 这类老系统，但代价是缺失新函数、行为差异多。以 2024 年的眼光看，如果你的用户群体跑 Windows 10 及以上，直接选ucrt，不用犹豫。这里有一个隐藏的好处是，ucrt变体编译出来的程序与 Visual Studio 编译出来的程序在 C 运行时层面更"谈得来"，混用 DLL 时不容易出幺蛾子。

2.5 rt-v11-r：修订号背后的版本节奏

rt-v11-r是工具链修订版本标识，它代表整套 MinGW-w64 工具集（binutils、GCC 补丁、运行时库 winpthreads 等）被打包到第 11 次修订。这个字段的意义不在于功能差异，而在于你拿到的是一个经过整合测试的快照。MinGW-w64 并不是单个项目，而是 GCC + binutils + mingw-w64 运行时库 + winpthreads 等多个上游项目拼装起来的，每个上游项目各自维护版本。rt-v11-r表明这些组件在某个时间点被统一拉齐、做过联调、修复过已知问题。

你必须明白一点：MinGW-w64 没有"官方安装器"这一说，常见的都是第三方维护者用脚本把工具链打包发布的。这个rt-v11-r就是你用来追踪打包状态的凭证。看到更新版本的rt-v12、rt-v13，你可以判断这个源是不是还在活跃维护；如果某个下载源半年没更新 rt 号，说明维护者已经不怎么跟进 GCC 上游了。对生产环境来说，rt-v11-r+ GCC 13.1.0 是一个可靠组合，它经过了大量用户的反馈和踩坑验证，不是那种刚发布就有明显问题的先行版。

3. 离线安装三步走：解压、路径、验证

3.1 第一步：解压到正确位置，避开两种坑

离线安装包一般是.7z或者.zip压缩格式，拿到手先解压。这里我强烈建议用 7-Zip（或 WinRAR 的 7z 模式）而不是 Windows 自带的资源管理器解压器。原因有两点：第一，MinGW-w64 的文件数量多、路径深，自带的解压器在处理长路径和特殊权限时有概率漏文件；第二，某些压缩包内包含符号链接或者硬链接信息，7-Zip 能正确还原，而自带解压器可能会把链接变成两份拷贝，这会导致后续链接阶段报"文件格式不认识"的错。

解压时注意两个坑：

注意：路径中绝对不要出现中文和空格。比如C:\Program Files\mingw64或者D:\开发工具\mingw64都会埋雷。空格会让部分脚本化的构建工具（尤其老旧的 configure 脚本）在解析路径时翻车，中文则可能让编译器在生成调试信息时出现字符集乱码。最稳妥的路径是C:\mingw64或D:\tools\mingw64。

解压完成后，你应该看到一个mingw64目录，里面至少包含bin、lib、include、libexec、share这几个子目录，以及libgcc、x86_64-w64-mingw32这类架构相关目录。如果缺少libexec或者include目录，说明解压不完整或者包本身有问题。此时回头重新解压，不要将就着用——缺失目录会在编译时以各种离谱的方式报错，比如找不到stdio.h或者cc1.exe执行失败。

3.2 第二步：环境变量的两种配置方式

解压本身只是把文件放到了磁盘上，系统还不知道去哪里找gcc.exe。你需要把C:\mingw64\bin加进系统环境变量 PATH。注意是bin目录，不是mingw64根目录，因为编译器的所有可执行文件（gcc.exe、g++.exe、gfortran.exe、mingw32-make.exe、gdb.exe等）都在bin下。

配置方式有两种，各有适用的场景。第一种是图形界面操作：右键"此电脑"→ 属性 → 高级系统设置 → 环境变量 → 在"系统变量"中找到Path→ 编辑 → 新建 → 填入C:\mingw64\bin→ 一路确定。这种方式适合一次性配置，配置完成之后所有新开的终端窗口都能生效，但要注意"系统变量"和"用户变量"的区别——系统变量对所有用户生效，用户变量只对当前用户生效。如果你这台机器上有多个用户，建议设到系统变量；如果只是自己开发用，用户变量就够，还能避免污染其他用户的 PATH。

第二种是命令行方式，适合写文档或自动化脚本时用：

setx PATH "%PATH%;C:\mingw64\bin"

这条命令把当前 PATH 原值后面追加一个C:\mingw64\bin。但要注意setx有个经典陷阱：它会截断超过 1024 字符的环境变量值。如果你的 PATH 本来就很长，用这条命令可能把后面的内容截掉，得不偿失。所以生产环境我一般建议用图形界面改，或者用 PowerShell 的[Environment]::SetEnvironmentVariable方法，它能处理更长内容：

[Environment]::SetEnvironmentVariable("Path", $env:Path + ";C:\mingw64\bin", "Machine")

这里的"Machine"代表系统级变量，如果你只想改当前用户，换成"User"。这段命令的逻辑是读取当前进程的 PATH，追加新路径后写回系统变量。注意用 PowerShell 写入"Machine"级别时，终端必须以管理员身份运行，否则会报访问拒绝。

3.3 第三步：用三个命令确认安装成功

配置完环境变量后，重开一个干净的终端窗口（这一步很关键，旧的终端窗口里 PATH 没有刷新，直接验证必然失败）。然后依次执行：

gcc --version

第一条命令查看 C 编译器版本。正常输出会显示gcc.exe (x86_64-win64-seh-rev1) 13.1.0这样的信息，其中x86_64-win64-seh-rev1是你这个包的完整标识，能看到seh说明异常处理模型选对了。

g++ --version

第二条命令验证 C++ 编译器。输出里同样应该包含13.1.0，如果这条命令报"不是内部或外部命令"，说明 PATH 没配置对，或者你bin目录里没有g++.exe。

where gcc

第三条命令用来确认系统实际命中的gcc.exe是哪一份。Windows 的 PATH 是按顺序查找的，如果你机器上装过其他编译器（比如 Oracle 的 GCC、其他版本的 MinGW），where命令会列出所有匹配的gcc.exe，排在最上面的就是实际生效的那个。这一步能帮你发现"版本被抢占"的隐患，后面第 5 章会展开讲。

三条命令全部通过后，离线工具链就已经在你的机器上跑起来了。此时你可以顺手执行一下mingw32-make --version，确认 make 工具也在，这个后面写 Makefile 时要用到。

3.4 离线安装为什么比在线安装更适合生产环境

这里要展开说一个容易被忽视的点。MinGW-w64 也有在线安装器（比如官方的 mingw-get、或者第三方基于网络下载的安装脚本），它像一个包管理器一样，可以在线拉取指定版本的 GCC、binutils 和运行时库。听起来很方便，但生产环境我反而推荐离线包。

核心原因是离线包的可重复性。在线安装器拉取的是某个时刻的"最新"组件，你这次装的是 A 版本，朋友下次装的是 B 版本，两个人写同样的代码，可能因为工具链差异出现不同的编译结果。离线安装包是固定的快照，x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r这个文件名本身就是版本锁定的声明，整个团队、整个 CI 流水线都用同一个包，编译结果才能对齐。

另外，离线包自带完整的目录结构，支持"绿色化"使用——不想动系统 PATH 的时候，你可以直接在 IDE 里指定编译器路径，比如在某个 IDE 或编辑器的编译设置里把编译器指向C:\mingw64\bin\g++.exe。这意味着它能装进 USB 移动盘，插到哪台机器上都用同一套工具链。在线安装器做不到这一点，它默认把文件打散到系统目录里，想迁移就得重新装一遍。

4. 最小编译流程与常用参数

4.1 从源码到 exe：一次最小的 g++ 调用

离线包装好之后，核心交付能力就是把.cpp源码变成 Windows 上可执行的.exe。先建一个最简测试文件，确认工具链的真实可用性：

// hello.cpp #include <iostream> int main() { std::cout << "Hello from MinGW-w64" << std::endl; return 0; }

然后在终端里执行：

g++ hello.cpp -o hello.exe

这条命令的效果是把hello.cpp编译并链接成hello.exe。如果整个流程一次通过，说明工具链的基础链路（预处理器 → 编译器 → 汇编器 → 链接器）是通的。如果这步就报错，说明离线包的文件有问题，或者路径配置没生效。

接下来，把命令升级一下，加入标准的工程参数：

g++ hello.cpp -o hello.exe -std=c++17 -Wall -O2

• -std=c++17：启用 C++17 标准，让编译器按 C++17 的语法规则来解析代码。MinGW-w64 的 GCC 13 默认标准是gnu++17（C++17 加 GNU 扩展），你写了c++17就明确关掉 GNU 扩展，代码更可移植。
• -Wall：开启常见警告，这不是"全部警告"的意思，而是打开一组高频、高价值的警告项。编译过程中如果代码有类型转换隐患、未使用变量等，-Wall会给你提示，建议构建脚本里永远带上它。
• -O2：优化等级二级。编译器会做循环展开、内联函数、指令调度等优化，生成的程序运行更快。调试阶段建议用-g -O0，发布阶段用-O2。

4.2 必须知道的五个编译参数

在日常开发中，除了-std、-Wall、-O2这三个基础参数，还有五个参数是绕不开的，我按使用场景分类说明。

第一个是-g，生成调试信息。它把源码行号、变量名、函数名等符号信息写入输出文件，让 GDB 调试器能告诉你"崩在第几行"。发布版本不要带它，会让文件变大、暴露源码结构；调试阶段必须带它，不然 GDB 面对的是纯汇编，排错基本靠猜。

第二个是-static-libgcc，静态链接 GCC 运行时库。MinGW-w64 编译的默认行为是动态链接libgcc_s_seh-1.dll，这个 DLL 如果你的用户机器上没有，程序会直接启动失败。加上这个参数后，GCC 运行时库会被嵌入到你的 exe 里，不再需要外部 DLL。代价是 exe 体积略微增大，但换来的是单文件可移植性。

第三个是-static-libstdc++，静态链接 C++ 标准库。作用和上面类似，把libstdc++-6.dll的部分静态嵌入。注意-static-libgcc和-static-libstdc++经常要搭配使用，它们不是替代关系，而是各管一摊。

第四个是-m64，强制要求 64 位编译。虽然你的安装包是 x86-64 的，GCC 默认也生成 64 位代码，但在某些自动化脚本里，环境变量可能被其他工具改成 32 位模式，显式加-m64是最保险的做法。反过来，如果你想交叉编译 32 位程序，需要装 32 位版本的库，再通过-m32指定。

第五个是-ID:\project\include，指定头文件搜索路径。如果你的代码#include "thirdparty.h"而这个头文件在D:\project\include目录下，编译器默认只在当前目录和系统 include 目录找，加了这个参数才能找到。Windows 环境下路径分隔符用\或/都行，但建议统一用/避免转义问题。

4.3 动态库依赖的静态链接处理

MinGW-w64 编译出来的程序，默认依赖几个运行时 DLL：libgcc_s_seh-1.dll、libstdc++-6.dll、libwinpthread-1.dll。这三个文件在你的C:\mingw64\bin目录里都有，你自己的机器上跑编译后的程序没问题，但把 exe 拷到别人机器上，如果对方没有装 MinGW-w64，程序启动时会弹"找不到 libstdc++-6.dll"或者"找不到 libwinpthread-1.dll"的错误框。

解决办法有两个方向。第一个是发布时把这三个 DLL 连同 exe 一起打包，放在同一目录下。Windows 加载 DLL 的顺序是本目录优先，所以同目录放置就能跑起来。第二个是编译时全静态链接：

g++ hello.cpp -o hello_static.exe -O2 -static

-static参数是终极方案，它把所有相关库都静态嵌入，包括libgcc、libstdc++、libwinpthread以及 C 运行时库（除了系统级的ucrtbase.dll这类不能静态化的 Windows 系统组件）。这样编译出来的 exe 在 Windows 10/11 上可以直接双击运行，不需要任何额外依赖。代价是文件体积明显增大（一个 Hello World 可能从几十 KB 涨到 1MB 以上），编译时间也会变长。

我一般的使用习惯是：开发调试阶段用动态链接（编译快、文件小），发布阶段用-static-libgcc -static-libstdc++，如果目标机器环境不可控，直接-static一锅端最放心。

5. 避坑：离线安装 MinGW-w64 最常见的 5 个坑

5.1 现象：编译通过，但运行时报"找不到 libstdc++-6.dll"

某开发者在自己机器上编译运行一切正常，把 exe 发给同事后，同事双击运行，系统弹窗提示缺少libstdc++-6.dll。这不是代码问题，是运行时依赖缺失。

原因：编译时默认采用动态链接，exe 在运行时需要加载三到四个 MinGW 运行时 DLL。开发机装了 MinGW-w64，DLL 在 PATH 里能找到；同事机器上没装，系统全局找不到这些 DLL，于是启动失败。

解决：发布 exe 给他人时，要么把三个 DLL（libstdc++-6.dll、libgcc_s_seh-1.dll、libwinpthread-1.dll或其中的实际依赖项）一起拷给同事，要么编译时加-static-libgcc -static-libstdc++减少外部依赖。如果还想连libwinpthread-1.dll也去掉，直接用-static。

5.2 现象：gcc --version显示的版本和你安装的对不上

这种情况最常见于机器上已经装过别的 GCC 工具链。比如某开发者装了x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r，但执行gcc --version显示的是gcc.exe (x86_64-win32-seh-rev1) 12.2.0。

原因：PATH 里存在多个排在前面的 MinGW 或 Cygwin 目录。where gcc的输出会告诉你所有匹配的gcc.exe路径，实际生效的是排在最前面的那一个。旧版本的 MinGW 路径可能配置在系统变量最前面，把你新装的路径挤到了后面。

解决：执行where gcc检查实际命中的路径。如果确认是旧版本抢占，把新装的C:\mingw64\bin往前挪到 PATH 列表靠前的位置，或者直接删掉旧 MinGW 的 PATH 条目。还有一种干净的做法是，在构建脚本里显式使用完整路径调用编译器，比如C:\mingw64\bin\g++.exe hello.cpp -o hello.exe，彻底绕开 PATH 查找。

5.3 现象：std::thread编译报 undefined reference topthread_create

代码写得好好的：

#include <thread> std::thread t([](){ /* ... */ });

一编译就报错，错误里能看到undefined reference to 'pthread_create'。

原因：你安装的 MinGW-w64 是win32线程模型。在这种模型下，编译器自带的 C++ 标准库没有链接 winpthreads 的 pthread 兼容层，std::thread里面的pthread_create符号找不到实现。posix 模型则额外提供了 winpthreads 库，把 POSIX 线程 API 映射到底层 Windows 线程 API，所以std::thread能正常工作。

解决：确认你的安装包线程模型字段是posix而不是win32。如果手里只有 win32 模型包，两个选择：换一个 posix 模型的包，或者代码里改用 Windows API（CreateThread、_beginthreadex）不用std::thread。在 x86-64 架构下，没有理由用 win32 模型，直接换包是最省事的。

5.4 现象：写 C 代码时snprintf编译报错，或者程序运行结果和 Visual Studio 里完全不一样

某开发者从 Visual Studio 迁移代码到 MinGW-w64 环境，发现一段格式化字符串的代码行为不一致，甚至snprintf的返回值对不上。微软的_snprintf在缓冲区不足时返回 -1，而标准 C 的snprintf返回应当写入的字符数。

原因：MSVCRT 实现的是微软自己那套 C 库语义，和标准 C 在部分函数上有差异；UCRT 则更接近标准行为。你的包如果选了ucrt字段，用的是 Universal C Runtime，它在大多数标准函数上行为正确；但如果你之前的代码是在 Visual Studio 的旧模式（MSVCRT 语义）下写的，迁移过来就要留意这种边界差异。

解决：编译时指定-std=c11（C 语言）或-std=c++17（C++），让编译器按标准模式解析代码，同时把代码里依赖微软特有行为的函数（_snprintf、_strdup）改成标准版本（snprintf、strdup）。如果代码要同时在 Visual Studio 和 MinGW 下编译，建议写一层兼容宏，按_MSC_VER和__GNUC__宏做条件编译。

5.5 现象：链接时提示skipping incompatible ...或cannot find -lxxx

当你尝试链接第三方库时，比如-lssl，GCC 提示找不到库，或者提示"跳过了不兼容的文件"。

原因：最常见的两个原因——一是库的位数不对，你用 64 位 GCC 但链接的是 32 位版.a/.lib文件；二是库的命名不符合 GCC 的查找规则，GCC 在 Windows 上默认找libname.a或libname.dll.a，如果你手头的文件叫ssl.lib（Visual Studio 风格），GCC 认不出来但能找到libssl.a。

解决：先确认库文件的位置和位数。用file命令（如果有）或者直接看库文件头部信息分辨架构。如果是 32 位库，去下载 64 位版本（对应 x86_64-w64-mingw32 目录下的库）；如果文件名带.lib后缀，在链接参数里用完整路径告诉 g++ 具体文件即可，比如：

g++ main.cpp D:\libs\ssl.lib -o main.exe

另一种情况是静态库是 GCC 风格的.a文件，需要把文件命名为libxxx.a才能用-lxxx找到，或者直接把整个.a文件路径写入链接命令，和上面的方式一样。

6. 进阶：把离线工具链变成工程化的编译环境

跑通单个.cpp只是开始，日常开发里你会有几十个源文件，每次手敲 g++ 命令不现实。我一般会为每个项目写一个 Makefile，把编译参数固化下来，这样团队内所有人都用同一套构建规则。一个最小可用的 Makefile 长这样：

CXX = g++ CXXFLAGS = -std=c++17 -Wall -O2 -g LDFLAGS = -static-libgcc -static-libstdc++ SOURCES = $(wildcard *.cpp) OBJECTS = $(SOURCES:.cpp=.o) app.exe: $(OBJECTS) $(CXX) $(OBJECTS) -o app.exe $(LDFLAGS) %.o: %.cpp $(CXX) $(CXXFLAGS) -c $< -o $@ clean: del /Q *.o app.exe

这个 Makefile 里的$(wildcard *.cpp)会自动收集当前目录所有.cpp文件，每个文件编译成.o目标文件，最后链接为app.exe。clean任务用于清理中间产物，Windows 下用del /Q（如果用 MinGW 自带的环境，mingw32-make会调用 cmd 作为 shell）。调用方式是mingw32-make app.exe，注意 MinGW 的 make 命令不叫make，而是mingw32-make，这是为了和 Visual Studio 自带的 nmake 区分。

在生产环境使用这套工具链时，还要养成固定验证的习惯：每换一个新版本包，执行一次版本确认和编译冒烟测试，把输出记录到构建日志里。这个习惯帮我抓出过好几次环境变量被篡改、工具链被替换导致的诡异问题。另外，建议把C:\mingw64\bin这个 PATH 条目写到团队的开发环境文档里，让每个人装的版本一致、配置一致、构建参数一致。我自己的经验是：离线包本身不等同于环境就绪，真正值钱的是把包、PATH、编译参数这三件事一并锁定下来，形成团队可复制的开发基线。希望今天的这些拆解和踩坑记录能帮到你，让你的 Windows 下 C/C++ 编译环境少折腾几轮。

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