5秒内恢复大文件滚动：先用命令面板设Plain Text语法停高亮，再关自动换行，最后右键设同后缀默认轻量加载；若卡死则用--safe-mode启动。
已打开的大文件卡死，5 秒内恢复滚动
别等加载完成，也别重启 Sublime，直接打断正在运行的渲染链：Ctrl+Shift+P（Win/Linux）或 Cmd+Shift+P（macOS），输入 Set Syntax: Plain Text 回车——语法高亮引擎立刻停止全量扫描；再输 Toggle Word Wrap 关闭自动换行，防止超长日志行反复计算软断点；最后右键状态栏右下角当前语法名（如显示 JSON 或 Log），选 Open all with current extension as… → Plain Text，让同后缀文件下次自动轻量加载。如果命令面板已无响应，终端执行 subl --safe-mode your_file.log，跳过所有插件和用户设置，实测 1.2GB 日志 8 秒内可滚动。
Preferences → Settings – User 必加的四条硬核配置
这些不是“越狠越好”，而是精准切断性能杀手链，必须写进用户设置才对后续新文件生效：
-
"large_file_size_limit": 100：单位 MB，设为 100 后，超 100MB 文件主动跳过语法分析和索引；设太小（如 50）会让日常.json被误判，太大（如 1000）可能错过真正要查的大日志 -
"index_files": false：禁用后台全文符号索引，否则GitGutter、SublimeLinter仍会偷偷 fork 子进程扫全文 -
"viewport_size": 5000：默认值是 100000，砍掉 95% 渲染字符数；但必须配合"word_wrap": false才生效，否则超长行仍拖垮渲染器 -
"detect_indentation": false：对无缩进日志毫无意义，却要从头扫到尾猜缩进，纯属耗时耗内存
为什么全局关 line_numbers 是坑？该用 syntax-specific 设置
你不需要对所有文件都关行号——日常写 Python 时仍需定位；但打开 access.log 时就得静默加载。全局设 "line_numbers": false 会反向影响开发效率。
正确做法：
- 打开一个大日志文件，确认右下角显示语法为
Plain Text或Log - 执行
Preferences → Settings – Syntax Specific，生成对应语法的配置文件（如Plain Text.sublime-settings） - 在里面写入：
{"line_numbers": false,"gutter": false,"highlight_line": false}
注意：gutter 控制行号区 DOM 节点生成，不关它，百万行下每行仍触发重绘；highlight_line 是当前行高亮，查错时完全不需要。
哪些插件在背后偷偷拖垮大文件？
即使你关了语法高亮，这些插件仍会在文件加载后几秒内触发整文件扫描：
-
SublimeLinter和ESLint：未配置lint_mode时，默认对每个打开的文件跑 lint -
GitGutter：逐行比对 Git 状态，百万行日志里每行都触发 diff 计算 -
BracketHighlighter：光标悬停就尝试匹配括号，长行里正则回溯直接卡死
临时验证是否是插件导致：终端运行 subl --safe-mode huge.log，如果秒开，问题就出在插件。不要盲目禁用，先用 --safe-mode 定位，再针对性调整插件配置或加入白名单。
真正卡顿的根源从来不是文件大小，而是 Sublime 默认把它当 main.py 在认真解析——语法高亮逐行正则、自动换行反复计算断点、索引线程全文件扫描、插件后台调用外部命令。关什么，比开什么更重要；而最常被忽略的，是 viewport_size 和 word_wrap 的联动关系：不关后者，前者几乎无效。
