应使用 _wfopen 替代 fopen 处理中文路径，因其接受 const wchar_t* 并原生支持 Windows UTF-16 路径；需将 UTF-8 路径通过 MultiByteToWideChar 等转换为宽字符串，不可直接强转 char*。
Windows 下用 fopen 打不开中文路径的文件？别硬扛，换 _wfopen
直接结论：标准 C 的 fopen 只接受窄字符串（const char*），在 Windows 上默认按系统 ANSI 代码页（如 GBK）解释路径。一旦路径含 UTF-8 编码的中文（比如 VS Code 默认保存的源文件路径），或项目在 UTF-8 环境下运行，fopen 就会把多字节序列当乱码处理，返回 nullptr。
真正该用的是 Windows 特供宽字符版：_wfopen —— 它吃 const wchar_t*，能原生对接 Windows 内部的 UTF-16 路径。
- 必须把路径转成
wchar_t字符串，不能用std::string直接强转 - 常见错误：用
std::string存 UTF-8 路径，再调_wfopen(path.c_str(), L"rb")→c_str()还是char*，类型不匹配，编译不过或静默失败 - 正确做法：用
MultiByteToWideChar(CP_UTF8, ...)或 C++11 的std::wstring_convert<:codecvt_utf8>></:codecvt_utf8>（注意后者在 C++17 已弃用，但目前仍可用） - VS2015+ 可直接用
std::filesystem::path构造宽路径后取.c_str()，前提是工程启用了 Unicode 字符集（项目属性 → 常规 → 字符集 = 使用 Unicode 字符集）
为什么 SetConsoleOutputCP(CP_UTF8) 不能解决文件打开问题
这是个高频误解：调用 SetConsoleOutputCP(CP_UTF8) 只影响 printf/wprintf 输出到控制台的编码，和文件系统 API 完全无关。Windows 文件 API（包括 CreateFileW、_wfopen）底层只认 UTF-16，不认 UTF-8。
-
SetConsoleOutputCP改的是控制台“显示”逻辑，不是“路径解析”逻辑 - 即使控制台能正常打印中文路径，
fopen("C:\中文.txt", "r")依然大概率失败，因为 CRT 库内部仍用 ANSI 版本的CreateFileA - 若强行用 UTF-8 字符串调
fopen，且系统区域设为中文，可能偶然成功（因 GBK 和 UTF-8 在 ASCII 区一致），但这纯属巧合，跨机器必崩
std::fstream 遇到中文路径怎么写才稳
C++ 标准库的 std::ifstream/std::ofstream 在 Windows 上默认走窄字符构造函数，同样踩 fopen 的坑。C++11 起支持宽字符构造函数，但需满足两个硬条件：
立即学习“C++免费学习笔记（深入）”；
- 编译器必须支持（MSVC 没问题，MinGW 需确认是否启用了 wide stream 支持）
- 传入的
std::wstring必须是合法 UTF-16，不能是 UTF-8 编码的wchar_t伪字符串 - 示例：
std::wstring wpath = L"C:\测试\data.bin";<br>std::ifstream fin(wpath, std::ios::binary); // ✅ 正确
- 错误写法：
std::string u8path = u8"C:\测试\data.bin";<br>std::wstring bad = std::wstring(u8path.begin(), u8path.end()); // ❌ 把 UTF-8 字节当 wchar_t 码点，全乱
跨平台项目里中文路径的底线方案
如果必须兼顾 Linux/macOS（它们原生支持 UTF-8 路径），又不想写两套逻辑，就放弃在路径层做宽窄转换，改用「规避策略」：
- 开发阶段统一用英文路径，CI/打包脚本生成临时英文路径映射表
- 用户侧路径输入后，立即用
GetShortPathNameW转成 8.3 格式（如C:U~1TE~1.TXT），它全是 ASCII，fopen绝对安全 - 或者干脆不碰路径：让用户选文件用
GetOpenFileNameW，它返回的就是宽字符串，直接喂给_wfopen - 注意：
std::filesystem::u8path（C++20）在 MSVC 2019+ 已支持，但底层仍调_wfopen，所以你仍得确保传入的是 UTF-8std::string，它会自动转宽字符 —— 这是最省心的现代写法，但得确认编译器版本
最麻烦的从来不是怎么转码，而是有人坚持用 char* 硬塞中文路径还怪编译器不争气。Windows 的宽字符路径机制很老，但没过时；绕开它写的兼容代码，往往比正经用 _wfopen 更容易出隐藏 bug。
