sublime text 启用 lsp 后变卡的主因是通配符配置（如"scopes": ["*"]）导致任意文件都启动语言服务器，叠加日志冗余、cpu满载及旧插件冲突；应限定scope、调低log_level、禁用冲突插件并限制服务器资源。
Sublime Text 启用 LSP 后变卡，不是硬件问题，而是语言服务器启动过多、日志冗余、语法范围匹配过宽或插件冲突导致的资源争抢——关掉默认启用的“全语言兜底”配置，就能明显提速。
为什么一开LSP就卡？关键在clients里写了不该写的通配
LSP 插件默认不启动任何服务，但很多人照着教程在 clients 里加了类似 "scopes": ["*"] 或 "syntaxes": ["*"] 的配置，结果打开任意文件（比如 README.md、.gitignore）都尝试拉起语言服务器。clangd、pyright 这类进程一开就是百MB内存，多个并行直接拖慢 UI 响应。
- 必须显式限定 scope 和 syntax：Python 只写
"scopes": ["source.python"]，TS 只写"scopes": ["source.ts", "source.tsx"] - 检查当前文件真实 scope：按
Ctrl+Alt+Shift+P（macOS 是Cmd+Alt+Shift+P），右下角显示什么就配什么，别凭感觉写source.js—— Sublime 4+ 已改用source.javascript - 禁用未使用的 clients：在
LSP.sublime-settings里把暂时不用的语言 client 整个删掉，别留"enabled": false，LSP 仍会扫描匹配
log_level设太高会让Sublime反复刷屏写日志
默认 "log_level": 1（INFO 级）已足够排错，但有人为“看得清”设成 2（DEBUG），结果每次光标移动、保存、切换标签都触发大量 JSON-RPC 日志写入，尤其 Windows 下磁盘 I/O 成瓶颈，编辑时明显卡顿。
- 日常使用保持
"log_level": 0（ERROR）或1；只有排查连接失败时才临时切到2 - 关闭实时日志面板：
Preferences → Package Settings → LSP → Toggle Log Panel关掉它，避免 Sublime 渲染长日志流 - 日志路径本身不占内存，但高频写入 + UI 渲染 = 卡顿源；
"log_file"配置项可保留，但别同时开着面板
pyright/clangd等服务器默认吃满CPU，得手动限频
pyright 默认启用 full type checking，clangd 默认索引整个项目树——它们不会自动降级，哪怕你只改一行 .py 文件。后台分析线程持续跑满一个 CPU 核，UI 就会掉帧。
- pyright 加
"initializationOptions": {"typeCheckingMode": "basic"}，跳过第三方库类型校验 - clangd 启动加
--limit-results=50参数，避免符号搜索返回上千结果 - 所有 command 数组末尾加
--stdio（如["pyright", "--stdio"]），确保走标准流而非 socket，减少握手开销 - Windows 用户注意：不要用
pyright-langserver（旧名），它已弃用且无 CPU 限制逻辑；只用pyrightCLI
别让LSP和旧插件抢同一个功能
Anaconda、SublimeCodeIntel、GoSublime 这些老插件和 LSP 共存时，会各自监听 on_modified 事件、重复解析 AST、互相覆盖补全列表——最终表现是补全弹出慢半拍、F12 跳转随机失效、CPU 持续 70%+。
- 确认冲突：关掉 LSP，只开 Anaconda，看是否还卡；再反过来，只开 LSP，关其他——对比 CPU 占用
- 必须禁用 Anaconda：它和 LSP-pyright 冲突最典型，禁用后重启 Sublime 才生效
- Go 用户别装 GoSublime：它自带 gocode，与
gopls抢go.mod解析权，直接导致跳转定义全部失效 - R 用户放弃 LSP-r：截至 2026 年 8 月，它仍无法稳定启动，强行启用只会让 Sublime 在后台反复 fork 失败进程
真正轻量的核心不是少装插件，而是让每个语言服务器只做一件事：精准匹配、低频日志、有限计算、不抢地盘。那些“全自动检测所有语言”的配置，恰恰是卡顿的起点。
