应采用动态规划二维数组实现，时间复杂度O(m×n)、空间O(m×n)，初始化首行首列，状态转移取删/插/替三者最小值加操作成本，注意索引边界和大小写统一处理。
编辑距离怎么算才不慢又不出错
直接用递归实现 edit_distance 函数很容易写错边界、爆栈，也慢——O(3ⁿ) 时间复杂度根本没法查词典。实际要用动态规划二维数组，空间 O(m×n)，时间 O(m×n)，m 和 n 是两个字符串长度。
关键点：初始化第一行/列表示「全删」或「全插」；状态转移只看三种操作（删、插、替），取最小值 +1（替换时若字符相等则不加 1）。
- 别忘了用
std::vector<:vector>></:vector>而不是裸数组，避免越界 - 字符串索引从 0 开始，DP 表维度设为
(s1.size() + 1) × (s2.size() + 1) - 常见错误：把
s1[i-1] == s2[j-1]写成s1[i] == s2[j]，导致越界或逻辑错
怎么快速找出最接近的拼写候选词
遍历整个词典挨个算编辑距离太慢，尤其词典超 10 万词时。必须加剪枝：一旦当前路径的累计距离 > 当前最优距离，立刻跳出内层循环；更进一步，可先按长度粗筛（比如只查长度差 ≤2 的词）。
如果词典固定且较大，建议预处理成 std::unordered_map<size_t std::vector>></size_t>，以长度为 key 分组，减少无效比较。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 阈值设为 2 或 3 比较合理：编辑距离 >3 的词基本不是拼写错误，而是换词了
- 注意大小写：统一转小写再比，但返回原词典中的原始形式
- 不要在循环里反复构造
std::string临时对象，传 const ref 或用string_view（C++17+）
为什么 Levenshtein 距离不够用？还得加权重
纯编辑距离对“teh”→“the”和“ab”→“ba”都给距离 2，但前者是典型打字邻键错误，后者更可能是乱输。真实纠错需要区分错误类型。
简单增强方案：把键盘布局建模成二维坐标，定义邻键替换代价为 0.5，而非邻键替换仍为 1；删除/插入保持为 1。这样 "teh" 到 "the" 的加权距离就变成 0.5，优先级更高。
- 只需改 DP 中的替换分支：
cost = (s1[i-1] == s2[j-1]) ? 0 : keyboard_cost(s1[i-1], s2[j-1]) - 小写字母映射表用
std::map<:pair>, double></:pair>或预计算的 26×26 数组 - 别为了“更准”堆砌规则——没词频模型支撑时，加权反而容易过拟合个别 case
实际调用时怎么避免内存和性能翻车
用户每敲一个字母就触发一次纠错？那必须缓存中间结果。例如输入 "helo"，先查 "h"、"he"、"hel" 的候选，再基于已有 DP 表增量更新到 "helo"，而不是重算四次。
更现实的做法是：只在用户停顿 ≥300ms 后触发完整纠错，并限制返回最多 5 个候选，且按距离升序 + 词频降序混合排序（词频可用静态统计如 Google Ngram）。
- 别用
std::endl频繁刷日志——它强制 flush，拖慢响应 - 词典加载用
mmap（Linux）或内存映射文件（Windows），避免启动卡顿 - 编辑距离函数务必声明为
constexpr（C++20）或noexcept，方便编译器优化
编辑距离本身很朴素，但嵌入到交互流程里，边界条件、缓存策略、IO 延迟才是实际卡点。别在核心算法上过度设计，先跑通单次查询，再逐个击破响应瓶颈。
