std::string::find 仅支持精确子串匹配，无法处理通配符、编辑距离或近似匹配等模糊需求；暴力枚举变形会导致时间爆炸，应改用 Levenshtein 滚动数组、剪枝 trie 或手工状态机等高效算法，并注意 UTF-8 编码与 Unicode 码点差异。
为什么不能直接用 std::string::find 做模糊匹配
std::string::find 只做精确子串查找，不支持通配符、编辑距离或近似匹配。一旦需求是“用户输错一个字母也想命中”“允许插入/删除一个字符”“匹配带 * 和 ? 的模式”，它就完全失效。
常见错误是硬套 find 加循环遍历所有可能变形，比如枚举所有 1-编辑距离的变体再查——时间爆炸，O(n × m × 26) 起步，实际项目里根本跑不动。
- 模糊匹配 ≠ 多次精确匹配；核心是把“相似性”建模成可计算的距离或状态转移
- 真正高效的做法是提前剪枝、复用中间结果，而不是暴力穷举
- 标准库没提供现成接口，必须组合算法或引入轻量级第三方逻辑
Levenshtein 距离适合短文本，但要注意空间优化
编辑距离是最直观的模糊指标，但朴素二维 DP 需要 O(m × n) 空间。对长度 100 的字符串，就要 10KB 内存；批量匹配时容易成为瓶颈。
实际用时应改用滚动数组——只保留两行：prev_row 和 curr_row，空间压到 O(min(m, n))。如果只关心是否 ≤ 某阈值（如 ≤2），还能进一步 early-exit：某行中最小值已超阈值，直接返回 false。
立即学习“C++免费学习笔记（深入）”；
- 阈值设为 0 → 等价于精确匹配；设为 1 → 容忍单字符替换/插入/删除
- 注意字符串编码：
std::string默认是 UTF-8，但 Levenshtein 通常按字节算——中文会出错；需先转std::u32string或用 ICU 库拆分 Unicode 码点 - 不要在热路径反复 new/delete 数组；建议预分配固定大小缓冲（如最大长度 256），复用
std::vector<int></int>
使用 std::regex 处理通配符模式时，避免回溯爆炸
C++11 起的 std::regex 支持 .*、.+ 等，但底层是回溯引擎。遇到像 a.*b.*c.*d 这类模式匹配长文本时，最坏复杂度指数级，几秒卡死很常见。
生产环境务必禁用 std::regex_constants::ECMAScript 默认语法中的贪婪量词滥用。更安全的做法是：把 * 替换为非贪婪等价写法，或改用 DFA 引擎（如 RE2 库）。
- 简单通配符（
?单字符、*任意长度）可用手写状态机，O(n) 稳定；boost::algorithm::wildcard就是这么实现的 - 若必须用
std::regex，加std::regex_constants::optimize标志，且提前检查 pattern 是否含嵌套*（如.*.*）——这类应拒绝输入 - 永远不要用
std::regex_search在大日志文件里搜模糊 pattern；先用std::string_view切块，再逐段匹配
大规模字符串集合匹配，优先考虑 trie + 编辑距离剪枝
当你要在 10 万词典中找与查询词编辑距离 ≤2 的所有候选，逐个算 Levenshtein 是 O(10⁵ × len²)，太慢。正确做法是建 trie，并在 DFS 过程中维护当前编辑距离，一旦超限立即剪枝。
关键优化点：每个节点存子树中最短词长和最长词长。若查询词长度减去当前距离已小于最短词长，跳过整棵子树；同理，超过最长词长也剪掉。实测对英文词典能减少 90%+ 的无效路径。
- 不要自己从零写
trie；用absl::flat_hash_map<char node></char>实现孩子指针，比std::map<char std::unique_ptr>></char>快 3 倍以上 - 编辑距离计算中，“替换”操作可合并进“插入+删除”，DFS 时统一用三个分支：跳过查询字符（删）、跳过词典字符（插）、字符相等则继续（匹配）
- 如果词典不变，可预计算每个节点的“最小编辑距离下界”（比如基于字符频率），进一步加速
trie。最容易被忽略的是字符编码边界——UTF-8 字节 vs Unicode 码点，一不留神就让“你好”变成三个匹配失败的字节。 
