lexically_normal() 仅做纯字符串规范化，不访问文件系统、不解析符号链接或环境变量，因此对不存在路径、扩展路径（如?）或UNC路径处理有限；而canonical()需访问磁盘、解析链接并验证存在性，返回真实绝对路径。
为什么 lexically_normal() 有时不生效？
它只做纯字符串层面的规范化，不检查文件系统是否存在，也不处理符号链接。比如 "./foo/../bar" 会变成 "bar"，但若当前目录下根本没有 foo，它照样返回 "bar" —— 这不是 bug，是设计如此。
常见错误现象：path("a/./b//c").lexically_normal() 返回 "a/b/c"，但有人误以为它会把 // 当作根路径处理（实际不会）；或者传入含环境变量或波浪号（~）的路径，结果原样保留，因为这不是 lexical 操作的范畴。
- 只作用于路径字符串本身，不访问磁盘
- 不解析
~、$HOME、%USERPROFILE%等扩展 - 遇到非法字符（如 Windows 下的
）也不会报错，照常返回“规范化”结果 - Windows 下对大小写不敏感，但
lexically_normal()不做大小写归一化，只是删.、合并..
和 std::filesystem::canonical() 的关键区别在哪？
lexically_normal() 是轻量字符串变换，canonical() 是重操作：它必须访问文件系统，解析符号链接，逐段验证路径是否存在，并最终返回绝对、真实、可访问的路径。前者快、可离线；后者慢、需权限、可能抛异常。
使用场景举例：构建日志路径拼接逻辑时，用 lexically_normal() 清理用户输入的相对路径片段足够了；但校验配置文件是否真能被加载，则必须用 canonical()，否则可能“看着规范，实则 404”。
-
lexically_normal()不抛异常（除非内存耗尽），canonical()可能抛filesystem_error -
canonical()要求路径中除最后一段外，其余所有父目录都存在；lexically_normal()对不存在的路径完全无感 - 跨平台行为一致的是
lexically_normal()；canonical()在 Windows 和 Linux 对符号链接的处理逻辑不同
在路径拼接后立即调用 lexically_normal() 合适吗？
合适，但要注意顺序：先拼接，再规范化。因为 operator/ 不自动清理冗余分量，比如 p / ".." / "src" 得到的是 "a/b/../src"，不是 "a/src"。
示例：
std::filesystem::path p = "/home/user"; auto q = (p / "docs" / ".." / "config.txt").lexically_normal(); // q == "/home/user/config.txt"
但别在中间步骤反复调用——没必要。比如 (p.lexically_normal() / "x").lexically_normal() 和直接 p / "x" 再调一次效果一样，多调一次只是白费 CPU。
- 推荐模式：
(base / rel).lexically_normal()，其中rel来自不可信输入（如命令行参数、配置项） - 避免对已知干净的绝对路径（如
"/usr/bin"）再调用，无意义 - 注意：Windows 下路径分隔符反斜杠
会被自动转为正斜杠/（仅在字符串表示中），不影响内部逻辑
Windows 下要注意的路径格式陷阱
Windows 支持多种路径前缀：C:、\?C:、//server/share，而 lexically_normal() 对它们的处理能力有限。它能正确处理普通驱动器路径，但遇到 \? 这类“扩展长度”路径时，会把 \? 当作普通目录名，导致错误归一化。
例如：std::filesystem::path(R"(\?C: emp.. est.txt)").lexically_normal() 返回 R"(\?C: est.txt)" —— 看似正常，但实际这个路径在某些 API 中已失效，因为 \? 路径禁止包含 ..。
- 对
\?或\.开头的路径，不要依赖lexically_normal()做安全校验 - 若需支持长路径或设备路径，应先剥离前缀、规范化主体、再拼回去
- 判断是否为 UNC 路径请用
.is_absolute()+.root_name()，而不是靠字符串匹配
事情说清了就结束。真正难的不是调用函数，而是想清楚你到底要“字符串干净”还是“路径真实可用”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
