<p>std::regex 不适合轻量通配符匹配，因其默认支持完整正则语义、启动开销大、过度解析 * 和 ?，而手写逻辑更可控、更快、noexcept 且无依赖。</p>
为什么 std::regex 不适合轻量通配符匹配
因为 std::regex 默认支持完整正则语义（如捕获组、回溯控制、Unicode），启动开销大，且对 * 和 ? 这类简单通配符会过度解析。实际项目中若只需 POSIX shell 风格匹配（? 匹配单字符，* 匹配任意长度子串），手写逻辑更可控、更快、无依赖。
常见错误是直接把 std::regex 当作通配符引擎用，结果在嵌入式或高频调用场景下触发大量内存分配和状态机跳转，CPU cache 友好性差。
- 通配符模式不含
^、$、[a-z]等扩展语法时，不必引入正则库 -
std::regex构造函数本身可能抛std::regex_error，而手写逻辑可全程noexcept - 递归实现若未加记忆化，最坏情况会退化成指数级（如
"****"匹配长字符串）
递归解法：如何避免重复计算和栈溢出
核心思路是按字符逐位推进：遇到普通字符直接比；遇到 ? 跳过一位；遇到 * 则尝试“匹配 0 个”或“匹配至少 1 个”，形成分支。
关键陷阱是不加缓存的朴素递归——比如模式 "a*b*c" 匹配 "aaabbbccc" 时，* 的多次分叉会导致同一子问题（如 s[3..] vs p[2..]）被反复计算。
立即学习“C++免费学习笔记（深入）”；
- 必须用二维
memo[i][j]记录s.substr(i)是否能被p.substr(j)匹配，类型为std::optional<bool></bool>或三态数组（-1=未算，0=false，1=true） - 递归出口要覆盖三种边界：
j == p.size()（模式耗尽，要求文本也耗尽）、i == s.size()（文本耗尽，模式剩余只能全是*） - 不要用
std::string::substr()传参，改用索引 + 引用，避免构造临时子串
示例关键判断：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
if (memo[i][j].has_value()) return memo[i][j].value();
if (j == p.size()) return i == s.size();
if (i == s.size()) return std::all_of(p.begin() + j, p.end(), [](char c) { return c == '*'; });
动态规划解法：状态转移怎么对应通配符语义
DP 表 dp[i][j] 表示 s[0..i) 是否匹配 p[0..j)。难点在于 * 的转移：它既能“吃掉”当前字符（dp[i][j] = dp[i-1][j]），也能“跳过自身”（dp[i][j] = dp[i][j-1]）。
容易错的是初始化和 * 的双重含义。比如空字符串匹配 "*" 应为 true，但匹配 "a*" 就是 false——这要求第一行（i=0）必须显式扫描模式前缀是否全为 *。
-
dp[0][0] = true（空串匹配空模式） - 第一行：
dp[0][j] = (p[j-1] == '*' && dp[0][j-1]) - 普通字符或
?：dp[i][j] = dp[i-1][j-1]（前提是字符匹配） -
*：dp[i][j] = dp[i-1][j] || dp[i][j-1]（前者表示 * 多吃一个，后者表示 * 匹配零个）
空间可优化为一维数组，但需从右往左更新，否则覆盖未使用的旧值。
实际部署时要注意的边界细节
用户常忽略模式开头/结尾的 * 对行为的影响。例如 "*txt" 应匹配 "report.txt"，但若 DP 初始化漏掉首行全 * 判断，就会返回 false。
另一个隐蔽问题是编码安全：若输入来自不可信源，需提前检查 p 中是否存在非预期字符（如 \0、控制字符），否则可能造成越界或逻辑误判。
- 禁止将
std::string直接传给 C 风格函数（如strcmp），必须用c_str()且确认已 null-terminated - 若需支持 Windows 路径中的反斜杠，应在预处理阶段统一转义，而非在匹配逻辑里特殊处理
- 递归深度限制建议设为 1000 层以内，超限时降级到 DP 解法，避免栈溢出
最复杂的点其实是模式规范化：连续多个 * 等价于单个 *，但很多实现直接跳过这步，导致在极端模式下性能骤降。这个压缩步骤不能省。
