立刻恢复滚动需三步：Set Syntax: Plain Text终止语法扫描，Toggle Word Wrap关闭自动换行，右键状态栏选Plain Text设同后缀默认轻量加载；若命令面板无响应，则用subl --safe-mode强制启动。
怎么立刻让已卡住的 Sublime 恢复滚动（5 秒内）
别等加载完成，也别重启软件——Sublime 卡死时 UI 线程被语法解析和渲染链锁死，必须手动打断。最有效三步是：Set Syntax: Plain Text → Toggle Word Wrap → 右键状态栏语言名选 Open all with current extension as… → Plain Text。
如果命令面板已无响应，直接终端执行：subl --safe-mode your_file.log。它跳过所有插件、用户设置和索引逻辑，实测 1.2GB 日志 8 秒内可自由滚动。
-
Set Syntax: Plain Text立刻终止语法高亮引擎的全量正则扫描，这是卡顿第一源头 -
Toggle Word Wrap关闭自动换行，防止超长日志行反复计算软断点位置（尤其 JSON dump 或 base64 行） - 右键状态栏语言名后选
Plain Text，让同后缀文件下次打开自动继承轻量模式，不是“这次关了就完事”
哪些配置项必须加进 Settings – User（且不能只改一个）
光设 large_file_size_limit 没用——它只是触发条件，真正拖垮 CPU 的是后台行为。这五项必须同步关闭：
-
"index_files": false：禁用后台全文符号索引，否则 GitGutter、SublimeLinter 仍会偷偷启动子进程扫全文 -
"detect_indentation": false：对 access.log 这类无缩进文本毫无意义，却要从头扫到尾猜缩进，纯属耗时耗内存 -
"viewport_size": 5000：默认是 100000，砍掉 95% 渲染字符数；但必须配合"word_wrap": false才生效，否则超长行仍拖垮渲染器 -
"line_numbers": false和"gutter": false：行号区不生成 DOM 节点，悬停折叠按钮也不再触发重绘
注意："large_file_size_limit": 100 单位是 MB，设为 100 后，超过 100MB 的文件才启用轻量模式；设太小（如 50）会让日常 .json 文件也被误判，太大（如 1000）可能错过真正要处理的大文件。
为什么全局关 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}
这样 .log 文件自动走轻量路径，.py 文件仍保持完整编辑体验，互不干扰。
哪些插件在背后偷偷拖垮大文件？
哪怕你手动切了 Plain Text、关了高亮，这些插件仍会全量扫描刚加载的文件：
-
SublimeLinter和ESLint：未配置lint_mode时，默认对每个打开的文件 lint，一碰几百 MB 就卡死 -
GitGutter：即使文件不在 Git 仓库里，也会尝试git status和 diff 计算 -
BracketHighlighter：对超长行做括号匹配，CPU 直接拉满
临时方案是 subl --safe-mode 启动；长期建议在插件设置中禁用大文件关联逻辑，或卸载非必要插件。真正需要查错时，用 grep -n "ERROR" app.log | head -20 定位后再开 Sublime，比硬扛 GB 文件靠谱得多。
复杂点在于：Sublime 本质是编辑器，不是查看器。它再怎么调参，也扛不住 2GB 的 app.log 编辑需求——这时候该换工具就换，别把 less、glogg 或 EmEditor 当备选，它们才是专为这个场景设计的。
