最安全的路径拼接方式是使用 std::filesystem::path 的 / 运算符而非 + 或字符串拼接，它自动处理平台差异、规范化路径，并需注意 Windows 下必须用宽字符或 u8path 处理 Unicode。
用 std::filesystem::path 拼接路径最安全
手动拼接字符串（比如 "./data/" + name + ".txt"）在 Windows 和 Linux 下容易出错：斜杠方向不一致、多余分隔符、相对路径解析失败。C++17 引入的 std::filesystem::path 自动处理平台差异，推荐作为默认方案。
常见错误现象：std::filesystem::path("a") + "b" 看似能用，但若 "b" 带开头斜杠（如 "/config.json"），会变成绝对路径，意外覆盖父级上下文。
- 用
/运算符拼接，不是+：auto p = std::filesystem::path("dir") / "file.txt" - 避免直接拼接裸字符串，优先用
path对象：std::filesystem::path(base) / filename - 构造时传入字符串会自动 normalize（比如合并
"a//b/./c"→"a/b/c"），但不会检查路径是否存在
解析路径时别依赖 .string() 直接切分
std::filesystem::path 提供了结构化访问接口，硬拆 .string() 结果（比如用 find_last_of('/')'）会忽略 Windows 下反斜杠、UNC 路径、驱动器盘符等细节，导致跨平台行为不一致。
使用场景：需要取文件名、扩展名、父目录，或判断是否为绝对路径。
立即学习“C++免费学习笔记（深入）”；
- 取文件名用
.filename()，不是.string().substr(...) - 取扩展名用
.extension()（返回".txt"），.stem()返回无扩展名部分 - 判断绝对路径用
.is_absolute()，比检查首字符更可靠（尤其 Windows："C:\a"或"\\server\share"） -
.parent_path()返回上层目录，空路径时返回""，不是抛异常
Windows 下处理中文路径必须用宽字符
在 Windows 上，如果路径含中文、日文等 Unicode 字符，用窄字符串（std::string）构造 std::filesystem::path 会导致乱码或 std::filesystem::filesystem_error，因为 Windows API 底层只接受 UTF-16。
错误信息示例：std::filesystem::create_directory: The system cannot find the path specified，实际路径存在且权限正常，只是编码不对。
- 显式用
std::wstring构造：std::filesystem::path p(L"数据/测试.txt") - 从 UTF-8 字符串转换（如命令行参数）需调用
std::filesystem::u8path()，不是直接强转 - 避免混用：
std::filesystem::path("中文") / L"子目录"会触发隐式转换，行为未定义，应统一用宽字符或u8path
跨平台部署前务必检查 std::filesystem 的链接和运行时支持
Linux/macOS 一般没问题，但某些旧环境（如 CentOS 7 默认 glibc、MinGW-w64 旧版本）可能缺少完整实现，编译通过但运行时报 std::filesystem::filesystem_error: Operation not supported。
性能影响：相比纯字符串操作，std::filesystem::path 有轻微构造开销，但路径解析本身不涉及 I/O，不影响性能关键路径。
- 编译时加
-lstdc++fs（GCC）或确认 CMake 中启用了stdc++fstarget - 运行时验证：
try { std::filesystem::current_path(); } catch(...) { /* fallback */ } - 嵌入式或极简环境可考虑轻量替代（如
boost::filesystem或手写白名单字符过滤），但放弃标准化成本更高
最易被忽略的是 Windows 宽字符和 Linux UTF-8 的隐式转换边界——同一段代码在 VS 和 Clang 下表现可能不同，必须在目标平台上实测中文路径全流程。
