应使用std::sregex_iterator遍历所有匹配项并提取match.str()拼接，而非regex_replace“减法”；需检查迭代器有效性、避免负向断言回溯爆炸，并注意GCC旧版本兼容性问题。
正则匹配后如何安全提取符合模式的子串
直接用 std::regex 做“减法”（即剔除不符合项）容易误删——它不提供反向捕获接口，std::regex_replace 默认替换的是匹配部分，不是“非匹配部分”。真要保留符合正则的内容，本质是**提取匹配项再拼接**，而非“减去不符合项”。
常见错误现象：std::regex_replace(s, re, "") 看似在删掉匹配内容，结果却把想要的留下的部分全干掉了——因为正则写成了“匹配要保留的”，但 regex_replace 删的是匹配到的，逻辑反了。
- 正确做法：先用
std::sregex_iterator遍历所有匹配，把match.str()收集起来，再用std::string拼接 - 注意边界：如果原字符串含重叠匹配（如
"aaa"匹配"aa"），sregex_iterator默认不重叠，需手动控制起始位置 - 性能影响：频繁
+=拼接小字符串会触发多次内存重分配；建议预估大小后用reserve()
用 std::regex 提取数字和字母组合（例如 "abc123def" → "abc123"）
场景很典型：只留“由字母开头、后跟数字的单词”，其他全不要。这时候不能靠 regex_replace 一刀切，得靠迭代器精准抓取。
示例正则：R"([a-zA-Z]+[0-9]+)" —— 注意它不会匹配中间的 "def"，所以只提取出 "abc123"。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 必须检查
std::sregex_iterator是否有效：空匹配时迭代器等于std::sregex_iterator()，直接解引用会崩溃 -
match.str()返回的是std::string，不是视图，别试图用string_view去优化它——底层已拷贝 - 若需保留原始顺序中的多个匹配（如
"x12 y34 z56"），直接 push_back 即可；无需额外排序
为什么不用 regex_replace 做“剔除”更简单？
因为“剔除不符合正则的内容”等价于“保留符合正则的内容”，而 regex_replace 的替换目标是“匹配上的部分”，你没法直接告诉它“把没匹配上的全换成空”。有人试过写负向断言，比如 R"((?!pattern).)*"，但这种写法极易失控：
- 负向先行断言
(?!...)不消耗字符，配合*容易导致回溯爆炸，输入稍长就卡死 -
std::regex在 GCC libstdc++ 中对复杂负向断言支持不完整，Clang libc++ 表现也不一致 - 即便语法合法，替换逻辑也难读：你要 replace 的是“非匹配段”，但 regex 引擎并不天然暴露“未匹配区间”
所以，宁可多写两行循环，也别硬套 regex_replace。
兼容性与编译器坑点
std::regex 在 C++11 中引入，但早期实现（尤其 GCC 4.9–5.5）bug 很多：空匹配处理错、Unicode 支持缺失、堆栈溢出不抛异常。现在稳妥的做法是：
- GCC ≥ 7.3 或 Clang ≥ 7.0 才建议开启
-std=c++17使用std::regex - Windows MSVC 2019 起基本可用，但避免用
\p{L}这类 Unicode 类别——它根本不支持 - 若项目需跨平台且正则较复杂，直接换
RE2或PCRE2更省心；std::regex仅适合简单场景
真正麻烦的从来不是怎么写正则，而是不同 STL 实现对同一正则的行为差异——测试时务必在目标编译器上跑一遍真实输入。
