std::regex在C++11+中运行失败主因是编译器未启用C++11及以上标准或libstdc++版本过旧；GCC≥4.9需加-std=c++11和-D_GLIBCXX_USE_CXX11_ABI=1，MSVC2015+可用但性能差；应优先用string::find等替代，慎用.*，区分regex_match（全串匹配）与regex_search（子串匹配），复用regex对象，复杂场景改用boost::regex或re2。
std::regex 在 C++11+ 里跑不起来？先检查编译器和标准
很多同学写完 std::regex 代码一编译就报错，或者匹配结果总为空——大概率不是写错了，而是编译器没开 C++11 或更高标准，或者用了不支持完整正则引擎的旧版 libstdc++（比如 GCC 4.8 默认的）。Clang 和较新 GCC（≥4.9）用 -std=c++11 或更高能跑，但 MinGW-w64 某些版本仍会 fallback 到 ECMAScript 子集，\d 可能不认，std::regex_constants::icase 可能被忽略。
- 确认编译命令带
-std=c++11（或c++14/c++17） - GCC ≥ 4.9 推荐加
-D_GLIBCXX_USE_CXX11_ABI=1避免 ABI 不一致导致崩溃 - Windows 下 MSVC 2015+ 基本可用，但
std::regex性能差、回溯易卡死，别在循环里高频调用 - 简单场景优先用
std::string::find+std::string::substr模拟通配符，比正则快一个数量级
模糊匹配常用模式怎么写才不翻车
写 std::regex 时最容易把“模糊”理解成“随便匹配”，结果写出 .* 开头的表达式，一遇到长字符串就栈溢出。实际中真正需要的往往是子串包含、前缀/后缀、或有限通配（如 file_*.log 这种）。
-
file_.*\.log：注意点号要转义，否则匹配任意字符；\.是字面量点 - 忽略大小写：传
std::regex_constants::icase标志，不是在 pattern 里写(?i)（libstdc++ 不支持内联标志） - 匹配中文或 Unicode：C++ 标准库 regex 不支持 UTF-8 自动解码，pattern 和输入都得是 UTF-8 字节流，且不能依赖
\w匹配汉字（它只认 ASCII） - 想实现类似
gitignore的规则？别硬套std::regex，用std::string手写前缀/后缀/星号分段判断更稳
性能崩了怎么办：regex_search vs regex_match vs regex_replace
这三个函数行为差异极大，选错一个，CPU 就开始发热。最常见错误是该用 regex_search 查子串，却写了 regex_match，结果永远返回 false——因为后者要求**整个字符串完全匹配**。
-
regex_match("abc123", r)：只有r能吃掉整个 "abc123" 才返回 true -
regex_search("abc123", r)：只要中间某段符合（比如\d+）就返回 true -
regex_replace会拷贝整个字符串，大文本慎用；若只需判断存在性，别调它 - 频繁匹配同一 pattern？把
std::regex对象提出来复用，别每次 new 一个——构造开销远大于匹配本身
替代方案：什么时候该放弃 std::regex
如果你只是想做文件名通配、日志关键词提取、或 URL 路径匹配，std::regex 很可能是杀鸡用牛刀。它的标准实现质量参差不齐，调试困难，错误信息全是 std::regex_error 加个数字码，没法告诉你哪错了。
立即学习“C++免费学习笔记（深入）”；
- 通配符（
*/?）：用glob库（如cppglob）或手写双指针匹配，10 行搞定 - 关键词高亮或简单提取：
std::string::find_first_of+std::string_view切片，零分配 - 真需要 PCRE 级能力？直接上
boost::regex或re2（Google 的 C++ 正则库，无回溯、线程安全），但得额外链接 - 跨平台打包时，
std::regex在 Android NDK 或 iOS 上可能被阉割，提前测
正则的坑不在语法，而在不同 STL 实现对标准的执行程度。写之前先问自己：这个模糊，是不是非得靠回溯不可？
