Sublime Text补全卡顿主因是索引策略与插件通信，非auto_complete_delay数值本身；应优化index_files、binary_file_patterns及插件独立延迟配置。
自动补全延迟由 auto_complete_delay 控制，但设太小反而卡顿
Sublime Text 默认的补全延迟是 50ms（auto_complete_delay: 50），这个值在低配机器或大项目里容易引发频繁触发、界面卡顿。不是越小越好——它本质是「防抖时间」，过短会导致编辑器反复中断当前操作去扫描符号表。
实操建议：
- 普通项目可设为
auto_complete_delay: 120，兼顾响应与稳定性 - 含大量第三方库（如 Python 的
numpy、pandas）时，建议200–300，避免sublime_jedi或anaconda插件反复加载 AST - 若关闭了所有语言服务（只用基础词典补全），可降至
30，但意义不大——真正影响体验的是后端分析，不是前端延时
auto_complete_size_limit 是性能关键，尤其对大文件
这个配置限制补全候选列表最多读取多少字符（默认 4194304，即 4MB）。一旦当前 buffer 超过该值，Sublime 会跳过文件内符号索引，导致补全仅依赖缓存或全局词典，看起来「不工作」。
常见错误现象：auto_complete 在 10MB 日志文件里完全失效，但新建小文件正常。
调整原则：
- 日常开发建议设为
auto_complete_size_limit: 1048576（1MB），足够覆盖绝大多数源码文件 - 不要盲目调高——增大该值不会提升补全质量，只会拖慢首次触发速度，并增加内存占用
- 配合
index_files: false（禁用项目索引）可进一步降低后台压力，适合只读大文件场景
插件级补全（如 Jedi、LSP）不受 auto_complete_delay 管控
原生 auto_complete_delay 只影响 Sublime 自带的「单词补全」和 sublime-completions 文件。Jedi、LSP、Anaconda 等插件走独立通信通道，它们的延迟由各自配置决定。
例如：
-
jedi插件：看settings -> "jedi_settings" -> "auto_complete_delay"（注意不是顶层 key） -
LSP插件：实际由 Language Server 决定，Sublime 侧仅控制请求节流，参数是"lsp_format_on_save": false类似开关，无直接 delay 设置 - 冲突点：如果同时启用多个补全源（如 Jedi + 原生），可能因响应时间不一致造成候选列表闪烁或重复项
真正拖慢补全的往往不是延迟，而是 index_files 和 binary_file_patterns
很多人调了 auto_complete_delay 发现没改善，问题其实在后台索引。Sublime 默认会对整个项目递归建立符号索引，而 node_modules、__pycache__、.git 这类目录会严重拖慢构建速度，进而让补全「等半天才出来」。
必须检查并加固这两项：
-
index_files: true（默认开启）——若不用项目级跳转（如goto_definition），可设为false -
binary_file_patterns必须显式包含：["*.jpg", "*.png", "*.zip", "node_modules/**", "__pycache__/**", ".git/**"]，否则索引线程会尝试解析二进制内容 - 额外技巧：在项目根目录加
.sublime-project，把folders里的path指向具体 src 目录，避开无关子树
补全延迟只是表象，背后是索引策略、插件通信、文件过滤三层耦合。改一个 auto_complete_delay 数值解决不了根本问题，重点得看它触发时，Sublime 正在忙什么。
