Sublime读取大文件卡顿的根源是默认将其当代码逐行解析，关闭语法高亮、行号渲染、自动换行、缩进检测、后台索引五项可解决90%问题；已卡死时用Set Syntax: Plain Text、Toggle Word Wrap或safe-mode启动，配合large_file_size_limit、index_files、viewport_size、detect_indentation四项配置及syntax-specific设置实现高效查看。
Sublime 读取大文件卡顿，不是它“撑不住”，而是默认把它当代码在逐行解析——语法高亮、行号渲染、自动换行、缩进检测、后台索引五项全开，一碰 100MB 的 access.log 就 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 必加的四条硬核配置
这些不是“越狠越好”，而是精准切断性能杀手链，只对后续新打开的文件生效：
-
"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、GitGutter、BracketHighlighter 这些插件仍会在后台偷偷全量扫描刚加载的文件——它们不识别“大文件”概念，一开就 fork 子进程，CPU 直接拉满。临时验证是否是插件导致，最简单就是 subl --safe-mode huge.log，秒开就说明问题出在这儿。
