sublime text卡顿主因是索引错乱、插件残留及ui状态膨胀；应禁用index_files、清空cache/local/index三类目录、删除packages/user下残留配置，并对大文件切plain text模式。
Sublime Text 卡顿不是“有点慢”，而是索引错乱、插件残留或 UI 状态膨胀导致的硬性故障——改几个配置、删对文件夹，冷启动能从 5 秒压到 0.8 秒，LSP 不再卡死，侧边栏菜单也不会错位。
关掉 index_files 是最立竿见影的操作
它默认开启，会递归扫描整个项目目录（包括 node_modules、dist、.git）构建符号数据库。Windows 上一碰到上万文件的目录，主线程直接卡死；macOS 下 FSEvents 触发频繁重扫，CPU 持续 100%。
- 打开
Preferences → Settings，在右侧用户设置中加这一行："index_files": false - 副作用明确：
Ctrl+Click跳转定义、Find All References失效，但Ctrl+P按文件名搜索、Ctrl+Shift+F全局文本搜索仍可用 - 若需保留部分能力，别全局关，改用项目级排除：右键侧边栏文件夹 →
Add to Project Exclude List，或在Project → Edit Project中写："folder_exclude_patterns": ["node_modules", ".git", "__pycache__"]
缓存必须手动清，Index 和 Cache 目录一个都不能留
Index Rebuild 命令只重建当前项目符号索引，对损坏的全局缓存、插件编译产物、UI 状态文件完全无效。真正卡顿、LSP 启动崩溃、插件右键菜单残留，根源都在这些目录里。
- 先彻底退出 Sublime：Windows 查任务管理器确认
sublime_text.exe进程消失；macOS 用活动监视器查Sublime Text - 删空以下两个目录（路径因系统而异）：
Windows：%APPDATA%\Sublime Text\Cache和%LOCALAPPDATA%\Sublime Text\Cache
macOS：~/Library/Application Support/Sublime Text/Cache和~/Library/Caches/Sublime Text
Linux：~/.config/sublime-text/Cache和~/.cache/sublime-text - 同级的
Index文件夹也必须一并清空——它存的是全文搜索和Goto Definition的底层数据库，损坏后补全延迟、跳转失败都源于此 - 删完插件后，别信
Package Control: Remove Package，去Cache目录用文件名搜插件关键字（如pyright、texlab），删掉整个匹配文件夹
别放过 Local 和 State ——它们才是长期卡顿元凶
很多人只敢动 Cache，却放任 Local 和 State 膨胀。Local 存未保存的会话、崩溃恢复数据、窗口布局；State 存 UI 状态（侧边栏展开项、标签页顺序、折叠区域）。长期运行后碎片化严重，造成启动卡顿、菜单错位、主题加载失败。
-
Local路径与Cache同级（如 Windows 的%APPDATA%\Sublime Text\Local），可临时重命名该文件夹（如改成Local.bak），重启 Sublime 强制重建 -
State在Packages/User/下，常见文件如SideBarEnhancements.sublime-settings或Theme - Default.sublime-settings，若某插件卸载后 UI 行为异常，优先检查这里 - 顺手清理
Packages/User/下残留的插件配置：PluginName.sublime-settings、PluginName.sublime-commands，它们不会随插件卸载自动删除
大文件和超长行要“按需关闭”，不是所有功能都该开着
语法高亮、自动换行、标尺、括号匹配……这些对日常编码是加分项，但对单行几万字符的日志或几百 MB 的 dump 文件，就是渲染炸弹。关键不是“能不能开”，而是“此刻要不要开”。
- 打开大文件前，先切到
Plain Text模式（右下角点语言名 →Plain Text），避免触发任何sublime-syntax解析 - 用户设置中加：
"word_wrap": false（防软换行卡顿）、"rulers": []（清空垂直标尺）、"highlight_line": false、"draw_white_space": "none" - 处理日志类文件时，设为只读更安全：
"default_is_read_only": true，或手动Set as Read-Only，防止编辑器反复分析变更 - 超过 2GB 或需高频正则替换时，别硬扛——用
less（macOS/Linux）或more（Windows Terminal）查看，grep -n "error" app.log | head -20定位后再跳转，比全文find_in_files快一个数量级
性能问题从来不是某个开关单独起作用，而是索引、缓存、UI 状态、渲染策略四层叠加的结果。最容易被忽略的，是删完 Cache 后没动 Local，或者关了 index_files 却忘了清掉旧 Index 数据库——它们残留在磁盘上，每次启动都默默加载几百 MB 冗余内容。
