推荐手写带剪枝的动态规划而非依赖第三方levenshtein库：用一维数组滚动更新、限制最大距离提前终止、结合长度/字符特征预筛、使用std::string_view避免拷贝，并叠加音似规则与常见错误映射提升纠错准确率。
编辑距离计算要用 levenshtein 还是自定义动态规划？
直接用第三方库（比如 levenshtein）看似省事，但 C++ 没有标准库内置该函数，多数所谓“levenshtein”头文件其实是用户自实现，且常忽略边界或优化。实际纠错不需完整编辑距离矩阵，只需限制最大允许距离（如 ≤2），否则对长词开销陡增。
推荐手写带剪枝的 DP：用一维数组滚动更新，外层循环目标词长度，内层限制步数上限。这样既可控又避免 std::string 频繁构造带来的隐式拷贝开销。
- 初始化
dp[j] = j表示空字符串变前 j 个字符的代价 - 每轮只保留当前行和上一行，空间从 O(mn) 降到 O(n)
- 一旦某行所有值 > 允许最大距离（如 2），立即
return -1 - 注意区分插入、删除、替换的代价——标准 Levenshtein 全设为 1，但拼写纠错中“替换相近字母”（如 i/1, o/0）可设为 0.5，需用
float或缩放为整数
候选词怎么快速筛选？暴力遍历字典太慢
全量计算每个字典词与输入的编辑距离，在万级词表下会卡顿。必须预筛：先按长度过滤，再用首尾字符、字符集交集等轻量特征淘汰明显不符项。
例如输入 "acress"，长度为 6，就跳过所有长度 ≠ {5,6,7} 的词；再检查是否含 'c' 和 's'，不含则跳过。这些判断比跑一次 DP 快 10–100 倍。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 构建字典时预存每个词的
length()、front()、back()、std::set<char></char>（或 bitset 压缩） - 用
std::unordered_set<:string></:string>存原始词，用std::vector存预处理结构体，避免重复解析 - 若字典固定，可进一步建倒排索引：以双字符 bigram（如 "ac", "cr"）为 key，映射到可能匹配的词 ID 列表
std::string_view 能不能用在编辑距离函数里？
能，而且应该用。传 std::string 会触发隐式构造和内存分配，而纠错场景中绝大多数输入是临时字符串字面量或已有缓冲区视图。编辑距离只读不改内容，std::string_view 完全满足。
但要注意：函数签名必须统一，否则混合使用 const std::string& 和 std::string_view 会导致重载歧义或静默转换。建议全部切到 std::string_view，并在调用处显式构造：
int dist = levenshtein_distance(std::string_view(input), std::string_view(dict_word));
- 避免在循环内反复调用
.data()+.size()，提前存成局部变量 - 如果字典词来自
std::vector<:string></:string>，可改为存std::vector<:string_view></:string_view>，但需确保原始字符串生命周期长于视图 - Windows 下注意
\r\n可能导致长度误判，纠错前先做简单 normalize（如删 \r）
为什么纠正 “recieve” 得不到 “receive”？
因为标准编辑距离无法感知音似或常见拼写规则，“i before e except after c” 这类知识不在 DP 范围内。单纯靠距离会把 “recieve” 和 “relieve”、“retrieve” 算得一样近（都是 1 替换），甚至因字母顺序更接近而优先返回错词。
- 必须叠加规则层：对特定错误模式（如
"ie"vs"ei"）打分加成，或在距离相同时按规则置信度排序 - 预置常见错误对映射表：
std::map<:string std::vector>></:string>，如{"recieve": {"receive"}}，查表优先于 DP - 小写字母比较前务必调用
std::tolower，否则大小写混用（如 "iPhone"）会导致距离虚高
真正难的不是算距离，而是让程序知道“哪些错更可能、哪些音更像、哪些词更常用”。编辑距离只是骨架，血肉得靠语料统计和领域规则补上。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
