立刻恢复响应需执行Set Syntax: Plain Text和Toggle Word Wrap，或用subl --safe-mode启动；用户设置必须添加"index_files": false、"line_numbers": false、"gutter": false、"highlight_line": false、"draw_white_space": "none"五项以实现只读降级。
Sublime Text 打开超大文件（几百 MB 到 2GB）卡死或无响应，不是软件坏了，也不是你机器差——它在认真执行默认开启的语法解析、索引、缩进检测和软换行计算，而这些对日志、dump、单行长 JSON 来说全是冗余开销。关掉它们，subl 就能秒变高效查看器。
怎么立刻让已卡住的 Sublime 恢复响应（5 秒内）
别等加载完，直接中断正在“拼命干活”的流程：
- 按
Ctrl+Shift+P打开命令面板，输入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 秒内可滚动
用户设置里必须改的五项（只读场景下最有效）
打开 Preferences → Settings – User，在右侧 JSON 中加入以下配置。这不是“可选优化”，而是针对只读查看的硬性降级：
-
"index_files": false——关后台全文索引，否则 CPU 会默默拉满建倒排表 -
"line_numbers": false和"gutter": false——行号区重绘是卡顿常见源头，尤其光标悬停触发折叠按钮时 -
"highlight_line": false——当前行高亮纯属渲染负担，对大文件毫无实用价值 -
"draw_white_space": "none"——跳过空格/制表符可视化，避免大量字符串切片开销
注意："scroll_past_end": false 也建议加上，防止滚动到底部时额外分配缓冲区。
为什么设了 large_file_size_limit 还是卡？阈值逻辑有坑
很多人加了 "large_file_size_limit": 100 就以为万事大吉，但 Sublime 实际检查多个阈值，且部分选项优先级更高：
-
large_file_size_limit单位是 MB，设为 100 后，仅对 >100MB 文件启用轻量模式；但如果"index_files": true（默认），它仍会在后台扫描全文建索引 -
"detect_indentation": true（默认）会让 Sublime 从头扫到尾猜缩进，对无缩进日志毫无意义，却耗时耗内存 -
"viewport_size": 100000（默认）意味着单次渲染 10 万字符，改成5000可省 95% 渲染内存，但必须和"word_wrap": false配合，否则超长行仍拖垮渲染器 - 某些插件（如
GitGutter、SublimeLinter）不识别大文件逻辑，一加载就启动子进程扫全文，比 Sublime 自身还慢
真正该用什么工具，而不是硬调 Sublime
Sublime 的设计目标从来不是 GB 级文本编辑。当遇到以下情况，该换工具就换：
- 纯查看：用
less（Linux/macOS）或more（Windows Terminal），支持/pattern搜索、g到开头、G到结尾，零内存占用 - 筛选/切片：用
grep -n "error" app.log | head -20先定位行号，再把关键段贴进 Sublime，比让它全量加载实在得多 - 真要编辑：确认是否必须图形界面？
vim -u NONE +1000000 huge.log启动后直接定位，比 Sublime 加载还快
最常被忽略的一点：系统级“只读”属性比任何 Sublime 设置都管用。右键文件 → 属性 → 勾选“只读”，Sublime 会自动禁用撤销栈、缓存写入和大部分后台分析——这才是它真正进入“查看模式”的开关。
