最稳妥提取文件后缀应使用 std::string::rfind(".")，检查是否为 npos 或位置为0（如 ".gitignore"），再用 substr(pos+1)；注意大小写敏感性依平台而异，std::filesystem::path::extension() 返回带点字符串且对无点文件返回空。
用 std::string::rfind 找最后一个点最稳妥
直接用 std::string::find 从头找点，会错判 "archive.tar.gz" 这类多点文件名——它返回第一个点的位置，导致截出 "tar.gz" 而不是真正的后缀 "gz"。必须从末尾往前搜。
实操建议：
立即学习“C++免费学习笔记（深入）”；
-
rfind(".")返回std::string::npos表示没点，此时无后缀 - 找到点后，检查位置是否为 0（即文件名以
"."开头，如".gitignore"），这种通常不算常规后缀，按需跳过 - 取子串用
substr(pos + 1)，别漏掉+1，否则会把点一起包进去
std::string ext = filename.rfind('.') != std::string::npos
? filename.substr(filename.rfind('.') + 1)
: "";
区分大小写？得看场景和系统
Windows 文件系统默认不区分大小写，"FILE.TXT" 和 "file.txt" 是同一个文件；Linux/macOS 默认区分。C++ 标准库不做转换，"JPG" 和 "jpg" 就是两个不同字符串。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 如果只是做简单匹配（比如过滤日志里所有
"log"文件），用std::equal配std::tolower比较更安全 - 如果后续要打开文件，且目标平台是 Windows，强行转小写反而可能掩盖路径问题（比如某些老旧工具依赖大写扩展名）
- 别依赖
std::string::compare的大小写敏感版本去“统一处理”，它不帮你转大小写
std::filesystem::path::extension() 看似方便，但有陷阱
C++17 引入的 std::filesystem::path 确实提供 extension() 方法，但它返回的是包括点的字符串，比如 "txt" → ".txt"，而且对 "makefile"、"README" 这类无点但有约定含义的文件，它返回空——这和多数人直觉不符。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 如果项目已用 C++17 且需要跨平台路径操作，可以用
extension().string()，但记得手动去掉开头的点：ext.substr(1) - 如果只为了判断后缀，不用整个
std::filesystem，它带额外开销（尤其在嵌入式或性能敏感场景） - 注意：某些编译器（如旧版 MSVC）对
std::filesystem的实现不完整，extension()在含 Unicode 路径下可能行为异常
别忘了路径分隔符干扰——"C:data
eport.pdf" 怎么办
只查点，会把 Windows 路径中的反斜杠当普通字符，rfind(".") 仍能正确找到 "pdf"；但若路径含正斜杠（如网络路径 "//server/share/doc.txt"）或混合分隔符，逻辑不变。真正的问题是：有人会先用 find_last_of("\/") 提取纯文件名，再查点——这步容易漏掉边界情况。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 优先用
std::filesystem::path::filename()提取不含目录的部分（C++17），比手撕字符串可靠 - 如果不能用 C++17，自己拆时注意：空路径、结尾是分隔符（如
"dir/"）、只有分隔符（如"/"）都要单独判断，否则rfind可能作用于错误字符串 - 测试用例至少覆盖：
"a.b.c"、".hidden"、"noext"、"path/to/file"、"C:\temp\readme.TXT"
".gitignore" 这种点开头的文件名是否算“有后缀”，以及大小写处理时没对齐实际运行环境。 
