find_last_of 查找字符集中任意字符最后一次出现的位置，返回其索引；若未找到则返回 npos，需检查有效性并注意边界（如避免越界取 substr(pos+1)）。
用 find_last_of 找不到点？注意它和 find_last_of 的语义差异
find_last_of 查的是“字符集中任意一个字符的最后一次出现”，不是“找最后一个点”。比如路径 "archive.tar.gz"，filename.find_last_of(".") 返回的是第二个点的位置（gz 前的点），但如果你传入 ".\" 这类字符串，它可能误匹配反斜杠或点，结果错乱。
真正该用的是 find_last_of('.') —— 单引号加单个点，且必须确保只查点。更稳妥的做法是：size_t pos = filename.find_last_of('.'); 然后立刻检查 pos != std::string::npos，再确认这个点不在开头（避免 ".gitignore" 被当成扩展名）和不在路径分隔符之后（避免 "/home/user.file.txt" 里误取 txt）。
- Windows 下路径分隔符是
'\'，Unix/Linux/macOS 是'/'，建议统一用std::filesystem::path（C++17）自动处理 - 如果不用
std::filesystem，至少要跳过末尾的路径分隔符：先find_last_of("/\")得到目录结束位置，再从那之后找点 -
find_last_of和find_last_not_of容易混淆——后者是找“不在此集合中的字符”，别用错
用 substr 提取扩展名时，起始位置和长度怎么算？
substr(pos, len) 的 len 是可选参数，默认到末尾；但直接写 filename.substr(pos) 会把点也包含进去（如得到 ".txt"），而多数场景需要纯扩展名（"txt"）。所以通常要 substr(pos + 1)。
但这里有个坑：如果 pos 是最后一个字符（即文件名以点结尾，如 "file."），pos + 1 就越界了，substr 会抛异常或返回空串（取决于标准库实现）。安全写法是先判断 pos + 1 。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 推荐写法：
if (pos != std::string::npos && pos + 1 - 不要写
filename.substr(pos + 1, std::string::npos)—— 第二个参数是长度，不是“直到末尾”的标志；std::string::npos在这里是合法值，但语义误导性强 - 若需大小写归一化（如统一转小写），应在提取后再调用
std::transform，别在substr里混逻辑
C++17 起，用 std::filesystem::path::extension() 更可靠
手写 find_last_of + substr 容易漏掉隐藏文件、多点名、无扩展名等情况。C++17 的 std::filesystem::path 内置规则更贴近真实系统行为。
例如：std::filesystem::path p("my.photo.jpeg"); p.extension() 返回 ".jpeg"；p.stem() 返回 "my.photo"；p.filename() 返回 "my.photo.jpeg"。它自动忽略末尾的点、处理 .tar.gz 这类复合扩展（可用 replace_extension("") 剥离）。
- 注意：Windows 下
extension()区分大小写，但实际文件系统不区分；Linux 下一般小写，但不保证 - 编译需加
-lstdc++fs（GCC）或启用 /std:c++17（MSVC） - 如果项目还不能升 C++17，就别硬套，老老实实用
find_last_of加边界检查更可控
常见错误现象和对应修复点
调试时看到扩展名为空、取到整个文件名、或程序崩溃，大概率是以下某条没检查：
- 没判断
find_last_of返回std::string::npos—— 比如文件名"README"没点，直接substr(npos + 1)是未定义行为 - 把
find_last_of(".\/")当成“找最后一个点”，结果在"C:\temp\file.txt"中匹配到了反斜杠，pos变成反斜杠位置，后续substr完全错乱 - 忽略当前目录标识：
"./data.csv"中的点是路径的一部分，不是扩展名分隔符；应先用std::filesystem::path或手动跳过"./"和"../" - UTF-8 文件名中含中文或 emoji 时，
std::string按字节操作不会出错，但find_last_of仍只认 ASCII 点；这点无需额外处理，除非你要支持 Unicode 标点（极少场景）
扩展名逻辑看着简单，但边界情况比想象中多——尤其是当输入来自用户路径、HTTP URL 解码结果或 ZIP 内部文件名时，std::filesystem::path 的健壮性优势立刻体现出来。
