sublime text代码提示慢主因是无意义目录索引，应禁用index_files或配置folder_exclude_patterns排除node_modules等；auto_complete_delay设200–300ms适配大项目，lsp问题需检查服务状态而非重装。
Sublime Text代码提示慢，90%不是编辑器本身卡，而是它在拼命扫描node_modules、__pycache__、.git这些你根本不会去补全的目录——索引一卡，Ctrl+R、Ctrl+P、点.后弹窗全跟着卡。
怎么关掉无意义的项目级索引
禁用index_files是最立竿见影的操作，它直接让Sublime跳过整个项目的符号扫描，不建索引，自然不卡。这不是“阉割功能”，而是把补全交给更专业的插件（如LSP）或本地词典来处理。
- 打开
Preferences → Settings – User，添加："index_files": false - 若你仍需部分项目内跳转（比如
Ctrl+Click进自己写的模块），改用排除法，而非全局开启索引 - 别信网上说的
"index_workers": 1能提速——线程数调小只是把卡顿藏得更深，扫描量没变，CPU照样打满
auto_complete_delay设多少才真有效
auto_complete_delay不是越小越好。它本质是防抖时间：设太低（如50），你敲requests.还没输完，Sublime就已中断三次去查符号表；设太高（如800），又明显感知延迟。关键要看你用什么补全源。
- 纯原生补全（只靠当前文件单词+
.sublime-completions）：可设"auto_complete_delay": 30，但意义不大 - 中等项目（含
src/和tests/）：推荐120，响应快且不打断输入流 - 带
node_modules或Python虚拟环境的大项目：必须设200–300，给Jedi或pyright留出AST解析时间 - 注意：这个参数对LSP插件无效——LSP的响应节奏由语言服务器（如
pyright）决定，Sublime只做请求节流
folder_exclude_patterns比插件开关还管用
很多人停用SublimeCodeIntel或LSP后仍卡，是因为Sublime原生索引还在后台扫node_modules。真正有效的过滤，得在编辑器底层做。
- 在
Settings – User里加："folder_exclude_patterns": ["node_modules", ".git", "__pycache__", "dist", "build"] -
"file_exclude_patterns": ["*.log", "*.tmp", "*.swp"]防止误读临时文件 -
"binary_file_patterns": ["*.pdf", "*.zip", "*.jpg"]避免编辑器尝试高亮二进制内容导致UI线程阻塞 - 右下角语法显示为
Plain Text却在写Python？补全必然失效——先点语法名切换回Python，再调参数
LSP类插件卡住时别重装，先看状态栏
LSP补全不弹，大概率不是配置错，而是服务没真正就绪。Sublime只管发请求，不负责等服务器启动完成。
- 右下角显示
LSP-pyright starting...？说明pyright进程没起来，终端执行pyright --version确认是否安装成功 - 显示
LSP-pyright active但补全不动？等2–5秒，尤其首次打开大项目时，pyright需要加载类型库 - 控制台（
Ctrl+`）报ImportError或timeout？代表插件在后台反复失败重连，此时应停用它，而非调auto_complete_delay - 同时启用Jedi + LSP？会出现候选重复、列表闪烁——这不是延迟问题，是补全源冲突，必须禁掉其中一个
最常被忽略的一点：auto_complete_size_limit默认4MB，但一个10MB的日志文件会直接跳过索引，补全“失效”其实是编辑器主动放弃。设成1048576（1MB）反而更稳——补全本就不该发生在日志或构建产物里。
