调小 delayTime 通常无效，因它只控制请求触发时机而非响应速度；真正瓶颈在 provider 性能、LSP 延迟或系统输入节奏。
调小 delayTime 通常能见效，但多数卡顿根本不在这个参数上——它只控制“等多久发请求”，不决定“请求多久回来”。真正拖慢补全的，是 provider 性能、LSP 服务延迟或系统级输入节奏。
autocomplete-plus 的 delayTime 怎么设才有效
这是最常被误操作的地方。默认值 100 是防干扰设计，不是性能缺陷。
- 设为
30或50可让doc→document更快弹出，改完 Settings → Packages →autocomplete-plus→ Delay Time (ms) 后立即生效 - 不要设成
0：快速连打时会触发大量无效请求，尤其搭配autocomplete-ternjs这类重 provider，UI 直接卡住 - 验证是否真生效：运行
atom --safe（禁用所有第三方插件），再测试补全响应——如果还慢，说明问题在别处
为什么调了 delayTime 还是慢
因为 delayTime 只管“等多久开始问”，不管“问完多久回来”。瓶颈往往在 provider 层：
-
autocomplete-ternjs首次要解析整个项目 AST，常卡 300–800ms；换成轻量的autocomplete-javascript能明显缓解 -
atom-autocomplete-php没跑过ctags -R .或没勾选 “Use local ctags”，就会 fallback 到慢路径 -
ide-typescript或atom-ide-ui下，delayTime根本不生效——它走 LSP 协议，延迟由 TypeScript Server 控制，得去插件设置里调Debounce Delay (ms)
TabNine 补全卡顿或建议错乱
TabNine 不是“装了就快”，它和 autocomplete-plus 存在抢权关系，且依赖本地索引质量：
- 必须禁用
autocomplete-plus的Enable Auto Completion，并确保 TabNine 设置页勾选了Use TabNine as primary provider，否则建议根本不上屏 - 首次打开项目时，右下角显示
TabNine: indexing是正常现象，持续几十秒到几分钟；别提前关 Atom，否则索引中断，项目内变量永远不进补全词库 - 关闭
Enable Deep Completion，改用Inline Completion；把Minimum confidence threshold提高到0.7或0.8，过滤低质建议
最容易被忽略的是层级混淆：你以为在调“debounce”，其实同时在动编辑器层的触发时机、provider 层的数据获取效率、系统层的按键重复节奏。这三个层面各自独立，混着调只会掩盖真实瓶颈。
