最可靠方法是用 std::string::rfind('.') 定位最后一个点，再截取前缀；若未找到或点在开头则保留原名；对完整路径需先提取文件名，C++17 推荐用 std::filesystem::path::stem()。
用 std::string::rfind 找最后一个点位置最可靠
直接删掉最后几个字符不可靠——比如文件名是 "archive.tar.gz"，盲目删 ".gz" 会错删。正确做法是定位最后一个 '.'，再截取前面部分。C++11 起 std::string 提供 rfind，从右往左找，天然适合这个场景。
注意：要排除路径分隔符干扰（如 "./data.txt"），所以只看文件名部分；但若输入已确保是纯文件名（不含 / 或 ），rfind 就够用。
- 如果没找到点（
rfind返回std::string::npos），原字符串就是无扩展名的文件名，直接返回 - 如果点在开头（如
".gitignore"），按惯例它属于隐藏文件名，不是扩展名，也应保留全名 -
rfind比find_last_of更准——后者会把"file.name.backup"中间那个点也当候选，而我们只关心“最后一个点是否属于扩展分隔符”
用 std::filesystem::path 更健壮，但需 C++17
如果你的项目已启用 C++17 且不介意依赖 <filesystem>，std::filesystem::path 是更安全的选择。它自动处理不同平台路径格式、区分目录与文件名，并提供 stem() 方法直接返回无扩展名的文件名部分。
例如：std::filesystem::path("image.jpeg").stem() 返回 "image"；std::filesystem::path(".config").stem() 返回 ".config"（符合 POSIX 隐式约定）。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 必须链接
-lstdc++fs（GCC）或开启 /std:c++17 + /experimental:filesystem（MSVC） -
stem()内部逻辑等价于先取filename()再去掉extension()，但它已处理好边界情况：空扩展名、点开头、多点连写（如"file..txt"） - 不要对非文件路径（如
"../"）调用stem()，结果可能不符合直觉——先确保输入是合法文件名
手动遍历时容易踩的坑：别用 find_last_of(".")
find_last_of 是查找字符集合中任一字符最后一次出现的位置，传入 "." 看似等价，实则危险——因为它的参数是字符串字面量，"." 实际是含结束符 ' ' 的两字符数组，find_last_of 会把 ' ' 也当作待查字符。在某些实现下可能导致未定义行为或意外匹配。
更隐蔽的问题是：如果误写成 find_last_of('.')（单引号），编译失败；若写成 find_last_of(".")（双引号），语义错误但能编译，运行时行为不可靠。
- 坚持用
rfind('.')——参数是char，语义清晰、行为确定 - 别自己循环倒序扫描：效率低，且容易漏掉
npos判断或越界访问 - Windows 下注意：长文件名可能含
':'（如备用数据流file.txt:zone.identifier），但扩展名规则仍以最后一个点为准，无需特殊处理
跨平台兼容性提醒：路径分隔符不能忽略
如果输入是完整路径（如 "C:\docs\notes.md" 或 "/home/user/file.tar.xz"），直接对整个字符串调用 rfind('.') 可能错把目录名里的点当成扩展分隔符（比如 "my.dir/file.txt"）。这时候必须先提取文件名部分。
简单办法是用 std::string::find_last_of("/\") 定位最后一个路径分隔符，再取其后子串；但更推荐统一走 std::filesystem::path——它的 filename() 方法自动适配 / 和 ，且能正确处理 UNC 路径和根路径。
- Linux/macOS 下
find_last_of("\")总返回npos，看似无害，但混用平台代码时易埋雷 - 不要依赖
strrchr：C 风格函数对宽字符、UTF-8 多字节无效，且不处理空字符串 - 若无法用
filesystem，至少封装一个basename类似逻辑：从末尾向前扫，跳过结尾斜杠，再找上一个斜杠或到达开头
rfind 加路径分离逻辑——边界情况多，但每一步都可控。 
