最稳的解决方式是使用纯ascii路径，如d:devhello；避免中文路径可彻底绕过mingw-w64 gcc 12及之前版本对utf-8中文路径解析不稳定的问题。
g++ 在 Windows 上遇到中文路径（比如用户名含中文、项目路径含中文）时，常报错：
-
cc1plus.exe: fatal error: opening dependency file xxx: Invalid argument - 或编译中途卡住、生成空目标文件、
internal compiler error
根本原因不是编码本身不支持，而是 MinGW-w64 的 GCC 早期版本（尤其 GCC 12 及之前）对 Windows 路径中 UTF-8 编码的中文处理不稳定 —— 它依赖系统 locale，而 Windows 控制台默认是 GBK，GCC 内部又按 UTF-8 解析，一来一回就乱码。
为什么改环境变量 LANG=C 不起作用
有人试过在终端里执行 set LANG=C 或 $env:LANG="C"，但无效。因为 MinGW-w64 的 GCC 并不读取 LANG，它依赖的是 Windows 的 GetACP()（ANSI code page）和内部对命令行参数的宽字符转换逻辑。PowerShell/cmd 传入的路径字符串一旦含中文，GCC 某些阶段（尤其是预处理写 .d 依赖文件时）会直接截断或解析失败。
最稳的解决方式：用短路径 + ASCII 路径
这不是妥协，而是 MinGW-w64 官方推荐做法（见 MSYS2 文档）。Windows 支持 8.3 短名，只要路径本身不含空格、中文、特殊符号，就能彻底绕过问题：
- 把项目移到纯 ASCII 路径下，例如：
D:devhello、C:cpp est - 避免使用 OneDrive、WeChat Files、桌面等默认含中文用户名的路径
- 若必须在用户目录开发，可用
mklink /D建硬链接到短路径（如mklink /D D:proj C:Users张三Documentsmycpp），再在D:proj下操作 - VS Code 中打开文件夹时，务必确认左下角显示的是短路径（不是
\?C:...或含中文的绝对路径）
临时补救：加 -finput-charset=UTF-8 和 -fexec-charset=GBK
仅适用于 GCC 13+（MSYS2 UCRT64 默认带），且只缓解部分场景（比如源码里有中文字符串），**不能解决路径本身的乱码问题**：
g++ -finput-charset=UTF-8 -fexec-charset=GBK hello.cpp -o hello.exe- 这个组合告诉编译器：源文件按 UTF-8 读，字符串字面量按 GBK 编码进可执行文件
- 但它对
#include "中文头.h"或输出依赖文件路径无效 —— 那些路径由 GCC 内部拼接，不受 charset 参数控制
VS Code 用户特别注意 c_cpp_properties.json 的 includePath
即使编译能过，IntelliSense 仍可能报 cannot open source file "xxx"，因为 c_cpp_properties.json 里的 includePath 若含中文路径，C/C++ 扩展会解析失败：
- 检查
.vscode/c_cpp_properties.json，确保所有includePath条目都是 ASCII 路径 - 不要写成：
"${workspaceFolder}/第三方库/utf8-header" - 应改为：
"D:/libs/utf8-header"或用 MSYS2 提供的 POSIX 路径映射（如/mingw64/include） - 如果用了 WSL 工具链，路径需转为 Linux 格式，且 VS Code Remote 必须连上 WSL 实例
真正卡住人的从来不是“能不能编译”，而是“为什么有时候行、有时候不行”。路径含中文时，g++ 行为高度依赖当前 shell 类型（cmd/PowerShell/MSYS2 terminal）、GCC 版本、是否启用 PCH、甚至临时文件磁盘的 NTFS 属性 —— 最省事的办法，就是从一开始就不让它碰到中文。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
