应使用llvm-mingw工具链而非手动配置clang+mingw-w64，因其已预置头文件、crt和链接器，避免msvcrt/ucrt混用、栈检查函数缺失、运行时依赖及win7兼容性问题。
直接用 llvm-mingw 工具链，别自己从头配 Clang + MinGW-w64 头文件 + LLD 链接器——90% 的失败都源于手动拼凑路径或混用运行时（MSVCRT vs UCRT）。
为什么不用 clang -target x86_64-pc-windows-msvc？
因为那是给 MSVC ABI 用的，生成的二进制依赖 vcruntime140.dll 等 VC 运行时；而 MinGW 程序目标是零依赖、静态链接、调用 Windows API 直接走 kernel32.dll。用错 target 会导致：
-
undefined reference to `__chkstk_ms'—— MSVC 栈检查函数，MinGW 不提供 - 链接时找不到
libucrt.lib或报LNK1181: cannot open input file 'ucrt.lib' - 即使编译通过，exe 在无 VC 运行时的 Win7/Server 上直接闪退
x86_64-w64-mingw32-clang 的实际用法
这是 llvm-mingw 提供的标准前缀，它已预置好头文件路径、默认链接 mingw-w64 CRT 和 winpthreads，无需额外 -I 或 -L。
- 编译 C 文件：
x86_64-w64-mingw32-clang hello.c -o hello.exe - 启用 C++ 支持：
x86_64-w64-mingw32-clang++ main.cpp -o app.exe - 静态链接所有依赖（推荐）：
x86_64-w64-mingw32-clang hello.c -static -static-libgcc -static-libstdc++ -o hello.exe - 若需 Unicode 控制台支持，加
-municode，否则wprintf可能乱码
常见环境变量和 PATH 冲突点
最容易出问题的是 PATH 中混入了其他 MinGW（如 MSYS2 自带的 gcc）或旧版 LLVM，导致命令被错误解析。
- 执行
which x86_64-w64-mingw32-clang（Linux/macOS）或where x86_64-w64-mingw32-clang（Windows PowerShell）确认来源路径是否属于你解压的llvm-mingw目录 - 不要把
/usr/bin或msys64/mingw64/bin放在llvm-mingw/bin前面 - Windows 下若用 Git Bash，确保
export PATH="/d/llvm-mingw-w64/bin:$PATH"生效，且没被 Windows 的%PATH%覆盖 - 验证 CRT 类型：
x86_64-w64-mingw32-clang -v hello.c 2>&1 | grep "thread-model\|crt"，应看到thread-model: posix和crt2.o路径指向llvm-mingw自带目录
真正麻烦的不是编译命令本身，而是运行时行为差异：比如 fopen("中文.txt", "r") 在 UCRT 下可用，在老版 MSVCRT 下会失败；又比如 std::filesystem 在 LLVM 15+ 才完整支持 MinGW。这些细节不跑起来根本看不出问题。
