std::filesystem::path::extension() 返回带点号的扩展名（如".txt"），需注意空扩展、尾部空格、大小写敏感及非法路径等问题，正确用法应先校验再截取。
用 std::filesystem::path::extension() 获取扩展名，但要注意点号是否包含
它返回的是带点号的字符串，比如 "file.txt" 的 extension() 是 ".txt"，不是 "txt"。这点容易在字符串比较或拼接时出错。
常见错误现象：用 if (p.extension() == "txt") 判断失败——因为实际是 ".txt"。
- 如果需要纯后缀名（不含点），用
p.extension().string().substr(1)，但得先检查是否非空且以点开头 - 更稳妥的做法是：
auto ext = p.extension(); if (!ext.empty() && ext.string()[0] == '.') { /* 取 substr(1) */ } - 空扩展名（如
"Makefile"）会返回空path，.string()是空串，别直接substr(1)
stem() 不是“文件名”，而是“去掉扩展名后的主干”
stem() 返回的是 filename() 去掉 extension() 的部分，不是路径中最后一级的完整名字。例如 "/a/b/file.tar.gz" 的 stem() 是 "file.tar"，不是 "file"。
使用场景：批量处理压缩包时想保留原始名，又不想带 .tar.gz；或者做文件重命名时需隔离主干与后缀。
立即学习“C++免费学习笔记（深入）”；
-
stem()对"readme"（无扩展名）返回"readme"；对"readme."（结尾有点）返回"readme"；对"readme.."返回"readme." - 它不处理多级扩展名逻辑，只按最后一个点切分 —— 这是标准行为，不是 bug
- 若需“去掉所有已知后缀”，得自己维护后缀列表并循环调用
replace_extension("")
Windows 路径下 extension() 可能返回 ". "（点+空格）
某些旧工具生成的文件名末尾带空格（如 "report.txt "），Windows 文件系统允许，std::filesystem 会把末尾空格视作文件名一部分，导致 extension() 返回奇怪结果，比如 ". " 或空。
这不是库的问题，而是路径本身不规范。真实项目中遇到过因资源管理器重命名残留空格引发的解析失败。
- 读取文件名后建议先用
std::string::find_last_not_of(" \t\r\n")截断尾部空白 - 不要依赖
extension()做安全校验（如判断是否为图片），应结合 MIME 类型或 magic bytes - C++20 中
std::filesystem对非法路径容忍度低，遇到含控制字符或 Unicode 归一化异常的路径可能抛std::filesystem::filesystem_error
跨平台时注意 operator/ 和大小写敏感性对 extension() 的间接影响
extension() 本身不涉及路径拼接或大小写，但你传给它的 path 对象常来自拼接或遍历。Linux 下 "FILE.TXT" 和 "file.txt" 是不同文件，而 Windows 不区分——这会导致同一段代码在不同系统上拿到的 extension() 值虽然正确，但后续逻辑（如查找配置表）可能因大小写不一致失效。
- 避免直接用
p.extension() == ".json"做判断；改用p.extension().string().compare(".json") == 0或转小写后再比 - 用
std::filesystem::canonical()前先确认目标存在，否则可能抛异常，导致extension()根本没机会调用 - 构建
path时优先用u8string或 UTF-8 字符串字面量，避免 Windows 下string含 GBK 编码导致extension()解析错位
事情说清了就结束。最麻烦的从来不是怎么调函数，而是你传进去的那个 path 对象，到底是不是你以为的样子。
