std::filesystem::absolute仅补全路径而不验证存在性或解析符号链接；需配合exists()等函数校验，且C++20支持指定基准路径以规避cwd变动风险。
std::filesystem::absolute 为什么返回的路径看起来不对
它只做“补全”，不检查文件是否存在，也不解析符号链接。传入相对路径 "./data.txt"，它就简单拼上当前工作目录；传入 "../config.json"，就往上跳一级再拼——哪怕那个目录根本不存在，或者 config.json 压根没放那儿。
常见错误现象：std::filesystem::absolute("missing.log") 返回 /home/user/missing.log，但 std::filesystem::exists() 返回 false，误以为路径生成失败。
- 务必在调用
std::filesystem::absolute后，用std::filesystem::exists或std::filesystem::is_regular_file验证目标是否真实可达 - 如果想解析软链接（比如
/usr/bin/python3指向/usr/bin/python3.11），得用std::filesystem::canonical，不是absolute - Windows 下注意路径分隔符：
absolute返回的path对象内部用正斜杠或反斜杠都行，但输出字符串时默认按系统习惯，别硬写"\\"去匹配
怎么确保获取的是真正的绝对路径（含真实 cwd）
当前工作目录（cwd）是进程级状态，可能被其他代码（比如第三方库、线程中 chdir）意外修改。直接调用 std::filesystem::absolute 依赖的就是这个易变的 cwd。
使用场景：服务程序长期运行，或多个模块共用一个进程，cwd 不可控。
立即学习“C++免费学习笔记（深入）”；
- 最稳的做法：启动时立刻用
std::filesystem::current_path()记下初始 cwd，后续所有absolute都基于这个快照路径手动拼接，例如：initial_cwd / "conf/app.yaml" - 不要依赖多次调用
current_path()的结果一致——它可能已被改过 - 跨平台注意：Linux/macOS 的
/proc/self/cwd或 Windows 的GetModuleFileName可读取可执行文件所在目录，但那是二进制位置，不是 cwd，别混用
std::filesystem::absolute 在 C++17 和 C++20 下有啥区别
核心行为没变，但 C++20 加了 std::filesystem::absolute 的重载，支持传入第二个参数 std::filesystem::path 作为基准路径，替代隐式依赖 cwd。
性能影响：C++20 版本避免了每次查 cwd 系统调用，尤其在高并发路径拼接场景更轻量。
- C++17 只能：
std::filesystem::absolute("log.txt")（隐式用 cwd） - C++20 可以：
std::filesystem::absolute("log.txt", base_dir)，其中base_dir是你确认过的有效路径，比如配置目录 - 若项目必须兼容 C++17，就老实用
base_dir / "log.txt"替代，别强求absolute
遇到 “No such file or directory” 错误，是不是 absolute 用错了
不是。std::filesystem::absolute 本身不访问磁盘，不会报这个错。真正抛出该异常的是后续操作，比如 std::filesystem::copy、std::ofstream 构造，或 std::filesystem::canonical。
典型链路：absolute 返回 /tmp/data.csv → 你拿它去 open() → 系统报 No such file or directory。
- 先打印
.string()看实际路径，确认没拼错字符或空格 - 检查路径权限：比如
/var/log下普通用户无法写入，即使路径绝对且存在，打开也会失败 - 容器或沙盒环境（Docker、flatpak）里，宿主机路径对进程不可见，
absolute算出来的路径在容器内根本不存在
