Windows下std::ifstream传UTF-8字符串打开中文路径必失败，因底层调用CreateFileA将UTF-8字节误作GBK解码；唯一可靠方案是改用std::wifstream配合std::wstring宽字符路径（如L"./数据/测试.txt”）。
Windows 下用 std::ifstream 打开含中文、Emoji 或长路径的文件，十有八九失败——不是文件不存在，而是路径根本没被系统正确识别。根本原因在于：MSVC 的窄字符流默认调用 CreateFileA，把 UTF-8 字节当 GBK 解码，一碰到非 ASCII 就乱码截断。唯一可靠路径是全程走宽字符（wchar_t）+ CreateFileW。
为什么 std::ifstream 传 UTF-8 string 必然失败
Windows API 分 A/W 两套：CreateFileA 只收 char*，内部按当前 ANSI 代码页（如 CP936）解释字节；你传 "./数据/测试.txt" 这个 UTF-8 字符串，它会把 0xE6 0x95 0xB0 当成三个独立 GBK 字节去解析，结果路径无效。即使源文件保存为 UTF-8 with BOM，字面量仍是窄字符串，编译器不会自动转码。
-
std::ifstream构造后立即检查ifs.is_open()，别只看failbit——构造失败时状态位可能未更新 - 临时验证：把路径改成纯英文（如
"./data/test.txt"），能开就基本锁定是编码问题 - 改控制台代码页（如
SetConsoleOutputCP(CP_UTF8)）完全无效——它不影响文件 API 底层行为
std::wifstream + std::wstring 是唯一可靠组合
Windows 原生支持 UTF-16 路径，CreateFileW 直接接收 wchar_t*，无解码歧义。C++ 标准库中对应的是 std::wifstream 和 std::wstring。
- 硬编码路径：直接写
L"./数据/测试.txt"，前缀L强制生成wchar_t[] - 外部来源（如 JSON、命令行）：必须用
MultiByteToWideChar(CP_UTF8, ...)转换，std::mbstowcs依赖 locale，在 Windows 默认 locale 下大概率崩 - 别用
std::filesystem::path("xxx").c_str()喂给std::ifstream——它的窄字符输出在 Windows 上是 ANSI 编码，不是 UTF-8
超长路径（>260 字符）必须加 L"\\?\\" 前缀
Windows 默认限制 MAX_PATH=260，超过就报 ERROR_PATH_NOT_FOUND，哪怕路径真实存在。绕过方案是给绝对路径加 ? 前缀（注意是 4 个反斜杠 + ? + 2 个反斜杠），且仅对绝对路径有效。
立即学习“C++免费学习笔记（深入）”；
- 先用
std::filesystem::absolute(path)转绝对路径，再拼接：L"\\?\" + abs_path.native() - 相对路径不支持该前缀；含
.或..的路径需先std::filesystem::canonical规范化 - 拼好后传给
std::wifstream，不要用.string()取回——std::filesystem::path会自动剥离\?
跨平台项目怎么封装才不踩坑
Linux/macOS 的 std::ifstream 天然支持 UTF-8 路径，但 Windows 不行；不能简单 #ifdef _WIN32 切换流类型——std::ifstream 和 std::wifstream 接口不兼容（如 getline 参数类型不同）。
- 所有路径统一存为
std::string（UTF-8 编码），仅在真正调用open()前做平台判断转换 - Windows 下转
std::wstring后进std::wifstream，其他平台直传std::string - 剪切板路径、长路径等特殊场景，优先用
std::filesystem::path构造宽路径：std::wfstream f(std::filesystem::path(L"\\?\C:\..."))，避免隐式转换丢失 Unicode
最易忽略的一点：宽字符流（std::wifstream）读文本时默认不处理 BOM，也不自动转码内容。如果文件是 UTF-8 编码且带 BOM，它会把 0xEF 0xBB 0xBF 当作三个 wchar_t 读进来——得手动跳过或用二进制模式读，再按需解码。别指望 imbue 配 codecvt_utf8，它在 C++17 已弃用，且 MSVC 早已不维护。
