不能直接用JaroWinkler做拼写纠错，因其仅返回相似度分值，不生成候选词、不建索引、不处理大小写/空格归一化，也无top-1自动选择能力；需补全候选生成、打分过滤、结果排序三模块。
直接用 JaroWinkler 做拼写纠错不现实——它只返回相似度分值，不生成候选词、不建索引、不处理大小写/空格归一化，更不会自动选 top-1 修正结果。真要落地为“纠错引擎”，必须补全三块：候选生成、打分过滤、结果排序。
为什么不能直接调 JaroWinkler 函数就完事
常见错误是把 JaroWinkler 当成黑盒纠错器：输入错词，期望它吐出正确词。实际它只是个两两比较函数，比如 JaroWinkler("recieve", "receive") 返回 0.92，但你得先有 "receive" 这个候选，它才打得上分。
- 没候选词源 → 算再准也无词可纠
- 没预处理 →
"John"和"JOHN "直接比会拉低分值 - 没阈值控制 →
"cat"对"dog"也能算出0.0，但你不想让它进结果列表 - 没去重/排序逻辑 → 同一正确词可能被多个变体（
"color"/"colour"）同时匹配，得分还接近
候选词怎么来：字典 + 编辑距离生成双策略
纯靠大词典查表太死板，纯靠编辑距离生成又爆炸。推荐组合用：
- 主词典：加载常用词表（如
en_us.dict），全部转小写并去首尾空格，存进map[string]struct{} - 邻近生成：对输入错词，用
Levenshtein生成编辑距离 ≤2 的所有字符串（注意剪枝：长度差 >2 直接跳过；生成时限制字符集为 a-z） - 交集过滤：只保留既在词典中、又在邻近生成集合里的词 —— 这步能砍掉 90%+ 垃圾候选
示例：输入 "recive"，Levenshtein 生成 ["recieve", "receive", "recipe"]，词典里只有 "receive" 和 "recipe" 存在，最终候选就这两个。
立即学习“go语言免费学习笔记（深入）”；
打分与排序：Jaro-Winkler 要加权，不能裸用
JaroWinkler 对前缀敏感，但原始实现对大小写、空格、标点零容忍。上线前必须做三件事：
- 统一预处理：对输入词和每个候选，都执行
strings.ToLower(strings.TrimSpace(s)) - 加前缀惩罚：如果两个字符串首字母不同，强制把
JaroWinkler分值 × 0.7 —— 避免"apple"和"apply"因前缀长而高分误判 - 长度补偿：若候选词长度与原词差 >1，额外 ×
math.Max(0.5, 1.0-float64(abs(len(cand)-len(input)))/10)，防止超长词占便宜
最后按加权分降序排，取前 3 个返回即可。别硬卡 >0.85 阈值——短词（如 "UK" vs "US"）天然难打高分。
Go 实现关键点：避免重复计算和内存泄漏
高频纠错场景下，JaroWinkler 被反复调用，要注意：
- 不要每次调用都新建切片：把
s1和s2的 rune 切片缓存在函数内，用sync.Pool复用 - 匹配窗口计算别写错：
w := int(math.Floor(float64(maxLen)/2)) - 1，注意maxLen=0时要 guard（空串直接返回 0） - 换位数统计必须严格按匹配顺序提取字符再比对，不能只比索引 —— 否则
"abc"和"acb"会漏掉换位 - 如果词典超 10 万词，别用纯内存 map 查找，改用
go-adaptive-radix-tree或预建 n-gram 倒排索引加速候选筛选
真正卡住性能的往往不是 JaroWinkler 本身，而是候选池过大或预处理没做缓存。上线前用 pprof 看下 runtime.mallocgc 占比，超过 30% 就该优化内存分配了。
