大文件渲染变慢主因是sublime默认“认真干活”，关语法高亮、行号、自动换行、索引及插件扫描可立竿见影缓解卡顿；已打开文件可通过命令面板即时关闭高亮与行号，并设为plain text语法，同时配置"index_files":false等关键设置。
大文件渲染变慢，不是 Sublime 吃内存吃满了，是它在“认真干活”——语法高亮逐行跑正则、自动换行反复计算断点、行号区为每行生成 DOM 节点、插件还在后台扫全文。关掉这些，默认行为就从「编辑器」降级为「查看器」，卡顿立刻缓解。
怎么立刻让已打开的大文件滚动不卡
别重启、别等加载完成，直接打断渲染链：
- 按
Ctrl+Shift+P（macOS 是Cmd+Shift+P），输入View: Toggle Syntax Highlighting回车——高亮一关，CPU 占用常从 90% 掉到 10% - 再输
View: Toggle Line Numbers关行号，尤其对千万行日志，这步能省下几百 MB 渲染开销 - 右下角点击当前语法名（如
JSON或Log），选Open all with current extension as… → Plain Text——跳过所有.sublime-syntax解析，连内联<script></script>都不碰 - 顺手关自动换行：
View → Word Wrap → Off，否则单行 20 万字符的 dump 文件会把主线程卡死在软换行计算上
为什么改了 large_file_size_limit 还是卡
这个配置只影响「新打开」的文件，且仅是触发阈值，不等于自动关功能。点了弹窗的 Yes 后，Sublime 仍会照常做缩进检测、索引、高亮当前行——你只是被允许「看着它卡」。
- 必须手动加这三项才真正生效：
"index_files": false（禁用后台全文件扫描）、"detect_indentation": false（避免从头读到尾猜缩进）、"highlight_line": false（关掉当前行高亮，纯属渲染负担） -
"ask_before_opening_large_files": false一定要配，否则每次打开都弹窗，而弹窗本身就会阻塞 UI 线程 -
large_file_size_limit建议设为100（单位 MB），太小（如50）会让日常.json被误判，太大（如1000）可能漏掉真正要处理的大文件
哪些插件会在保存/加载时偷偷拖垮界面
语法高亮关了，不代表就安全了。很多插件默认不识别「大文件」概念，一加载完就开扫：
-
GitGutter：默认调git status，大文件 + 未提交变更 = 等 1.5 秒 -
LSP（如pyright）：默认diagnostics_delay_ms是 0，等于实时诊断，一改就全文件重分析 -
SublimeLinter和BracketHighlighter：照常跑正则，哪怕你只开了个.log - 临时验证方法：启动时加
--safe-mode参数（Windows 下命令行运行subl --safe-mode huge.log），如果流畅了，问题一定出在插件
保存大文件时光标延迟、界面冻结怎么办
保存卡顿和打开卡顿不是一回事：前者主因是 atomic_save 同步写盘 + 插件保存钩子双重阻塞，哪怕你只改了一行，主线程也得等 GitGutter 和 LSP 全返回。
- 必须同时做三件事：
"atomic_save": false（关原子写入）、"non_blocking": true加到GitGutter的用户设置里、LSP 设置中加"diagnostics_delay_ms": 2000 - 确认没启用
AutoSave插件——它和save_on_focus_lost共存会导致重复保存，I/O 翻倍 - 大文件务必先切
Plain Text模式再保存，否则语法高亮器会在保存前强制重绘整页，正则解析吃满单核
真正容易被忽略的是：即使你清了 Index 目录、关了所有设置，只要 sublime_text.exe 进程没彻底退出，旧索引线程仍在后台跑；而 save_on_focus_lost 卡顿，90% 都发生在你多开了一个含 node_modules 的项目后——它根本没动你的设置，但 Sublime 已经在后台默默建索引了。
