Sublime 编辑大文件卡顿主因是默认将 access.log 当作代码文件解析，关闭语法高亮、缩进检测等五项并配置四项核心设置可解决。

Sublime 编辑大文件卡顿，不是内存或硬件问题，而是它默认把 access.log 当成 main.py 在逐行解析——语法高亮、缩进检测、后台索引、行号渲染全开，一碰几百 MB 就 CPU 拉满、滚动冻结。关掉这五项，90% 卡顿当场消失。

已打开的文件卡死，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 仍会偷偷启动子进程扫全文
• "viewport_size": 5000：默认值是 100000，砍掉 95% 渲染字符数；但必须配合 "word_wrap": false 才生效，否则超长行仍拖垮渲染器
• "detect_indentation": 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') 查看实际值

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

哪怕你关了语法高亮，这些插件仍会全量扫描刚加载的文件：

• SublimeLinter 和 ESLint：未配置 lint_mode 时，默认对每个打开的文件跑 lint，不识别“大文件”概念
• GitGutter：逐行比对 Git 状态，百万行日志里每行都触发 diff 计算
• BracketHighlighter：光标悬停就尝试匹配括号，长行里正则回溯直接卡死
• 临时验证是否是插件导致：命令行运行 subl --safe-mode huge.log，如果秒开，问题就出在插件

真正容易被忽略的是：Sublime 再怎么调，本质仍是面向编辑的 GUI 编辑器。GB 级日志不是用来“编辑”的，而是用来“查”的——该用 grep、tail、less 预处理时，就别硬扛。