应使用 std::string::rfind 从末尾查找最后一个点以提取扩展名，注意检查返回值是否为 npos 且位置大于0；更推荐用 c++17 的 std::filesystem::path::extension() 获取带点扩展名。
用 std::string::rfind 找最后一个点位置
文件扩展名总在最后一个 . 之后，所以不能用 find（它从头找），必须用 rfind 从末尾反向搜索。如果文件名是 "archive.tar.gz"，rfind(".") 返回索引 11，而不是 8 —— 这决定了你取的是 "gz" 而不是 "tar.gz"。
注意边界情况：rfind 找不到时返回 std::string::npos，直接用这个值做下标会出错；另外像 "makefile"、".gitignore" 这类无扩展名或以点开头的文件，也要单独判断。
实操建议：
- 先检查
filename.rfind('.') != std::string::npos - 再确认找到的位置不是开头（
pos > 0），避免把".bashrc"误判为扩展名"bashrc" - 提取子串用
filename.substr(pos + 1)，不要漏掉+1
用 std::filesystem::path 更安全地提取扩展名（C++17）
手写字符串逻辑容易漏掉路径分隔符、隐藏文件、多点名等边界，std::filesystem::path 是更鲁棒的选择。它自动识别路径结构，.extension() 方法返回带点的扩展名（如 ".txt"），.stem() 返回主名，.filename() 返回不含路径的部分。
立即学习“C++免费学习笔记（深入）”；
常见误区：
-
.extension()对"image.jpeg"返回".jpeg"，不是"jpeg"；要去掉点得再调一次.string().substr(1)或用.replace_extension("").string() - 路径含
"./data.log.bak"时，.extension()默认只返回最外层".bak"；若要完整扩展名（如".log.bak），得用.replace_extension("").extension()多套一层 - 不支持
std::filesystem的旧编译器（如 GCC -std=c++17 -lstdc++fs
处理 Unicode 路径时别用裸 std::string
Windows 下文件名可能是 UTF-16（std::wstring），Linux/macOS 虽用 UTF-8，但某些 locale 下 std::string 的 rfind 仍可能在多字节字符中间截断。这时候硬拆 . 会导致乱码或越界。
解决方案很实际：
- 跨平台项目优先用
std::filesystem::path，它内部已处理编码适配 - 若必须用字符串且确定是 UTF-8（如 Linux 服务端），确保输入来自
std::filesystem::path.filename().string()，而非char*系统 API 直接读取 - Windows 上若调用
CreateFileW等宽字符 API，就该用std::wstring+wrfind(L'.')，别强转成std::string
性能敏感场景下避免重复构造 std::filesystem::path
高频调用（比如日志轮转、资源加载循环）中，每次 new 一个 std::filesystem::path 会有小开销：内部要解析分隔符、缓存各段视图。如果只是简单取后缀，且路径格式高度可控（如全是 "xxx.yyy" 形式），纯 std::string + rfind 依然更快。
但要注意这个“可控”有多严格：
- 路径不含目录部分（即没
/或\） - 不会出现
"name..ext"或"name.这种异常 - 不需要区分
".config和config（前者是隐藏文件，后者是普通文件）
一旦业务逻辑开始混入路径拼接、跨平台部署或用户上传任意文件名，就该切回 std::filesystem::path——省下的那点纳秒，远不如少修一个 filename == "." 导致的崩溃来得实在。
