std::filesystem::path 自动标准化路径分隔符，支持跨平台混合使用 / 和 \；推荐用正斜杠构造，获取可移植字符串应使用 generic_string()。
std::filesystem::path 自动处理分隔符，无需手动替换
它内部用 std::filesystem::path::preferred_separator 表示当前平台的“推荐分隔符”，但所有构造和操作都支持混合使用 / 和 \ —— 无论你在 Windows 上用正斜杠，还是在 Linux 上用反斜杠，std::filesystem::path 都能正确解析并标准化。
关键在于：它不把路径当字符串处理，而是当作结构化路径对象。所以你写 path("a/b\\c") 在 Windows 上会被归一为 a\b\c，在 Linux/macOS 上归一为 a/b/c（注意：Linux 不会真的用 \，但构造时不会报错）。
构造时用字符串字面量最安全的方式是统一用 /
/ 是所有平台都支持的分隔符，C++17 标准明确要求 std::filesystem::path 必须识别它。而 \ 在 Windows 字符串字面量中需转义（"a\\b"），易出错；在 POSIX 系统上虽可被接受，但非惯用，且某些 API（如 generic_string()）可能保留原始形式导致意外。
- ✅ 推荐：
std::filesystem::path p = "data/config.json"; - ✅ 也可行（Windows）：
std::filesystem::path p = "data\\config.json"; - ❌ 避免混用未转义反斜杠：
"data\config.json"→ 编译器会把\c当作非法转义序列报错 - ⚠️ 不要依赖
.string()输出格式：它返回本地编码 + 本地分隔符，跨平台日志中可能不一致
获取可移植路径字符串时优先用 generic_string()
.string() 和 .u8string() 返回的是“本地格式”（Windows 返回 \，Linux 返回 /），而 generic_string() 强制返回以 / 分隔的 UTF-8 字符串，适合配置文件、网络传输、日志记录等需要一致文本表示的场景。
std::filesystem::path p = "a/b\\c"; std::cout << p.string() << "\n"; // Windows: "a\b\c", Linux: "a/b/c" std::cout << p.generic_string() << "\n"; // 总是 "a/b/c"（UTF-8）
注意：generic_string() 不是“通用编码转换”，它只是强制用 / 替换所有分隔符，并保证 UTF-8 编码；路径中的非 ASCII 字符仍按原编码处理（如 Windows 的 GBK 路径需先转 UTF-8 再构造 path）。
拼接与遍历时分隔符自动适配，但不要假设底层存储格式
用 / 操作符拼接、parent_path()、filename() 等行为完全跨平台，结果始终符合当前系统语义。但别试图通过 .string() 结果去“判断操作系统”——这不可靠，且违反抽象原则。
- ✅ 正确用法：
auto config = base / "etc" / "app.conf";（/是重载运算符） - ✅ 安全提取：
p.parent_path().filename()得到最后一级目录名，不涉及分隔符字符串操作 - ❌ 错误假设：
if (p.string().find('\\') != std::string::npos)判断是否为 Windows ——string()可能返回/即使在 Windows（比如你用generic_string()构造过）
真正容易被忽略的是：路径对象本身不保存“原始输入分隔符”，所有操作都基于归一
化后的逻辑结构。一旦你调用了 make_preferred() 或输出到本地 API（如 fopen()），才真正落地为 OS 原生格式 —— 这个时机由你控制，不是隐式发生的。
