Windows下std::ofstream无法写入中文路径是因为默认调用CreateFileA，应改用std::wofstream配合UTF-16路径；Linux/macOS需确保locale为UTF-8，std::filesystem::path不自动转码，跨平台推荐用原生API或boost::nowide。
Windows 下 std::ofstream 写入中文路径直接失败？先关掉宽字符默认行为
不是编码没设对，是 C++ 标准库在 Windows 上默认用 ANSI 版本的 CreateFileA 打开文件，根本不会解析 UTF-8 或 GBK 路径。哪怕你把源文件存成 UTF-8 with BOM，std::ofstream("C:\测试\a.txt") 也会静默失败（is_open() 返回 false）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 不要依赖
setlocale(LC_ALL, "")—— 它只影响 C 风格函数（如fopen），对std::fstream无效 - Windows 上必须用宽字符接口：改用
std::wofstream，路径传std::wstring - 确保编译器支持 UTF-16 字面量：用
L"C:\测试\a.txt"，别用普通字符串硬转 - VS2015+ 默认启用
/utf-8后，仍需手动转码：从 UTF-8 字符串转std::wstring，推荐用MultiByteToWideChar(CP_UTF8, ...)或跨平台库如std::from_chars（C++20）不适用此处
Linux/macOS 下中文路径能用 std::ofstream，但得确认系统 locale 是 UTF-8
Unix 系统靠系统级 locale 决定文件 API 对路径字节的解释方式。如果 LANG 是 zh_CN.UTF-8，std::ofstream 就能直接打开 "./测试/a.txt"；但如果 locale 是 POSIX 或 C，哪怕路径字节是合法 UTF-8，内核也会拒绝（errno = EINVAL）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 运行时检查：
std::string loc = setlocale(LC_CTYPE, nullptr);，输出应含UTF-8 - 启动程序前强制设置：
LANG=zh_CN.UTF-8 ./myapp，或代码里setlocale(LC_CTYPE, "zh_CN.UTF-8")（注意：仅影响 C 函数，但 Unix 的open()系统调用本身依赖这个） - 避免在容器中遗漏 locale：Docker 镜像需显式安装语言包并生成 locale，例如 Debian 中执行
locale-gen zh_CN.UTF-8
std::filesystem::path 不自动处理编码，它只是字节容器
std::filesystem::path 在底层不做任何编码转换。它在 Windows 上存储 wchar_t 序列，在 Linux/macOS 上存储 char 序列 —— 你塞进去什么，它就原样传给系统调用。所以 std::filesystem::path("/测试") 在 UTF-8 locale 下正常，在 C locale 下会失败，和 std::ofstream 一样。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 不要用
.string()获取窄字符串路径再传给std::ofstream：这会丢失原始编码意图 - 统一路径构造入口：所有路径来源（用户输入、配置文件、命令行参数）在进入
std::filesystem::path前，先转为目标平台期望的编码（Windows → UTF-16，Linux/macOS → UTF-8） - 调试时打印
path.native().size()和每个字节/码元值，比猜编码更可靠
跨平台项目里最稳妥的路径处理方式：绕过 C++ 标准库的文件 API
标准库的 std::fstream 和 std::filesystem 对中文路径的支持本质是“碰系统运气”。真正稳定的做法，是用平台原生 API 控制字节流，再把句柄交给 C++ 流封装。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- Windows：用
CreateFileW打开路径，拿到HANDLE后用_open_osfhandle转成int，再用fdopen包装为FILE*，最后用std::iostream构造器接入 - Linux/macOS：确保 locale 正确后，直接用
open()+fdopen()，路径保持 UTF-8 字节流不变 - 第三方库如
boost::nowide就是干这事的：它重载了std::fstream构造函数，内部自动做平台适配，比手写更轻量
真正麻烦的从来不是“怎么让中文显示出来”，而是“同一串字节，在不同系统上是否被当作文本路径解析”。这点不厘清，所有 setlocale、codecvt、u8"" 的尝试都只是在掩盖问题。
