lexically_normal() 仅做词法归一化，不访问文件系统，故遇不存在目录、符号链接起点或未解析变量等“断点”时..无法消去；它适合路径构造阶段，而canonical()用于使用阶段以确保真实路径有效性。
为什么 lexically_normal() 有时不生效？
它只做词法归一化，不访问文件系统，所以 .. 能消掉的前提是路径里没有“断点”——比如不存在的目录、符号链接起点、或未解析的变量。遇到 /a/b/../c 会变成 /a/c，但 /a/../b/c 在根目录下也安全；可一旦写成 /a/./../b，中间的 ./ 不影响逻辑，lexically_normal() 照样能压平。真正卡住的是像 /a/b/../../c/../d 这种跨多级回退后又前进的情况——它能处理，但结果依赖路径字符串结构，不是靠真实目录树。
lexically_normal() 和 canonical() 到底该选谁？
lexically_normal() 快、纯内存操作、无权限/IO 开销；canonical() 会查磁盘、解析符号链接、要求路径存在且可访问。如果你只是想把 foo/../bar/./baz 整干净，又不确定目标是否存在，或者在构建路径模板（比如日志路径拼接），就用 lexically_normal()。但若要确认最终落盘位置，比如打开文件前校验路径真实性，必须用 canonical()，否则可能绕过权限检查或指向错误位置。
-
lexically_normal()：适合路径拼接、日志打印、配置生成等“构造阶段” -
canonical()：适合打开文件、加载资源、安全校验等“使用阶段” - 两者不互斥——先
lexically_normal()整形，再canonical()落地，是常见稳健做法
Windows 下要注意路径分隔符和大小写
Windows 默认不区分大小写，但 lexically_normal() 不做大小写折叠，C:\Foo\..\Bar 和 c:\foo\..\bar 经它处理后仍是不同字符串。而且它保留原始分隔符风格：C:/foo/../bar → C:/bar，不会自动转成反斜杠。如果后续要传给 Win32 API 或某些库（比如旧版 OpenSSL），得手动调用 make_preferred()：
std::filesystem::path p = "C:/foo/../bar"; p = p.lexically_normal().make_preferred(); // 得到 C:\bar
另外，UNC 路径如 \server\share\foo\..\bar 也能正常归一，但开头双反斜杠不能省——漏写就变成普通相对路径。
立即学习“C++免费学习笔记（深入）”；
别忘了空路径和根路径的边界情况
空 path 对象调用 lexically_normal() 返回空；单个 . 变成空字符串；.. 变成 ..（无法再上提）；根路径如 / 或 C:/ 调用后不变。最容易错的是拼接后没清理：
auto p = std::filesystem::path("/tmp") / ".." / "etc";
// p == "/tmp/../etc"，还没归一
auto normalized = p.lexically_normal(); // "/etc"
常见坑：链式调用时忘了加括号，写成 p / "..".lexically_normal()——这会先对字符串字面量调用，报错；正确是 (p / "..").lexically_normal()。
. 和 ..，实际是守住“构造时不越界、使用前再验真”的分寸感。多数时候你只需要 lexically_normal()，但只要涉及真实文件操作，就得立刻补上 canonical() 或至少 exists() 检查——不然调试时看到路径明明“看起来对”，却打不开文件，八成是这儿漏了。 
