立刻恢复响应需执行三步：输入Set Syntax: Plain Text停语法解析，Toggle Word Wrap关自动换行，右键状态栏选Plain Text避免重蹈覆辙；若命令面板无响应，则用subl --safe-mode强制启动。

Sublime 打开超大文本文件卡顿，不是软件坏了，也不是你电脑差，而是它默认把每个文件都当「可编辑的代码」来处理——语法高亮、行号渲染、缩进检测、后台索引全在后台跑，一碰到几百 MB 的日志或 dump 文件，CPU 直接拉满，界面冻结。关掉这三类东西，5 秒内就能滚动。

怎么立刻让已卡住的 Sublime 恢复响应

别等加载完，直接干预正在运行的实例：

• 按 Ctrl+Shift+P（Win/Linux）或 Cmd+Shift+P（macOS）打开命令面板，输入 Set Syntax: Plain Text 回车——立刻停掉语法解析器
• 再输 Toggle Word Wrap 关闭自动换行，防止超长行反复计算软换行位置
• 右键状态栏语言名（比如显示 JSON），选 Open all with current extension as… → Plain Text，避免下次同后缀文件重蹈覆辙
• 如果 Ctrl+Shift+P 已无响应，就强制重启：subl --safe-mode your_file.log，不加载插件、不读用户设置，实测 1.2GB 日志 8 秒内可滚动

哪些配置项关了最立竿见影

很多人加了 "large_file_size_limit": 100 就以为万事大吉，但 Sublime 实际会同时检查多个阈值，且部分选项优先级更高。真正起效的是这几项：

• "index_files": false——关后台全文索引，这是头号 CPU 杀手
• "detect_indentation": false——对无缩进日志毫无意义，却要从头扫到尾猜缩进
• "line_numbers": false 和 "gutter": false——行号区重绘是卡顿常见源头，尤其光标悬停触发折叠按钮时
• "highlight_line": false——当前行高亮对大文件纯属渲染负担
• "draw_white_space": "none"——跳过空格/制表符可视化，避免字符串切片开销

为什么改了设置还是卡？常见坑点

这些细节容易被忽略，但一出错就前功尽弃：

• "large_file_size_limit" 单位是 MB，设为 100 后，超过 100MB 的文件才启用轻量模式；但若 "index_files": true（默认），它仍会在后台默默扫描全文建索引
• 某些插件（如 GitGutter、SublimeLinter）不识别大文件逻辑，一加载就启动子进程扫全文，比 Sublime 自身还慢
• "word_wrap": false 必须和 "viewport_size": 5000 配合，否则超长行仍会拖垮渲染器
• 右下角状态栏显示的 JSON 或 JavaScript 是 Sublime 自动猜的，一加载就开扫，必须手动切回 Plain Text

别硬扛 GB 级文件，该换工具时就换

Sublime 再怎么调，本质仍是面向编辑的 GUI 编辑器。超过 2GB 或需要正则替换上百万次时，它的内存模型和事件循环就不是设计目标了：

• 纯查看：用 less（Linux/macOS）或 more（Windows Terminal），支持 /pattern 搜索、g 到开头、G 到结尾，零内存占用
• 筛选/定位：用 grep -n "error" app.log | head -20 先拿到行号，再贴进 Sublime 用 Ctrl+G 跳转，比全文 find_in_files快一个数量级
• 真要编辑：确认是否必须图形界面？vim -u NONE +1000000 huge.log 启动后直接定位，比 Sublime 加载还快