fnmatch是POSIX C函数，C++标准库不提供原生支持；Linux/macOS需用<fnmatch.h>并注意FNM_PATHNAME等标志，Windows则用PathMatchSpec，跨平台需封装适配。
为什么 fnmatch 在 C++ 里不能直接用
因为 fnmatch 是 POSIX 标准的 C 函数，C++ 标准库（包括 <filesystem>）不提供原生支持。你在 Linux/macOS 上能调用它，是因为头文件 <fnmatch.h> 存在；Windows 默认根本没这玩意儿，连编译都过不去。别指望 std::regex 能直接替代——它的语法和通配符（*、?、[a-z]）不兼容，写个 "*.log" 还得手动转成 R"(\.log$)"，既易错又难读。
Linux/macOS 下用 fnmatch 的正确姿势
要安全调用，得注意三个细节：路径分隔符、匹配标志、错误返回值。尤其当你要匹配带目录的路径（比如 "logs/*.err"），fnmatch 默认不处理斜杠，必须加 FNM_PATHNAME 标志，否则 * 会跨目录乱匹配。
- 包含头文件：
#include <fnmatch.h> - 调用时务必传
FNM_PATHNAME | FNM_NOESCAPE（后者避免反斜杠被误解释） -
fnmatch返回0表示匹配成功，非零（如FNM_NOMATCH）才是不匹配，别写成if (fnmatch(...) == true) - 示例：
int ret = fnmatch("*.tmp", "cache_v2.tmp", FNM_PATHNAME | FNM_NOESCAPE); // ret == 0
Windows 下怎么搞等效功能
Win32 API 没有 fnmatch，但有 PathMatchSpec（需 #include <shlwapi.h>，链接 shlwapi.lib），行为最接近：支持 * 和 ?，且自动处理反斜杠。不过它不支持字符范围 [a-z]，也不区分大小写（Windows 默认不区分），这点和 POSIX fnmatch 加 FNM_CASEFOLD 不同。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 函数原型是
BOOL PathMatchSpec(LPCSTR pszFile, LPCSTR pszSpec)，参数顺序和fnmatch相反 - 只接受 ANSI 字符串，Unicode 需先用
WideCharToMultiByte转换，或改用PathMatchSpecW（但部分旧 SDK 不支持） - 若需跨平台统一接口，建议封装一层：
bool match_pattern(const std::string& filename, const std::string& pattern) { #ifdef _WIN32 return PathMatchSpec(filename.c_str(), pattern.c_str()) != FALSE; #else return fnmatch(pattern.c_str(), filename.c_str(), FNM_PATHNAME | FNM_NOESCAPE) == 0; #endif }
用 std::filesystem 遍历 + 通配符过滤的坑
std::filesystem::directory_iterator 本身不支持通配符过滤，很多人误以为 std::filesystem::glob 存在——它并不存在。你得自己遍历再调用匹配函数，但要注意：频繁调用 fnmatch 或 PathMatchSpec 对长路径性能影响不大，但若在循环里反复构造 std::string 或调用 path.filename().string()，会产生大量临时对象。
立即学习“C++免费学习笔记（深入）”；
- 推荐提前提取文件名：
auto fname = entry.path().filename().string()，避免每次匹配都重复计算 - 如果模式固定（如只过滤
"*.jpg"），可预编译成正则（std::regex），但注意std::regex构造开销大，别在循环里 new - 绝对路径匹配时，
fnmatch的FNM_PATHNAME会让"**/*.cpp"这种双星失效——POSIXfnmatch本来就不支持**，那是 shell 的扩展，得自己递归处理
[a-z] 这类模式在 Windows 下直接被忽略——这点容易漏测。 
