候选列表顺序由提供商priority值决定，权重越大越靠前；可通过provider: toggle debug mode命令查看已启用provider及其priority值，修改需直接编辑对应配置文件并确保scope匹配正确。
补全候选列表的顺序不是随机的，而是由提供商（provider）的 priority 值决定；改错位置或漏设权重，会导致你常写的函数永远沉底。
怎么看当前启用的补全提供商？
打开命令面板（Ctrl+Shift+P 或 Cmd+Shift+P），输入并执行 Provider: Toggle Debug Mode。编辑器底部会弹出一个面板，列出所有已激活的 provider 及其当前权重（priority 值）。注意：未启用的 provider 不会显示，比如禁用的 autocomplete-snippets 就不会出现在列表里。
- 权重值越大，越靠前；默认多数 provider 是 30，
autocomplete-snippets是 50，所以片段通常优先于语言级补全 - 同一 provider 多次加载（如被多个包引入）可能导致重复条目，需检查包冲突
- 部分 provider（如
language-rust-bundled）会在自己的 settings 目录下维护独立的.cson配置，不走全局设置
怎么修改某个 provider 的优先级？
直接编辑对应 provider 的配置文件，而不是在 Atom 设置 UI 里调——UI 里没有暴露该字段。例如想提升 CSS 补全权重：
apm list --packages | grep autocomplete-css
找到路径后，编辑其 settings/autocomplete-css.cson（或类似路径），添加或修改：
'autocomplete-plus':
'provider':
'priority': 60
- 必须是整数，不能写
"60"字符串 - 改完不用重启 Atom，但要重新触发一次补全（比如删一个字符再输）才能生效
- 如果 provider 来自社区包（如
autocomplete-python），它的配置文件可能在~/.atom/packages/autocomplete-python/settings/下，而非language-xxx包内
为什么改了 priority 还没效果？
常见失效原因不是配置错，而是触发上下文压过了权重逻辑：
- 你在
.js文件里敲doc，autocomplete-html不会出现——它只在.html或.erb等 scope 下激活，和 priority 无关 - 输入长度低于
minCharacterCount（默认 2），补全根本不会弹，权重再高也没用 - 当前光标位置在字符串字面量内（如
"foo.bar."），多数 provider 会主动退场，只剩autocomplete-snippets留守 -
autocomplete-plus的 blacklist 配置项屏蔽了当前 grammar，比如'.source.gfm'被加进黑名单，Markdown 文件里就看不到任何补全
如何让自定义 snippet 排到最前面？
默认 autocomplete-snippets 优先级是 50，但如果你的 snippet 属于特定 scope（比如只在 .rs 文件生效），而当前文件是 .ts，那它根本不会参与排序。真正可靠的做法是：
- 确保 snippet 的
scope正确匹配当前 grammar（查Editor: Log Cursor Scope命令输出） - 在 snippet 定义中显式设
priority: 90（支持该字段的 snippet provider 才认） - 避免用通配 scope（如
'*'），否则可能被其他 provider 的更精确 scope 抢先匹配 - 如果依赖
autocomplete-plus默认行为，别动它的内置 blacklist，否则 snippet 可能被静默过滤
真正难调的从来不是数字大小，而是 scope 匹配链和 provider 激活时机——这两个地方一错，priority 再大也白设。
