std::regex 性能差源于标准库回溯引擎未优化、构造时构建语法树、匹配时频繁动态分配与递归，且标准语义限制无法做深度优化；推荐用 RE2、PCRE2 封装或改用 string::find 等轻量方案。
std::regex 构造和匹配都慢，根本原因在标准实现上
绝大多数 C++ 标准库（libstdc++、libc++）的 std::regex 采用回溯（backtracking）引擎，且未做深度优化。它在构造 std::regex 对象时就完成完整语法树构建和部分编译，而真正匹配时仍频繁动态分配、递归调用、保存回溯状态——哪怕一个简单模式如 "a+b+" 在长文本中也可能触发指数级回溯。
更关键的是：C++11 标准对 std::regex 的语义要求（比如 ECMAScript 兼容性、捕获组编号规则、空匹配处理）迫使实现必须保留大量运行时检查，无法像专用正则库那样做 aggressive 常量折叠或 DFA 预编译。
libre2（C++）是目前最稳妥的生产级替代
Google 的 re2 库用有限自动机（DFA + lazy NFA 混合）实现，保证 O(n) 时间复杂度（n 是输入长度），不支持反向引用和某些高级断言，但换来的是可预测的高性能与防灾难性回溯。
-
RE2构造开销低，且支持RE2::Set批量编译多个模式并共享状态 - 默认禁用捕获组以提升速度；需捕获时用
RE2::FullMatch+std::string*数组，比std::smatch轻量得多 - 兼容 POSIX ERE 语法子集，大部分
std::regex的简单模式（"\d{3}-\d{4}"）可直接迁移
#include <re2/re2.h>
std::string text = "call 123-4567 now";
RE2 pattern(R"(\d{3}-\d{4})");
std::string number;
if (RE2::FindAndConsume(&text, pattern, &number)) {
// number == "123-4567"
}
如果必须用 C++17+ 且不能引入第三方，std::regex 可抢救的底线操作
不是完全放弃，而是避开已知性能雷区：
Access Gmail, Calendar, Drive, Docs, and Sheets via the gws CLI or Python.
立即学习“C++免费学习笔记（深入）”；
- 绝不重复构造
std::regex对象——把它声明为static const或类成员，复用编译结果 - 避免
std::regex_search/std::regex_iterator，改用std::regex_match（全匹配）或std::regex_replace（内部有缓存路径） - 禁用
ECMAScript语法，改用std::regex_constants::basic（POSIX BRE），减少解析负担（但功能更弱） - 对超长字符串，先用
std::string_view+find_first_of做粗筛，再进正则细筛
其他轻量选项：oniguruma 和 PCRE2 的 C++ 封装
oniguruma（Ruby 默认引擎）和 pcre2 都支持 JIT 编译，在长文本/高频匹配场景下比 std::regex 快 5–50 倍，但需手动管理内存和错误码。
推荐封装库：cpp-pcre2（头文件 only，自动 RAII 管理 pcre2_code）或 onigmo-cpp（C++17 接口封装）。它们保留了完整 PCRE2 功能（包括命名捕获、条件子组），又规避了 std::regex 的 ABI 不稳定和调试信息缺失问题。
真正棘手的地方不在“选哪个库”，而在于：很多团队把 std::regex 当成字符串查找的通用解法，却没意识到 90% 的场景其实只需要 std::string::find、absl::StrContains 或 hand-written 状态机——正则永远是最重的锤子，别见钉子就抡。
