已打开大日志卡死时，5秒内恢复需三步：设Plain Text停语法解析、关Word Wrap防软换行重排、右键绑定后缀为纯文本；用户设置必加"large_file_size_limit":100、"index_files":false、"viewport_size":5000、"detect_indentation":false，并用syntax-specific关闭行号等渲染项。
已打开的日志文件卡死，5秒内恢复滚动
别等加载完成，也别重启编辑器——Sublime 正在后台对百万行日志逐行做语法分析、缩进检测和软换行计算，关掉这三项就能立刻响应：
- 按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入Set Syntax: Plain Text回车：终止所有语法高亮解析器 - 再输入
View: Toggle Word Wrap关闭自动换行：超长日志行（如带完整堆栈的 ERROR）不再触发反复断行重排 - 右键点击状态栏右下角当前语法名（如显示
Log或JSON），选Open all with current extension as… → Plain Text：防止下次同后缀文件重蹈覆辙 - 若命令面板已无响应，终端执行
subl --safe-mode your_app.log：跳过全部插件与用户设置，实测 1.2GB 日志 8 秒内可滚动
Preferences → Settings – User 必加的四条硬核配置
这些不是“越多越好”，而是精准切断性能链路。缺一不可，且只对后续新打开的文件生效：
-
"large_file_size_limit": 100：单位 MB，设为 100 后，超过该大小的文件从第一字节起就跳过语法分析、折叠、符号索引；设太小（如 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} - 注意：
"syntax"字段值需与实际一致，可在控制台运行view.settings().get('syntax')查看真实路径
哪些插件会在后台偷偷拖垮 Sublime？
即使你手动切了 Plain Text，这些插件仍会触发整文件扫描：
-
SublimeLinter：默认对所有文件跑 lint，不识别“大文件”概念，一开就 fork 子进程扫全文 -
GitGutter：逐行比对 Git 状态，百万行日志里每行都触发 diff 计算 -
BracketHighlighter：光标悬停就尝试匹配括号，长行正则回溯直接卡死 - 临时验证是否是插件导致：终端运行
subl --safe-mode huge.log，如果秒开，问题就出在插件
真正棘手的是混合场景：比如一个 300MB 的 JSON 导出文件，既要快速跳转字段，又不能丢结构——这时候 syntax-specific 配置 + viewport_size + 插件白名单才是唯一解法，而不是指望某个开关“一键全关”。
