最可靠标准是用std::filesystem::path解析后调用is_absolute()或is_relative()判断格式合法性，再用exists()或status()验证实际存在性，而非正则匹配。
Windows 下用 std::filesystem::path 判断路径合法性最可靠
标准库的 std::filesystem::path 不验证路径是否存在，但能解析结构、识别根、区分相对/绝对——这是最接近“格式合法”的定义。直接调用 is_absolute() 或 is_relative() 即可，无需手动解析斜杠或盘符。
-
std::filesystem::path("C:\foo\bar")→is_absolute()返回true -
std::filesystem::path("../data/file.txt")→is_relative()返回true -
std::filesystem::path("C:foo\bar")（无反斜杠）→is_absolute()为false，因为 Windows 视其为相对路径（当前驱动器下的相对路径） - 空字符串、仅空格、含
path时可能抛std::filesystem::filesystem_error，需try/catch
Linux/macOS 下注意根路径和开头斜杠的语义
Unix-like 系统只认以 / 开头为绝对路径，其余均为相对路径。但要注意：// 开头在 POSIX 中是实现定义行为（某些系统等价于 /，有些保留为网络路径前缀），std::filesystem::path 在 libstdc++ 和 libc++ 中通常将 //foo 视为绝对路径，但 is_absolute() 结果依赖底层 OS API 的解释。
-
std::filesystem::path("/home/user")→is_absolute()为true -
std::filesystem::path("//server/share")→ 多数现代实现返回true，但不可跨平台依赖 -
std::filesystem::path("file.txt")或"./file.txt"→ 均为相对路径 - 含
..或.的路径（如".././sub/"）仍是合法相对路径格式，is_relative()仍返回true
别手写正则匹配路径分隔符——它解决不了本质问题
用正则判断是否以 / 或 [a-zA-Z]: 开头，看似简单，实则漏掉大量边界情况：UNC 路径（\servershare）、带空格或点号的合法路径名、不同编码下的宽字符路径、符号链接中的特殊字符等。C++ 标准路径库已封装这些逻辑，自己解析既不安全也不必要。
- 正则
^/[^ ]*$无法处理/proc/self/fd/123这类运行时才有效的路径格式 - 正则匹配盘符
^[a-zA-Z]:[/\]会错判C:foo.txt（合法相对路径）为绝对路径 - POSIX 允许路径中含任意非
真正要检查“路径能否被系统使用”？得走 exists() 或 status()
is_absolute() 只回答“格式上是否绝对”，不代表路径存在或可访问。如果业务需要确认路径真实可用（比如配置文件读取前校验），必须调用 std::filesystem::exists(p) 或 std::filesystem::status(p)，它们会触发系统调用并返回实际状态。
立即学习“C++免费学习笔记（深入）”；
-
exists()返回false可能因为路径不存在、权限不足、或中间目录不可遍历 - 对符号链接，
exists()默认跟随链接；若需检查链接本身是否存在，用exists(p, std::filesystem::symlink_option::no_follow) - 频繁调用
exists()有性能开销，生产环境建议缓存结果或结合业务逻辑延迟校验
std::filesystem::path 解析，语义层面靠 exists() 或 status() 验证，而跨平台一致性往往卡在 UNC、空格、编码这些细节上——别跳过 try/catch，也别把格式校验和存在性校验混为一谈。 
