簡介這是一份 MinGW-w64 的 64 位離線安裝包版本為 x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r核心編譯器為 GCC 13.1.0面向需要在 Windows x64 環(huán)境下進行 C/C 原生開發(fā)的程序員。整個壓縮包為 7z 格式共 18725 個文件包含編譯工具鏈、頭文件、鏈接庫與文檔主要文件類型包括 gcc/g 等可執(zhí)行文件、dll 動態(tài)庫、a 靜態(tài)庫、h/hpp 頭文件以及 HTML 格式的 GCC 配套文檔另有部分 Python 輔助腳本整體大小約 68.89MB。由于采用離線打包安裝過程中不依賴網(wǎng)絡(luò)適合內(nèi)網(wǎng)或網(wǎng)絡(luò)不穩(wěn)的機器快速部署。選擇 posix-seh-ucrt 線程模型與運行時組合兼容性較好可支持最新的 C/C 語言特性和標(biāo)準(zhǔn)庫。已有 1637 人學(xué)習(xí)下載適合需要搭建本地編譯環(huán)境或進行跨平臺 Windows 開發(fā)的讀者。開頭第一次看到x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r這串文件名估計不少人都是一臉懵這到底是壓縮包密碼還是哪個發(fā)行版的代號其實它是一個非常標(biāo)準(zhǔn)的 MinGW-w64 編譯器構(gòu)建版本標(biāo)識每一個用連字符分隔的字段都在告訴你這個編譯器是給什么架構(gòu)用的、用哪套線程模型、異常處理怎么做、鏈接哪個運行庫。把這段字符串讀懂了你就理解了 MinGW-w64 整個工具鏈的設(shè)計取舍也就能明白為什么有些 C/C 項目在 Windows 上必須用它來編譯而不是直接裝個 Visual Studio 了事。這篇文章就用這個具體的離線安裝包做線索把 MinGW-w64 的版本命名規(guī)則、離線包的獲取與校驗、環(huán)境配置、和 MSVC 的差異以及我實際用下來踩過的幾個坑一次性講清楚。無論你是要在內(nèi)網(wǎng)離線環(huán)境搭一套 C/C 編譯工具鏈還是剛準(zhǔn)備把項目從 Visual Studio 遷到開源工具鏈又或者只是想搞清楚posix、seh、ucrt這幾個詞到底意味著什么這篇都適合讀。1. 版本串逐段拆解x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r里每段都代表一次取舍1.1 x86-64不只是64位安裝包很多人一看x86-64就說哦64位版本嚴(yán)格來說不完整。x86-64描述的是目標(biāo) CPU 架構(gòu)和 ABIApplication Binary Interface它既包括 64 位通用寄存器和指針寬度也包括函數(shù)調(diào)用約定、結(jié)構(gòu)體內(nèi)存布局這些底層規(guī)范。在 MinGW-w64 的世界里和x86-64相對的另一個常見前綴是i686后者是 32 位構(gòu)建。選擇x86-64意味著你編譯出來的.exe或.dll只能在 64 位 Windows 上運行且默認(rèn)啟用 64 位指令集擴展。這比 32 位版本多出的不只是能用更多內(nèi)存這么簡單很多加密、音視頻處理、科學(xué)計算代碼在 64 位下能拿到更快的寄存器操作和更好的浮點性能。如果你的目標(biāo)機器全是 64 位 Windows就不要猶豫直接選這個。1.2 13.1.0GCC 版本號的演進邏輯13.1.0是 GCCGNU Compiler Collection的版本號。GCC 是大版本號 小版本號 修訂號的命名方式13表示這是 GCC 13 系列1是第一個特性更新.0是補丁級別。GCC 13 對 C 標(biāo)準(zhǔn)的支持已經(jīng)相當(dāng)完整默認(rèn)情況下g會以-stdgnu17作為默認(rèn)標(biāo)準(zhǔn)同時完整支持 C20 的大部分特性包括模塊modules的初步實現(xiàn)、std::format、std::ranges的相關(guān)組件等。如果你在寫現(xiàn)代 C或者要編譯一些要求較高標(biāo)準(zhǔn)版本的第三方庫選擇 13 以上的版本會省掉很多因為語言特性不夠而編譯失敗的麻煩。需要注意的是13.1.0是2023 年上半年左右的版本。電子產(chǎn)品的世界里沒有最新只有更新但編譯器這行穩(wěn)定性和兼容性往往比追新更重要。13.x 這個版本線目前已經(jīng)被大量開源項目驗證過對 MSVC 兼容性、對常見第三方庫的支持都趨于成熟拿來作為離線環(huán)境的固定工具鏈非常合適。1.3 posix vs win32線程模型的路線之爭這個是版本串里最需要花時間理解的部分。MinGW-w64 官方構(gòu)建提供兩套線程模型posix和win32。win32 線程模型直接使用 Windows API 的CreateThread等底層接口作為線程實現(xiàn)編譯出的程序不依賴額外的線程支持庫體積更小。但它對 C11 標(biāo)準(zhǔn)庫中的thread、mutex、future等線程設(shè)施支持得不好std::thread可能根本無法正常工作。posix 線程模型在 Windows 線程之上實現(xiàn)了一層 POSIX 線程接口基于 winpthreads 庫讓 GCC 可以完整支持 C 標(biāo)準(zhǔn)線程庫也兼容 OpenMP、以及大量假設(shè)線程行為符合 POSIX 規(guī)范的第三方庫。如果你打算寫 C 多線程代碼或者要編譯的庫內(nèi)部用到std::thread、pthread_*接口那必須選posix版本。這就是為什么很多開源庫的 Windows 構(gòu)建說明里會特意寫上請使用 posix 線程模型。有一點要提前說清楚posix線程模型在運行時可能需要額外的一個動態(tài)庫libwinpthread-1.dll。后面部署到目標(biāo)機器時要么把它一起復(fù)制過去要么在編譯時加-static-libgcc -static-libstdc把相關(guān)庫靜態(tài)鏈進可執(zhí)行文件不然會出現(xiàn)找不到 libwinpthread-1.dll的經(jīng)典報錯。1.4 seh vs sjlj vs dw2異常處理機制異常處理機制這欄在 64 位構(gòu)建里基本都是seh32 位才常見sjlj或dwarf。它們的區(qū)別本質(zhì)上是當(dāng)程序拋出異常時運行時如何找到對應(yīng)的 catch 塊并展開調(diào)用棧。SEHStructured Exception HandlingWindows 原生結(jié)構(gòu)化異常處理機制由操作系統(tǒng)和編譯器協(xié)同處理。在 x86-64 上SEH 使用基于表的 unwind 信息異常拋出和捕獲的開銷非常低幾乎沒有額外的運行時成本。SJLJsetjmp/longjmp通過跳轉(zhuǎn)表記錄可能拋異常的代碼位置。優(yōu)點是兼容性強缺點是每次進入可能拋異常的代碼塊都要保存現(xiàn)場性能損失明顯。DWARF基于 DWARF 調(diào)試信息里的展開表性能和 SEH 接近但通常只用于 32 位且對第三方庫的交互要求更嚴(yán)格。選擇seh意味著你拿到了異常處理性能最好的那條路徑。在 64 位 Windows 下這基本沒有爭議除非你需要支持非常古老的系統(tǒng)或者特殊調(diào)試場景。1.5 ucrt運行庫的兼容性關(guān)鍵ucrt是 Universal C Runtime 的縮寫這是微軟從 Windows 10 開始把 C 標(biāo)準(zhǔn)運行庫拆出來的一個系統(tǒng)組件。在老一點的 MinGW-w64 構(gòu)建里你經(jīng)常會看到msvcrt這個標(biāo)記它對應(yīng)的是從 Windows 98 時代一路繼承下來的老式 C 運行庫。ucrt對比msvcrt最大的優(yōu)勢在于C99 和 C11 的標(biāo)準(zhǔn)函數(shù)支持更完整比如stdio.h里很多老庫缺失的函數(shù)、snprintf、strtok_s這類安全版本接口都能正常使用。另一個更關(guān)鍵的點是UCRT 是 Windows 系統(tǒng)自帶的組件MSVC 編譯器默認(rèn)也鏈接到 UCRT。這意味著使用ucrt構(gòu)建的 MinGW-w64 程序在調(diào)用系統(tǒng) API、處理標(biāo)準(zhǔn)輸入輸出、對接 MSVC 編譯的庫文件時底層運行庫是一致的二進制兼容性更好。代價是如果你的目標(biāo)系統(tǒng)是 Windows 7 且沒有安裝相應(yīng)的 UCRT 系統(tǒng)更新程序可能跑不起來。在今天這個時間點絕大多數(shù)場景下都應(yīng)該優(yōu)先選ucrt不要再守著msvcrt了。1.6 rt-v11-r構(gòu)建環(huán)境的版本信息最后這一段rt-v11-r最容易被忽略但它其實記錄了 MinGW-w64 構(gòu)建環(huán)境的版本。rt-v11是 MinGW-w64 源碼樹的一個構(gòu)建標(biāo)簽r代表 revision修訂版后面的數(shù)字是具體修訂號。它相當(dāng)于告訴你這個編譯器是用 MinGW-w64 哪個版本的源碼和構(gòu)建腳本打包出來的。MinGW-w64 本身不是一個編譯器而是一套讓 GCC 能生成 Windows 可執(zhí)行文件的頭文件和導(dǎo)入庫集合。所以同樣的 GCC 13.1.0配不同版本的 MinGW-w64 運行時源碼生成的二進制在兼容性上會有細微差別。日常使用中你不需要記住每個rt版本對應(yīng)什么只需要知道如果某個第三方庫要求MinGW-w64 至少是 rt-v10 或更高那這個rt-v11就是滿足條件的。2. 為什么非得用離線包在線安裝器的痛內(nèi)網(wǎng)環(huán)境的需求2.1 在線安裝器的問題出在哪很多剛接觸 MinGW-w64 的人第一反應(yīng)是去官網(wǎng)找個 exe 安裝器。這個想法本身沒錯早期的 MinGW-w64 也確實提供過圖形化安裝器可以勾選組件在線下載。但這個方案實際用起來并不省心第一在線安裝器需要從多個遠程源拉取大量零散包服務(wù)器在國外的話下載速度很不可控經(jīng)常是某個包下到一半就斷掉然后安裝器陷入重試-失敗-重試的死循環(huán)。第二企業(yè)內(nèi)網(wǎng)安全策略通常會攔截這種安裝器運行時才去下載一堆可執(zhí)行文件的行為最終結(jié)果就是安裝器能啟動但一個包都拉不下來。第三在線安裝器每次裝的組件版本是當(dāng)前時間點的最新版換個時間換個機器再裝一次得到的工具鏈版本可能就不一樣了這在需要穩(wěn)定復(fù)現(xiàn)構(gòu)建的環(huán)境里是災(zāi)難。所以我現(xiàn)在養(yǎng)成的習(xí)慣是不碰任何在線安裝器直接下載一個完整的離線包。2.2 離線包到底適合哪些場景離線安裝包最適合這樣幾類場景隔離內(nèi)網(wǎng)環(huán)境。物理斷網(wǎng)或者出口受控的研發(fā)網(wǎng)里想裝編譯器唯一的辦法就是把安裝包拷貝進去。構(gòu)建環(huán)境標(biāo)準(zhǔn)化。團隊里所有 CI 節(jié)點、同事電腦全用同一個版本的編譯器避免我這邊能編你那邊編不了的扯皮。反復(fù)部署。一次下載拷貝給十臺機器每臺解壓配置哪怕其中八臺沒外網(wǎng)也能用。應(yīng)急修復(fù)。生產(chǎn)服務(wù)器上程序崩潰需要編譯一個帶日志的修復(fù)版本不想在那臺機器上裝全家桶 IDE只想丟一個干凈的gcc.exe進去用。2.3 如何選擇具體的構(gòu)建版本選離線包的核心原則是在滿足需求的前提下盡量選 release 版本、選較新的大版本號、選posix線程模型、選seh、選ucrt。像標(biāo)題里這個x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r就是一條非常標(biāo)準(zhǔn)的推薦組合。release說明它是正式發(fā)布版不是每天自動構(gòu)建的 snapshotposix保證標(biāo)準(zhǔn)線程庫可用seh保證異常性能ucrt保證運行庫現(xiàn)代且與 MSVC 兼容。這幾個條件同時滿足基本能覆蓋 95% 以上的日常 C/C Windows 開發(fā)需求。3. 離線包獲取、校驗與部署的完整操作清單3.1 獲取渠道和文件識別獲取離線包第一優(yōu)先是去 MinGW-w64 項目官方的發(fā)布頁面或者從被廣泛認(rèn)可的第三方分發(fā)站點比如 winlibs.com 這類專門做 MinGW-w64 構(gòu)建的站點獲取。下載前先看文件名確保它是編譯器構(gòu)建包而不是源碼包。通常離線包是一個.7z壓縮文件解壓后的根目錄下至少能看到bin、lib、include、libexec這些文件夾bin里有g(shù)cc.exe、g.exe、gdb.exe這些可執(zhí)行文件。有時候你會看到文件名里多出win32或者dwarf后綴那是另一種線程模型或異常處理方式的構(gòu)建如果沒特別需求就繞開直接選本文標(biāo)題這種標(biāo)準(zhǔn)組合最穩(wěn)妥。3.2 下載后先做校驗別急著解壓離線包在網(wǎng)絡(luò)上傳播哪怕是從看起來很可靠的渠道下載也有被中間人篡改的微小可能。編譯器一旦被植入后門你用它編譯的任何產(chǎn)品都會帶上惡意代碼這是最可怕的一種供應(yīng)鏈攻擊。所以拿到壓縮包后第一步就是校驗哈希。Windows 下用 PowerShell 執(zhí)行Get-FileHash .\x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r.7z -Algorithm SHA256然后在發(fā)布頁面找到官方的 SHA256 校驗值或者.sha256文件逐個字符對比。如果對不上寧可重新下載也不要解壓特別是當(dāng)你準(zhǔn)備把編譯產(chǎn)物交付給別人或者部署到生產(chǎn)環(huán)境時這一步絕對不能省。3.3 解壓部署路徑問題第一課解壓這一步我強烈建議你遵守一個原則路徑不要有空格和中文越簡單越好。比如解壓到C:\mingw64得到C:\mingw64\bin\gcc.exe這樣的結(jié)構(gòu)。不要解壓到C:\Program Files\MinGW-w64這種目錄。雖然現(xiàn)代 GCC 已經(jīng)比早年容忍空格了但在 CMake、Ninja 等構(gòu)建系統(tǒng)里帶空格的路徑依然會時不時引爆一些奇怪的解析問題。為一個工具鏈去趟這種渾水完全不值得。解壓完成后可以檢查一下C:\mingw64\bin下應(yīng)該能看到gcc.exe、g.exe、mingw32-make.exe、gdb.exe等。如果這些文件都在說明包基本完整。有些構(gòu)建版本還帶了libwinpthread-1.dll和libstdc-6.dll這些動態(tài)庫也在這個目錄下運行時需要它們就在旁邊。4. 從命令行到 IDE環(huán)境變量配置與首次編譯驗證4.1 配置 PATH 環(huán)境變量編譯器解壓好后要讓系統(tǒng)能找到它核心就是配置 PATH 環(huán)境變量。右鍵此電腦→屬性→高級系統(tǒng)設(shè)置→環(huán)境變量在系統(tǒng)變量里找到Path編輯并新增一行C:\mingw64\bin。如果只是想在當(dāng)前命令行會話里臨時測試也可以用set PATHC:\mingw64\bin;%PATH%還有一種方法是直接寫入用戶級 PATH用setxsetx PATH C:\mingw64\bin;%PATH%注意setx的坑它會把當(dāng)前%PATH%展開后的完整值直接寫死到注冊表如果當(dāng)前 PATH 里帶了臨時路徑會把臨時路徑也永久固化進去。所以我一般推薦用系統(tǒng)環(huán)境變量圖形界面來改穩(wěn)妥可控。4.2 第一次編譯冒煙測試配置完 PATH新開一個終端setx之后必須要開新終端才生效驗證一下gcc --version g --version如果輸出里能看到gcc.exe (MinGW-W64 ...) 13.1.0這樣的字樣說明編譯器已經(jīng)正常工作了。接著寫一個最小的 C 程序測試編譯流程#include iostream #include thread int main() { std::thread t([] { std::cout hello from thread std::endl; }); t.join(); std::cout hello mingw std::endl; return 0; }使用thread頭文件是檢驗posix線程模型是否正常的最直接方法。如果你的編譯器是win32線程模型編譯這行代碼很可能報錯或者鏈接失敗。把下面的命令敲進去g -stdc17 -O2 test.cpp -o test.exe如果沒有任何警告錯誤test.exe能正常輸出兩行文本那這套 MinGW-w64 工具鏈的核心部分就已經(jīng)完全可用了。4.3 接入 VSCode 和 CMake絕大多數(shù)人不會只停在命令行接下來會把它接進 VS Code 或 CLion。在 VS Code 里安裝 C/C 插件后在.vscode/c_cpp_properties.json里指定{ configurations: [ { name: MinGW, compilerPath: C:/mingw64/bin/g.exe, cStandard: c17, cppStandard: c17, intelliSenseMode: windows-gcc-x64 } ] }如果是用 CMake 構(gòu)建在 CMakeLists.txt 旁邊執(zhí)行cmake -S . -B build -G MinGW Makefiles -DCMAKE_C_COMPILERgcc -DCMAKE_CXX_COMPILERgMinGW Makefiles生成器會讓 CMake 調(diào)用 MinGW 自帶的mingw32-make這是 Windows 下最推薦的方式。也可以用-G Ninja前提是你單獨裝好了 Ninja。4.4 完整工具鏈的自檢清單新環(huán)境配置完我習(xí)慣跑一遍這個自檢流程確認(rèn)工具鏈沒有隱藏問題gcc --version確認(rèn)版本號是 13.1.0且輸出里帶posix字樣。編譯一個使用thread的程序確認(rèn)線程庫可用。編譯一個調(diào)用printf并snprintf的程序確認(rèn) UCRT 的運行時函數(shù)正常。運行g(shù)endef或dlltool在bin目錄里確認(rèn) MinGW-w64 的輔助工具都在。只要這四條通過就說明這個離線包沒白下后面可以放心寫業(yè)務(wù)代碼了。5. MinGW-w64 與 MSVC 的差異都是 Windows 編譯器差別比想象中大5.1 為什么開源項目偏愛 MinGW很多從 Visual Studio 轉(zhuǎn)過來的開發(fā)者第一眼看到 MinGW-w64 會很不適應(yīng)沒有.sln項目文件沒有 IntelliSense連 Release/Debug 的配置都是 makefile 或 CMake 里的參數(shù)。但開源社區(qū)偏偏大量使用 MinGW原因很現(xiàn)實第一它是一套完整的開源工具鏈沒有許可證和授權(quán)成本。第二它和 Linux 下的 GCC 工具鏈?zhǔn)褂梅绞綆缀跻恢峦粋€ CMakeLists.txt 在 Linux 和 Windows 下都能跑跨平臺維護成本低。第三很多開源庫FFmpeg、libcurl、OpenSSL 等的 Windows 官方預(yù)編譯包用的就是 MinGW-w64 工具鏈你拿到源碼自己編也能輕松對齊。5.2 底層差異對照我整理了一張表把兩邊核心差異列出來方便大家對照對比維度MinGW-w64MSVC底層編譯器GCCcl.exeC 標(biāo)準(zhǔn)庫libstdcMicrosoft STL運行庫UCRT / msvcrtUCRT默認(rèn)調(diào)試器GDBVisual Studio Debugger構(gòu)建系統(tǒng)Make/Ninja/CMakeMSBuild/CMake二進制兼容與 MSVC 不互通與 MinGW 不互通異常處理SEH/SJLJ/DWARFSEH許可證GPL/公共許可商業(yè)授權(quán)附帶免費社區(qū)版最關(guān)鍵的是二進制兼容性這一行。MSVC 編譯出的.lib與 MinGW-w64 編譯出的.a并不能直接互相鏈接因為兩者的 C ABI名稱修飾規(guī)則、異常處理元數(shù)據(jù)、結(jié)構(gòu)體布局細節(jié)完全不同。同一個第三方庫用 MSVC 編一份、用 MinGW 再編一份是常有的事。這也是為什么很多庫的發(fā)布頁面會提供x64MSVC 版和mingw-w64兩個版本的預(yù)編譯包。5.3 什么時候我應(yīng)該用哪個我的經(jīng)驗是如果你要維護 Windows 獨占的商業(yè)項目深度依賴 Visual Studio 的調(diào)試器、性能分析器、IntelliSense那繼續(xù)用 MSVC 就好。如果項目本來就在 Linux 下用 GCC 構(gòu)建只需要額外產(chǎn)出一份 Windows 版本那 MinGW-w64 是成本最低的選擇CMake 一套配置兩邊復(fù)用。如果要編譯和開源生態(tài)強綁定的庫比如從源碼構(gòu)建 FFmpeg、Boost、Qt開源版MinGW-w64 通常比 MSVC 省事因為開源社區(qū)的腳本默認(rèn)圍繞 GCC 寫。6. 使用離線 MinGW-w64 編譯時的幾個真實教訓(xùn)6.1 CRT 不匹配導(dǎo)致的只可意會的編譯錯誤ucrt版本默認(rèn)鏈接到 Windows 系統(tǒng)自帶的 Universal C Runtime。如果目標(biāo)機器是 Windows 7且沒裝 UCRT 更新程序在啟動時會直接報缺少 api-ms-win-crt-runtime-l1-1-0.dll之類的缺失錯誤。解決辦法是在編譯時加g -static -static-libgcc -static-libstdc把運行庫全部靜態(tài)鏈接進可執(zhí)行文件。但注意-static并不能把 UCRT 靜態(tài)鏈進去UCRT 是系統(tǒng)組件不是你能靜態(tài)打包的。如果必須跑在 Windows 7 且沒打補丁的機器上就得考慮換msvcrt構(gòu)建版本了。6.2libwinpthread-1.dll丟失的連鎖反應(yīng)使用posix線程模型編譯出的第一個程序如果直接拷到別的機器上運行最常見的報錯就是找不到 libwinpthread-1.dll。我從一開始就建議凡是準(zhǔn)備對外分發(fā)的 exe統(tǒng)一用下面這條命令編譯g -stdc17 -O2 -static-libgcc -static-libstdc main.cpp -o app.exe這樣能把 libgcc、libstdc 全靜態(tài)鏈接進去只有 winpthread 可能還得動態(tài)依賴。再保險一點直接把C:\mingw64\bin目錄下的libwinpthread-1.dll復(fù)制到 exe 同目錄雙保險。6.3 路徑空格和\vs/的折騰這點前面提過我在這里再強調(diào)一次MinGW 工具鏈里的工具大多源自 Unix 世界它們能識別/但 Windows 自帶的一些腳本、IDE 插件時不時會往配置里塞\。最穩(wěn)妥的做法是所有自定義路徑統(tǒng)一寫成正斜杠/比如C:/mingw64/bin/g.exe。不要低估一個反斜杠能讓 CMake 崩潰的破壞力這種問題排查起來特別消磨耐心。6.4 靜態(tài)編譯與殺毒軟件的親密接觸有一次我為了交付一個獨立 exe加了全部靜態(tài)鏈接參數(shù)結(jié)果編譯出的文件體積從幾百 KB 漲到好幾 MB而且目標(biāo)機器上的殺毒軟件直接報毒。原因是編譯器把異常處理表、調(diào)試符號和一堆運行庫初始化代碼都壓進去了部分安全引擎的行為檢測對這種大而全的可執(zhí)行文件比較敏感。解決辦法不是放棄靜態(tài)編譯而是注意兩點一是盡量用 release 版本且去掉調(diào)試符號二是對編譯產(chǎn)物做一次數(shù)字簽名。純內(nèi)部使用的工具還好要外發(fā)給客戶的話最好提前拿主流殺毒軟件掃一遍免得交付當(dāng)天被對方的 IT 攔下來。6.5 調(diào)試器版本和 GCC 版本要對齊最后提醒一個很多人忽略的細節(jié)MinGW-w64 的多個構(gòu)建版本雖然都帶gdb.exe但 GDB 和 GCC 的版本是兩套獨立的版本線。如果編譯器很新而 GDB 太老調(diào)試時會遇到無法讀取 DWARF 調(diào)試信息之類的問題。所以選離線包的時候不要只看 GCC 版本順手確認(rèn)一下包內(nèi) GDB 的版本。GCC 13.x 對應(yīng)的 GDB 至少應(yīng)該是 13.x 或更高調(diào)試體驗才會正常。我自己現(xiàn)在維護的工具鏈就是把這套x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r離線包解壓到C:\mingw64然后配合 VS Code 和 CMake 一起用。最省心的一個用法是先手動編譯一次最小的 C 程序確認(rèn)線程和異常都正常再用 CMake 配置整個項目。這樣即使后面遇到問題也知道是構(gòu)建腳本的問題而不是編譯器本身的問題。如果你也是第一次配置 MinGW-w64 的離線環(huán)境建議你也按這個順序走一遍比東搜一個教程西看一篇文檔要高效得多。本文還有配套的精品資源點擊獲取