sublime打开gb级日志卡死，根本原因是默认当代码处理；立即恢复需三步：设plain text停语法解析、关word wrap、右键绑定后缀为纯文本；用户设置必加"large_file_size_limit":100、"index_files":false、"viewport_size":5000等项，并配合syntax-specific配置与插件白名单实现精准降级。
Sublime 打开几个 GB 的日志文件卡死，不是它撑不住，而是你没让它“别当这是个要编辑的文件”——关掉语法解析、索引、行号这三类默认开启的重型功能，再配合只读加载和外部预处理，1.2GB 日志 8 秒内可滚动。
已打开大文件卡住时，5 秒内恢复响应
别等加载完成，直接干预正在运行的实例：
- 按
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，避免下次同后缀文件重蹈覆辙 - 如果
Ctrl+Shift+P已无响应，终端执行subl --safe-mode your_file.log：跳过所有插件和用户设置，实测 1.2GB 日志 8 秒内可滚动
Preferences → Settings – User 必加配置项
这些不是“越狠越好”，而是按需启用，否则后续新打开的大文件仍会卡：
-
"large_file_size_limit": 100：单位是 MB，设为 100 后，超过 100MB 的文件会主动跳过语法分析和索引；不要设为 0 或负数，Sublime 会忽略 -
"index_files": false：禁用后台全文符号索引，否则GitGutter、SublimeLinter等插件仍会偷偷启动子进程扫全文 -
"viewport_size": 5000：默认值是100000（10 万字符），改成 5000 可省 95% 渲染内存，但必须配合"word_wrap": false，否则超长行仍拖垮渲染器 -
"detect_indentation": false：对无缩进的日志毫无意义，却要从头扫到尾猜缩进，纯属耗时耗内存 -
"line_numbers": false和"gutter": false：千万行下每行生成 DOM 节点是重绘瓶颈；⚠️ 不要全局设"line_numbers": false——日常写 Python 时仍需行号定位；只应在大日志场景下通过 syntax-specific 设置覆盖
按语法类型精准覆盖设置（比全局开关更安全）
你不需要对所有文件都关掉高亮，但打开 access.log 或 dump.json 时就得静默加载：
- 打开一个大日志文件，确认右下角显示语法为
Plain Text或Log - 执行
Preferences → Settings – Syntax Specific，生成对应语法的配置文件（如Plain Text.sublime-settings） - 在里面写入：
"line_numbers": false、"gutter": false、"highlight_line": false、"syntax": "Packages/Text/Plain text.tmLanguage"
哪些插件会在后台偷偷拖垮 Sublime
即使你关了语法高亮，某些插件仍会在文件加载后几秒内触发整文件扫描：
-
SublimeLinter：默认对所有文件跑 lint，不识别“大文件”概念，一开就 fork 子进程扫全文 -
GitGutter：逐行比对 Git 状态，百万行日志里每行都触发 diff 计算 -
BracketHighlighter：光标悬停就尝试匹配括号，长行里正则回溯直接卡死 - 临时验证是否是插件导致：命令行运行
subl --safe-mode huge.log，如果秒开，问题就出在插件 - 若必须用
BracketHighlighter，加配置："bracket_highlighter.ignore_syntaxes": ["Plain text"]
真正棘手的是混合场景：比如一个 300MB 的 JSON 导出文件，既要快速跳转字段，又不能丢结构——这时候全局关 line_numbers 或 index_files 就会反向影响日常开发；syntax-specific 配置和插件白名单才是可控边界。
