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 秒内可滚动
哪些配置项必须改，且不能只靠 large_file_size_limit？
large_file_size_limit 单独设为 100（单位 MB）只是触发轻量模式的开关，但若其他高耗能项开着，照样卡死。真正起效的是这五项，必须写进 Preferences → Settings – User："index_files": false：禁用后台全文索引，否则 GitGutter、SublimeLinter 仍会偷偷 fork 子进程扫全文"detect_indentation": false：对无缩进日志毫无意义，却要从头扫到尾猜缩进，纯属耗时耗内存"line_numbers": false 和 "gutter": false：行号区不生成 DOM 节点，悬停折叠按钮也不再触发重绘"highlight_line": false：当前行高亮对大文件是冗余渲染，查错时完全不需要
注意："viewport_size": 5000 必须配合 "word_wrap": false 才生效，否则超长行仍拖垮渲染器
为什么全局关 line_numbers 是坑？该用 syntax-specific 设置
你不需要对所有文件都关行号——日常写 Python 时仍需定位；但打开 app.log 时就得静默加载。
全局设 "line_numbers": false 会反向影响开发效率。
正确做法：
打开一个大日志文件，确认右下角显示语法为 Plain Text 或 Log
执行 Preferences → Settings – Syntax Specific，生成对应语法的配置文件（如 Plain Text.sublime-settings）
在里面写入：
{"line_numbers": false,"gutter": false,"highlight_line": false}这样只对纯文本类大文件生效，不影响其他语言编辑体验
哪些插件在背后偷偷拖垮大文件？
即使你手动切了 Plain Text 并关了高亮，这些插件仍可能在后台全量扫描刚加载的文件：SublimeLinter 和 ESLint：未配置 lint_mode 时，默认对每个打开的文件跑校验GitGutter：逐行比对 Git 状态，百万行日志里每行都触发 diff 计算BracketHighlighter：光标悬停就尝试匹配括号，长行里正则回溯直接卡死
临时验证是否是插件导致：终端运行 subl --safe-mode huge.log，如果秒开，问题就出在插件
真正卡顿的根源不是文件太大，而是 Sublime 默认把它当「可编辑的代码」来伺候——语法解析、索引、渲染三者叠加，CPU 拉满。关什么，比开什么更重要；而最常被忽略的，是右下角那个看似无关紧要的语法名：它一显示 JSON，扫描就已开始。
