应使用 std::filesystem::path 替代手拼路径，它自动处理跨平台分隔符、规范化及类型检查；需用 / 拼接、优先 generic_string()、先 exists() 再 is_regular_file()、从 argv[0] 推导基准路径，并注意编译器兼容性与链接选项。
用 std::filesystem::path 替代手拼字符串
手动用 "./data/" + name + ".txt" 或 strcat 拼路径，在 Windows 和 Linux 下迟早出事：斜杠方向、盘符、大小写敏感性全都不一样。C++17 引入的 std::filesystem::path 就是干这个的——它内部按平台规则自动处理分隔符和规范化。
-
std::filesystem::path构造时接受任意风格的字符串（"a/b\c"、"C:\temp"、"../out/file.json"），自动归一化 - 用
/运算符拼接，不是+：base / "config" / name + ".yaml"，它会自动选对分隔符 - 不要对
path对象调用.string()再去拼，那又退化回手工处理；需要字符串时再转，且优先用.generic_string()（返回正斜杠风格，跨平台日志/调试更稳）
路径操作前先检查 std::filesystem::exists() 和 is_regular_file()
不同系统对“路径存在但不可读”“符号链接指向不存在目标”“权限拒绝但路径语法合法”的反应差异极大。直接 std::ifstream 打开失败，错误码可能是 ENOENT、EACCES、ENOTDIR，根本看不出是路径错还是权限错。
- 统一先用
std::filesystem::exists(p)判断路径是否真实可达（不区分文件/目录） - 再用
std::filesystem::is_regular_file(p)或is_directory(p)明确类型，避免在 Windows 上把目录当文件打开、或在 macOS 上因符号链接绕过权限检查 - 注意：
exists()可能抛std::filesystem::filesystem_error，比如网络驱动器断连，得捕获——别假设它只返回false
跨平台路径硬编码必须走 std::filesystem::current_path() 或 argv[0] 推导
写死 "./config/app.conf" 看似简单，但用户双击运行、从终端 cd 到别处执行、打包成 App Bundle（macOS）、或被 systemd 以不同工作目录启动时，就完全失效。
- 启动时立刻存下
std::filesystem::current_path()，作为相对路径基准；但注意它可能被后续chdir改动 - 更可靠的是从可执行文件位置反推：
std::filesystem::path(argv[0]).parent_path()，Windows 的GetModuleFileName或 Linux/macOS 的/proc/self/exe都被std::filesystem::canonical()封装好了 - 配置文件、资源目录建议用“可执行文件同级的
res/”而非“当前目录的./res/”，前者行为确定，后者依赖 shell 环境
注意 std::filesystem 在 MinGW 和旧 macOS 上的兼容性缺口
不是所有“支持 C++17”的编译器都完整实现了 std::filesystem。MinGW-w64 8.0 之前默认不启用，macOS 10.15 以前 libc++ 没实现 std::filesystem::copy()，Clang 9 以下甚至不认这个命名空间。
立即学习“C++免费学习笔记（深入）”；
- 编译时加
-lstdc++fs（GCC）或-lc++fs（Clang），否则链接报undefined reference to 'std::filesystem::status' - CMake 中要显式
find_package(Threads REQUIRED)并链接stdc++fs，光设set(CMAKE_CXX_STANDARD 17)不够 - CI 测试至少覆盖 GCC 9+、Clang 10+、Apple Clang 12+，Windows 上优先用 MSVC 2019 或 MinGW-w64 9.0+
路径逻辑看着简单，但真正卡住人的从来不是“怎么写”，而是“哪个环节在哪个系统上悄悄变了行为”。多打几行 std::cout ，比猜强得多。
