Sublime打开大文件卡顿的根源是默认当代码处理，关语法解析、索引、行号三类功能并设Plain Text、关Word Wrap、用safe-mode启动，配合index_files等四项配置可实现1.2GB日志8秒内滚动。

Sublime 打开大文件卡顿，不是它撑不住，而是你没让它“别当这是个要编辑的文件”——关掉语法解析、索引、行号这三类默认开启的重型功能，再配合只读加载和外部预处理，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，避免下次同后缀文件重蹈覆辙
• 如果命令面板已无响应，终端执行 subl --safe-mode your_file.log：跳过所有插件和用户设置，实测 1.2GB 日志 8 秒内可滚动

Preferences → Settings – User 必加的四条硬核配置

这些不是“越狠越好”，而是精准切断性能杀手链：

• "index_files": false：禁用后台全文索引，否则 GitGutter、SublimeLinter 仍会偷偷启动子进程扫全文
• "detect_indentation": false：对无缩进日志毫无意义，却要从头扫到尾猜缩进，纯属耗时耗内存
• "viewport_size": 5000：默认值是 100000，砍掉 95% 渲染字符数；但必须配合 "word_wrap": false 才生效，否则超长行仍拖垮渲染器
• "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}

• 如果语法名不确定，可在控制台运行 view.settings().get('syntax') 查看实际值

哪些插件在背后偷偷拖垮大文件？

哪怕你手动切了 Plain Text，这些插件仍会全量扫描刚加载的文件：

• SublimeLinter 和 ESLint：未配置 lint_mode 时，默认对每个打开的文件触发分析
• GitGutter：不识别大文件逻辑，一加载就启动 diff 子进程扫全文
• BracketHighlighter：对超长行反复匹配括号结构，CPU 直接拉满

临时验证是否插件导致卡顿：用 subl --safe-mode 启动，若流畅，就逐个禁用插件排查。真正容易被忽略的是：插件行为不受 large_file_size_limit 控制，必须单独配置或禁用。