Windows下std::ifstream用窄字符串开中文路径必失败，因底层调用ANSI API将UTF-8字节误作GBK解码；唯一可靠方案是改用std::wifstream配合std::wstring宽字符路径（如L"./数据/测试.txt"）。
std::ifstream 用窄字符串打开含中文路径时直接失败
Windows 下用 std::ifstream 传入 UTF-8 编码的 std::string 路径（比如 "./数据/测试.txt"），大概率返回 failbit —— 不是文件不存在，而是系统根本没正确解析路径。C++ 标准库的窄字符流在 Windows 上默认走 ANSI API（CreateFileA），会把 UTF-8 字节序列当成本地编码（通常是 GBK）去解码，一遇到非 ASCII 中文就乱码，路径无效。
- 确认是否真失败：打开后立刻检查
ifs.is_open()或!ifs，别只看ifs.fail()，因为构造失败时状态位可能未完全设置 - 临时验证法：把路径改成纯英文（如
"./data/test.txt"），如果能开，基本锁定是中文路径问题 - 不要尝试用
SetConsoleOutputCP(CP_UTF8)或修改控制台代码页——这不影响文件 API 的底层行为
Windows 上唯一可靠方案：用 std::wifstream + 宽字符路径
必须把路径转成 std::wstring，再用 std::wifstream 打开。Windows 的宽字符 API（CreateFileW）原生支持 UTF-16，能准确表示任意中文路径。
- 路径来源是硬编码：直接写 L 前缀，如
L"./数据/测试.txt" - 路径来自用户输入或 JSON 等外部源（UTF-8 字节流）：用
MultiByteToWideChar(CP_UTF8, ...)转换，别用std::mbstowcs——它依赖 locale，Windows 下默认 locale 不保证是 UTF-8 - 注意
std::wifstream默认不支持 UTF-8 BOM 检测，如果文件本身是 UTF-8 编码且含 BOM，需手动跳过或用imbue设置 codecvt（但已弃用），更稳的做法是先用宽字符流读，再按需转码内容
std::wstring wpath = L"./数据/测试.txt";
std::wifstream wifs(wpath);
if (!wifs.is_open()) {
// 处理错误，比如 GetLastError()
}
跨平台项目别硬写 wifstream：封装路径抽象层
Linux/macOS 的 std::ifstream 用 UTF-8 路径是 OK 的，但 Windows 不行。如果代码要同时编译，不能简单 #ifdef 切换流类型——因为 std::ifstream 和 std::wifstream 接口不完全兼容（比如 getline 参数类型不同）。
- 最简隔离：所有路径统一存为
std::string（UTF-8），仅在真正调用 open 前做平台判断转换，Windows 下转std::wstring后进wifstream，其他平台直传std::string - 避免用
std::filesystem::path的c_str()直接喂给std::ifstream——它的窄字符输出在 Windows 上仍是 ANSI 编码，不是 UTF-8 - 第三方库如 Boost.Nowide 可提供统一的
boost::nowide::ifstream，内部自动处理，但引入依赖需权衡
std::filesystem::open_file 为什么也不行？
C++17 的 std::filesystem::ifstream 构造函数（接受 std::filesystem::path）看似能解题，但它在 MSVC 实现中，对窄字符串路径仍调用 ANSI 版本 API。即使你传入的是 UTF-8 编码的 std::string，MSVC 的 libstdc++/libc++ 也尚未完全实现跨平台 UTF-8 路径语义。
立即学习“C++免费学习笔记（深入）”；
- 实测：MSVC 19.3x 下
std::filesystem::path("数据.txt").string()返回的仍是 ANSI 编码字节，不是原始 UTF-8 - Clang/LLVM libc++ 在 Windows 上表现略好，但仍建议以
wstring为准，别依赖标准库的“自动转换” - 如果你已在用
std::filesystem，至少确保 path 对象由宽字符构造：std::filesystem::path p(L"数据.txt")，再用其wstring()方法取值
