Sublime大文件卡顿根源是默认当代码处理，关语法高亮、索引、行号、自动换行四类行为即等效“极速模式”；已卡死时5秒内恢复需执行Set Syntax: Plain Text、Toggle Word Wrap、右键设同后缀为Plain Text三步，或用subl --safe-mode强制轻量加载。
Sublime 没有叫“极速模式”的开关，但它的大文件卡顿问题几乎全来自默认当代码处理——关掉语法高亮、索引、行号、自动换行这四类行为，就等效于手动开启只读+轻量加载的“极速模式”。
怎么立刻让已卡死的大文件恢复滚动（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 必加的四项硬核配置
这些不是“越狠越好”，而是精准切断性能杀手链，且仅影响后续新打开的文件：
-
"large_file_size_limit": 100：单位 MB，设为 100 后，超过 100MB 的文件自动跳过语法分析、折叠、符号索引；设太小（如 50）会让日常.json被误判，太大（如 1000）可能错过真正要处理的大文件 -
"index_files": false：禁用后台全文索引，否则GitGutter、SublimeLinter仍会偷偷 fork 子进程扫全文 -
"detect_indentation": false：对无缩进日志毫无意义，却要从头扫到尾猜缩进，纯属耗时耗内存 -
"viewport_size": 5000：默认是 100000（10 万字符），砍到 5000 可省 95% 渲染内存，但必须配合"word_wrap": false才生效，否则超长行仍拖垮渲染器
为什么全局关 line_numbers 是坑？该用 syntax-specific 设置
你不需要对所有文件都关行号，日常写 Python 时仍需定位；但打开 access.log 时就得静默加载。全局设 "line_numbers": false 会反向影响开发效率。
- 打开一个大日志文件，确认右下角显示语法为
Plain Text或Log - 执行
Preferences → Settings – Syntax Specific，生成对应语法的配置文件（如Plain Text.sublime-settings） - 在里面写入：
{"line_numbers": false,"gutter": false,"highlight_line": false}
哪些插件会在后台偷偷拖垮 Sublime
即使你关了语法高亮，某些插件仍不识别“大文件”概念，一加载就触发全量扫描：
-
SublimeLinter：默认对所有文件跑 lint，不区分大小，一开就 fork 子进程扫全文 -
GitGutter：逐行比对 Git 状态，百万行日志里每行都触发 diff 计算 -
BracketHighlighter：光标悬停就尝试匹配括号，长行里正则回溯直接卡死 - 临时验证是否是插件导致：终端执行
subl --safe-mode huge.log，如果秒开，问题就出在插件
真正难处理的不是“怎么开得快”，而是“怎么让 Sublime 别把它当代码”。它不会自动降级，必须靠配置和操作主动切断解析链——尤其是 index_files 和 detect_indentation 这两项，常被忽略，却是 CPU 拉满的元凶。
