sublime的auto_complete_delay不是越小越好，本质是防抖时间：设太低（如5ms）导致频繁中断卡顿，设太高（如800ms）响应滞后；真实项目中120–300ms为兼顾流畅与准确的合理区间。
直接说结论：Sublime 的 auto_complete_delay 不是越小越好，它本质是防抖窗口——设太低（如 5）会让补全频繁中断、卡顿；设太高（如 800）又明显滞后；真实项目里，120–300 毫秒才是多数人兼顾流畅与准确的合理区间。
为什么改了 auto_complete_delay 还没反应？
常见错误现象：改完设置保存，输入 . 后补全框仍慢半拍，甚至不弹。
- 右下角语法标识不是目标语言（比如写 Python 却显示
Plain Text），auto_complete_selector会直接跳过该文件，补全压根不启动 -
auto_complete在用户设置里被设为false或根本没开启，整个功能处于关闭状态 - 你用的是 LSP 插件（如
LSP-pyright），而auto_complete_delay对 LSP 无效——它的响应节奏由语言服务器控制，Sublime 只负责转发请求 - 项目里有
node_modules或__pycache__，索引卡死导致所有补全类操作（包括Ctrl+P、Ctrl+R）整体变慢，延迟参数再调也没用
auto_complete_delay 设多少才真有用？
这个值必须结合你实际用的补全来源来定，不能一概而论：
- 纯原生补全（只靠当前文件单词 +
.sublime-completions文件）：30–50可行，但提升有限，容易误触发 - 中等规模项目（含
src/、tests/，无node_modules）：120是平衡点，打字不被打断，提示也跟得上 - 带
node_modules或 Python 虚拟环境的大项目：200–300更稳妥，给pyright或jedi留出 AST 解析时间，避免“敲完回车补全才出来” - 如果同时开了多个 LSP 服务（比如 Python + TypeScript），建议统一设到
250，防止某一个服务拖慢全局响应
比调延迟更关键的三件事
很多人盯着 auto_complete_delay 死磕，却忽略真正拖慢补全的底层负担：
- 禁用项目级索引：
"index_files": false加进用户设置，立刻停掉后台扫文件行为；若需部分跳转能力，改用"folder_exclude_patterns": ["node_modules", ".git", "__pycache__"] - 检查插件是否在“偷偷干活”：像
SublimeLinter、GitGutter这类插件，会在大文件加载后强行分析，导致 UI 冻结；可临时禁用它们验证是否是元凶 - 确认补全源是否就绪：LSP 类插件卡住时，别重装，先看状态栏左下角有没有
LSP: ready；没有就打开控制台（Ctrl+`），搜lsp或error查具体失败原因
真正影响体验的，往往不是那个毫秒级的延迟数字，而是 Sublime 正在后台扫描你根本不会去补全的几千个 .js 文件。调参前，先关掉那些它“不该干的活”。
