Sublime大文件卡顿根源是默认当代码编辑处理，关语法解析、索引、行号并设为Plain Text可秒开100MB日志；已卡死时执行Set Syntax: Plain Text、Toggle Word Wrap、右键设Plain Text三步5秒恢复，配合large_file_size_limit等四项配置及syntax-specific设置实现高效查看。

Sublime 运行大文件卡顿，不是它撑不住，而是你没让它“别当这是个要编辑的文件”——默认对 access.log、dump.json 逐行跑正则高亮、猜缩进、建索引、渲染行号，CPU 拉满就卡死。关掉语法解析、索引、行号这三项核心耗能行为，再配合按语法类型精准降级，100MB 日志可秒开，1.2GB 文件 8 秒内滚动。

已打开的大文件卡死，5 秒内恢复滚动怎么做

别等加载完，也别重启，直接打断正在运行的渲染链：

• 按 Ctrl+Shift+P（Win/Linux）或 Cmd+Shift+P（macOS），输入 Set Syntax: Plain Text 回车——立刻终止语法高亮引擎的全量扫描
• 再输 View: 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 必加的四项硬核配置

这些不是“越狠越好”，而是精准切断性能杀手链，只影响后续新打开的文件：

• "large_file_size_limit": 100：单位是 MB，设为 100 后，超过 100MB 的文件才启用轻量模式；设太小（如 50）会让日常 .json 被误判，太大（如 1000）可能错过真正要处理的大文件
• "index_files": false：禁用后台全文索引，否则 GitGutter、SublimeLinter 仍会偷偷启动子进程扫全文
• "viewport_size": 5000：默认值是 100000，砍掉 95% 渲染字符数；但必须配合 "word_wrap": false 才生效，否则超长行仍拖垮渲染器
• "detect_indentation": false：对无缩进日志毫无意义，却要从头扫到尾猜缩进，纯属耗时耗内存

为什么全局关 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 时，默认对每个打开的文件触发分析
• GitGutter：会调用 git 命令比对差异，大文件下阻塞主线程
• BracketHighlighter：对超长行做括号匹配，极易卡死
• 临时验证是否插件导致：启动时加 --safe-mode 参数，或在用户设置中加 "ignored_packages": ["SublimeLinter", "GitGutter"]

真正容易被忽略的是：大文件不是用来“编辑”的，而是用来“查”的。哪怕只开一次 app.log，也建议顺手右键设为只读——Sublime 会自动禁用撤销栈、缓存写入和语法变更监听，这才是最彻底的降级方式。