c++oding="utf-8" ?>
regex_match要求整个字符串完全匹配正则，regex_search只需子串匹配即返回true；前者用于格式校验（如邮箱、日期），后者用于文本中查找（如日志提取ip）；误用会导致逻辑失败。
regex_match 和 regex_search 有什么区别
根本区别在于匹配模式： regex_match 要求整个字符串完全匹配正则，regex_search 只要子串匹配就返回 true。比如用 R"(d+)" 去匹配 "abc123def"，regex_match 返回 false，regex_search 返回 true。
常见误用是该用 regex_search 却写了 regex_match，结果逻辑始终不进分支。调试时可先打印 std::string 内容，确认是否含预期子串。
- 校验邮箱格式（整串合规）→ 用
regex_match - 从日志行提取时间戳（只需找一段）→ 用
regex_search - 想捕获多个分组？两个函数都支持
std::smatch，但必须传引用，否则匹配结果丢掉
编译器不报错但运行时崩溃或匹配失败
多数是正则字符串未正确转义。C++ 字符串字面量本身就要处理反斜杠，而正则引擎还要再解析一次。比如想匹配一个反斜杠，得写成 "\\"：第一个 \ 是 C++ 层转义为单个 ，第二个 \ 是正则层表示字面量反斜杠。
另一个高频坑是忘记指定 std::regex_constants::ECMAScript（默认值，通常不用显式写），但若用了 std::regex_constants::basic，语法就变成 POSIX BRE，不支持 +、? 等简写——这时 R"(w+)" 会直接抛 std::regex_error 异常。
- 用原始字符串字面量
R"(...)"能大幅减少反斜杠嵌套，推荐优先使用 - 构造
std::regex对象时加 try-catch，捕获std::regex_error并打印e.code()，比段错误好定位得多 - Clang 15+ 和 GCC 13+ 对 regex 支持较稳；MSVC 在 /std:c++17 下部分特性（如
regex_iterator）仍有 bug，慎用
如何提取多个匹配结果（比如所有数字）
不能只靠一次 regex_search，得用 std::sregex_iterator 遍历。它本质是个输入迭代器，底层调用 regex_search 并自动更新搜索起始位置。
注意：迭代器范围是左闭右开，且 end 迭代器必须用默认构造的 std::sregex_iterator()，不能传空 std::smatch 或其它值，否则 UB。
std::string s = "price: 199, discount: 49, total: 150";
std::regex r(R"(d+)");
for (std::sregex_iterator it(s.begin(), s.end(), r); it != std::sregex_iterator(); ++it) {
std::cout str()
- 如果正则含捕获组（如
R"((w+): (d+))"），it->str(1)取第一组，it->str(2)取第二组 - 性能敏感场景慎用：每次迭代都重新扫描，长文本 + 复杂正则可能明显拖慢；可考虑用
regex_search循环 +match[0].second手动推进位置 -
std::sregex_iterator不支持移动语义，别试图 std::move 它
为什么在 Windows 上用 std::regex 性能特别差
MSVC 的标准库实现（尤其是旧版本）对 std::regex 采用回溯解释器而非 DFA/NFA 编译，遇到像 .* 或嵌套量词的正则极易指数级回溯。同一段代码在 Linux（libstdc++/libc++）上毫秒级，在 MSVC 上可能卡数秒甚至触发栈溢出。
- 简单场景（如固定前缀匹配）直接用
std::string::find或starts_with更快更稳 - 复杂需求建议换库：PCRE2（
pcre2_compile）、RE2（Google，无回溯）、或 C++23 的std::regex新实现（尚未普及） - 若必须用 MSVC 自带 regex，避免
.*开头、禁用^和$锚点以外的多义量词，用[a-zA-Z0-9]+替代w+（防止 Unicode 相关开销）
regex 的坑不在语法难，而在跨平台行为和隐式性能成本。哪怕只是临时解析配置文件，也值得花两分钟验证下目标编译器的实际表现。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
