c++oding="utf-8" ?>
正确做法是用单词边界+显式起始断言：std::regex r(r"(d+)");匹配独立数字，如"123_backup.zip"中提取"123"，避免路径或扩展名中的数字被误捕。
用 std::regex 提取文件名里连续的纯数字（不带前缀）
直接上结论：C++11 起标准库支持 std::regex，但默认引擎对 Unicode 和边界处理较弱，提取「无前缀纯数字」必须显式锚定位置，否则容易把路径中的数字、扩展名里的数字也抓进来。
常见错误是写成 std::regex r("\d+")，结果 "log2024.txt" 提取出 "2024" —— 这不是你想要的「无前缀」，它前面紧挨着字母；而 "123_backup.zip" 本该取 "123"，却可能因贪婪匹配拿到 "123" 或整个 "123_backup" 中的其他数字段。
- 正确做法是用单词边界
\b+ 显式起始断言：std::regex r("(?，即「前面不是字母/数字/下划线，后面也不是」 - 更稳妥（尤其在 Windows 路径含反斜杠时）：先提取 basename（去掉路径和扩展名），再对纯文件名部分匹配
- 注意
std::regex在 GCC libstdc++ 中长期有性能 bug 和部分 PCRE 特性缺失，Clang libc++ 相对稳定；若需高可靠，建议降级用std::string::find_first_of手动扫描
手动剥离路径与扩展名后再提取数字（兼容性优先）
很多用户卡在第一步：正则还没跑，"./data/007_v2.log" 就让 std::regex 把 "007" 和 "2" 都拎出来了。根源是没先做 basename 处理。
使用场景：跨平台读取日志目录、批量重命名、按数字 ID 分组文件——这些操作都要求「只看文件名主体，不碰路径和后缀」。
- 用
std::filesystem::path（C++17）最干净：p.filename().stem().string()得到"007_v2" - C++11 可用
strrchr找最后一个'/'或'\'，再找最后一个'.'，手动截取中间部分 - 切忌直接对完整路径字符串跑正则——
"C:\temp\123.txt"里"123"前面是'\'，不属于\w，但"a123.txt"里的"123"就会被误伤
std::regex_iterator 多次匹配时的坑：只取第一个还是全收集？
你以为写个循环就能拿到所有数字段？错。多数需求只要「最前面那段独立数字」，比如 "20240501_report_final_v2.pdf" 应取 "20240501"，而不是全部 ["20240501", "2"]。
性能影响明显：对长文件名反复调用 std::sregex_iterator 构造开销不小，且每次都要重新编译正则（除非缓存 std::regex 对象）。
- 如果只要首个匹配，用
std::regex_search即可，别上iterator - 若真要全收集，记得检查
match[0].str()而非match.str()（后者可能含捕获组外内容） - 空匹配会导致迭代器失效——加一句
if (match.empty()) break;防崩
数字开头带零怎么办？stoi 会吃掉，但业务可能需要保留
提取出 "007" 后直接喂给 std::stoi，得到整数 7，再格式化回去就丢精度。这在版本号、编号系统、摄像头序列号等场景是硬伤。
典型错误现象："0001.jpg" → 1 → 保存为 "1_new.jpg"，破坏原始排序和语义。
- 如需保留前导零，别转整数，直接用
match.str()结果 - 如需比较大小，可用
std::lexicographical_compare（字符串比）或补零后转long long（注意位宽） - 正则本身无法区分
"007"和"7"，这是语义层问题，提取阶段只负责「原样捞出来」
真正麻烦的是混合模式：有些文件叫 "v123"，有些叫 "123_v2"，有些叫 "item_0042_final"。这时候光靠一个正则不够，得先分类再提取——没有银弹，得根据你的实际文件命名规则收口。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
