最可靠方案是使用 std::filesystem::path 的 filename() 和 stem() 方法。它跨平台处理 Windows/Linux 路径分隔符、UNC、扩展路径等所有合法格式，避免手动解析导致的各类边界错误。
用 std::filesystem::path 提取文件名最可靠
Windows 和 Linux 路径分隔符不同（ vs /），手动 find_last_of 容易漏掉网络路径、UNC 路径或带冒号的驱动器（如 C: ooar.txt），还可能被 \?C: 这类扩展路径搞崩。C++17 起 std::filesystem::path 是唯一能跨平台、语义正确处理这些情况的方案。
实操建议：
-
std::filesystem::path p("C:/temp/data.log");构造后，直接调用p.filename()得到"data.log"（含扩展名） - 要纯文件名（不含扩展名），用
p.stem()→"data" - 路径含尾部斜杠（如
"./src/"）时，filename()返回空path，不是"."或异常 —— 这是设计行为，不是 bug - 编译需加
-lstdc++fs（GCC）或确保 MSVC 19.20+ 启用了/std:c++17
Windows 下别硬写 strrchr 或 FindFirstFile
有人用 strrchr(path, '\') 再加 strrchr(path, '/') 双查，看似省事，实际在以下场景全跪：
- 路径是
"\\server\share\file.txt"（UNC）：第一个\是协议头，不能当分隔符切 - 路径含环境变量，如
"%TEMP%\log.txt"：未展开前根本不是合法路径 - 调用
FindFirstFile获取文件名，本质是绕路做 I/O，纯解析路径时完全没必要，还引入权限/访问失败风险
结论：只要不涉及真实文件存在性校验，就别碰 Win32 API 做路径解析 —— std::filesystem::path 已覆盖全部合法路径格式。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
filename() 和 stem() 的边界行为必须记清
这两个函数不抛异常，但返回值含义容易误解，尤其对相对路径和根路径：
-
std::filesystem::path("/").filename()→""（空 path），不是"/" -
std::filesystem::path("archive.tar.gz").stem()→"archive.tar"，只删最后一个.后部分；要彻底去扩展名得链式调用.stem().stem() -
std::filesystem::path("C:foo.txt").filename()→"foo.txt"（无盘符路径），而"C:\foo.txt"才被识别为绝对路径 - 路径末尾有
.或..（如"dir/."），filename()返回"."，不是空 —— 这符合 POSIX 语义，但业务逻辑里常需额外过滤
兼容旧编译器时的最小安全降级方案
若卡在 C++14 或 GCC 7 以下，std::filesystem 不可用，又不想引入 Boost，可有限度手写：
- 仅处理已知格式的本地路径（排除 UNC、扩展路径、符号链接目标）
- 统一先用
std::replace(path.begin(), path.end(), '\', '/')归一化分隔符 - 用
path.find_last_of('/')找位置，再检查是否为path.length()-1（即末尾是/），避免把"a/b/"解成"" - 绝不尝试解析
~、%VAR%、$HOME等 shell 特殊语法 —— 那该由上层调用者展开
真正麻烦的从来不是“怎么取文件名”，而是你不确定输入路径到底来自用户输入、配置文件还是系统 API 返回 —— 前两者几乎必然混着各种非法字符和未转义序列，这时候硬解析不如先丢给 std::filesystem::path 构造，靠它的构造函数自动标准化和验证。
