用std::filesystem::relative计算相对路径时，必须显式指定base目录（如源文件的parent_path），否则默认以当前工作目录为基准，易导致路径错误；它返回“从base到target”的路径，而非“从target到base”。
直接结论：用 std::filesystem::relative 计算两个文件的相对路径，关键不是“能不能算”，而是“基路径选不对，结果就错得离谱”——它默认以当前工作目录为基准，不是你直觉里的“从 source 到 target 的路径”。
为什么 relative 返回的路径经常看起来“反了”或“多了一堆 ..”
因为 std::filesystem::relative(target, base) 的语义是：“从 base 出发，怎么走到 target”。但很多人误以为它是 “从 target 回到 base”。更麻烦的是：如果省略 base 参数，它会自动用 std::filesystem::current_path() 作基准——而这个路径和你的源文件、目标文件几乎无关。
常见错误现象：
- 输入 relative("a/b/c.txt", "a/d/e.txt") 却得到 ../../d/e.txt（正确），但你以为该是 ../d/e.txt
- 在 IDE 里运行结果和终端里不一样（工作目录不同）
- 路径含中文或空格时抛出 std::filesystem::filesystem_error
- 务必显式传入
base，别依赖默认值 -
base必须是目录，不能是文件；如果传了文件路径，会抛异常或静默截断 - 两个路径必须都存在（或至少父目录存在），否则可能抛
filesystem_error（取决于实现和选项）
如何安全地计算 A 文件到 B 文件的相对路径
核心逻辑：先取 A 所在目录作为 base，再对 B 调用 relative。这才是人话里的“从 A 去 B 怎么走”。
示例（假设 A 是 "proj/src/main.cpp"，B 是 "proj/include/utils.h"）：
立即学习“C++免费学习笔记（深入）”；
namespace fs = std::filesystem; fs::path a = "proj/src/main.cpp"; fs::path b = "proj/include/utils.h"; fs::path base = a.parent_path(); // → "proj/src" fs::path rel = fs::relative(b, base); // → "../include/utils.h"
- 如果
a和b不在同一个驱动器（Windows），relative会返回空路径或抛异常——这是标准行为，不是 bug - 路径必须 normalize 过（比如去掉
./、处理..），否则比较或计算可能出错；建议先调用.lexically_normal() - Windows 下注意大小写：NTFS 默认不区分，但
relative内部按字节比较，路径大小写不一致可能导致意外结果
relative 和 proximate 到底该用哪个
fs::relative 严格按目录树结构算最短相对路径；fs::proximate 会优先尝试相对路径，失败时退回到绝对路径（并保证可访问）。多数场景下，你要的是 relative，除非你明确需要“能用就行”的兜底行为。
- 想确保结果一定是相对路径？用
relative，但自己 handle 异常 - 在构建系统或配置生成中，路径要嵌入脚本/Makefile，且不能含空格或非法字符？
relative更可控 - 只是日志里显示一个“用户友好路径”，且不介意偶尔是绝对路径？
proximate更省心 - 两者都不做路径存在性校验——传入不存在的路径，只要父目录可达，仍可能返回看似合理的字符串
真正容易被忽略的一点：C++17 的 std::filesystem 在 MinGW 和旧版 libc++ 上支持不完整，relative 可能静默返回空或抛异常。上线前务必在目标平台实测两个真实路径——别只跑单元测试里的字符串 case。
