atom模糊匹配基于子序列匹配：输入字符须按序出现在候选词中且首字母吻合，如bgc匹配background-color；不依赖语义理解或编辑距离，大小写不敏感但影响排序权重。

Atom 的模糊匹配不是“智能联想”，而是基于字符子序列的快速筛选，bgc 能匹配 background-color 是因为字母顺序一致、不跳过首字母，不是靠语义理解。

模糊匹配实际怎么工作的？

autocomplete-plus 默认用的是子序列匹配（subsequence matching），不是编辑距离或 n-gram。它检查你输入的字符是否按顺序出现在候选词中，且首字母必须吻合。

• docu → 匹配 document（d-o-c-u 都在 document 中按序出现）
• bc → 不匹配 background-color（b 和 c 之间跳过了太多字符，且 c 不是第二位）
• bgc → 匹配 background-color（b-g-c 按序、且 b 是首字母）
• 大小写不敏感，但首字母大小写会影响排序权重：输入 Console 会把 console 排更前

想改匹配逻辑？别动核心，换 provider 或加 filter

你不能直接修改 autocomplete-plus 的模糊算法，它硬编码在 filterSuggestions 方法里。但可以绕过：

• 用自定义 provider 替换默认行为：比如写一个 autocomplete-javascript-fuzzy，在 getSuggestions 返回前自己调用 fuzzysort.go 或 string-similarity
• 在 suggestionList 显示前拦截：监听 autocomplete-plus:shown 事件，用 atom.workspace.getActiveTextEditor().getSuggestions() 拿到原始列表再重排
• 禁用默认模糊：设置 autocomplete-plus 的 minimumWordLength 为 1，再配合 strictMatching: true（这时只做前缀匹配，con 只出 const、console，不匹配 document）

自定义 snippet 补全也走模糊匹配？不，它走 scope + 前缀精确匹配

snippet 补全（比如输 for 回车出循环）和 provider 补全是两套机制：snippets 插件只看光标前文本是否**完全等于** snippet 的 prefix 字段，不模糊、不子序列、不忽略大小写。

• 定义了 prefix: "for"，那必须敲完 f-o-r 三个字母，少一个都不触发
• prefix: "For" 和 prefix: "FOR" 是三个不同 snippet，不会互相匹配
• scope 错误比匹配逻辑更常导致失效：确保 scope: "source.js"，而不是 "javascript" 或 "text.html.basic"
• 修改 snippets.cson 后不用重启 Atom，但要执行 Reload Window（Cmd+Shift+P / Ctrl+Shift+P）才生效

为什么有些插件看起来“更智能”？其实是预过滤 + 多级 fallback

像 atom-autocomplete-modules 或 atom-ternjs 并不是改了模糊算法，而是提前缩小了候选池：

• atom-autocomplete-modules 先扫描 node_modules 和 webpack.config.js，只把真实存在的路径塞进 suggestions 列表，再交给 autocomplete-plus 模糊匹配
• atom-ternjs 启动本地 Tern 服务，分析 JS AST，返回的 suggestion 已经是“可能被调用的函数”，getSuggestions 返回的列表本身就很精准，模糊匹配只是锦上添花
• 如果你发现某个 provider 响应慢，大概率是它在 getSuggestions 里做了同步文件 I/O 或网络请求——这不是模糊匹配的问题，是 provider 实现缺陷

真正难调的不是匹配逻辑，是 provider 返回的建议质量。模糊匹配再快，给一堆无关项也没用；而一个只返回 3 个高相关项的 provider，哪怕关掉模糊、只用前缀匹配，体验也更好。