sublime text打开大文件卡死或崩溃并非内存不足，而是默认将access.log等日志文件当作main.cpp解析，导致语法高亮逐行正则匹配、自动换行反复计算断点、索引线程全文件扫描、插件后台调用外部命令及冗余渲染（如highlight_line、draw_white_space）五项高耗能行为叠加，cpu拉满、ui冻结；仅调large_file_size_limit无效，必须同步在用户设置中关闭index_files、detect_indentation、line_numbers、gutter、highlight_line五项，并设ask_before_opening_large_files为false，配合plain text语法与临时关闭高亮/行号/自动换行，才能实现秒开与即时响应。
为什么大文件一打开就卡死或崩溃
不是Sublime内存不足，而是它默认把access.log当成main.cpp在认真解析：语法高亮逐行跑正则、自动换行反复计算断点、索引线程扫描全文件、插件后台调用外部命令——四项叠加，CPU拉满，UI线程冻结。尤其当文件含超长行（如JSON dump）或大量二进制头（如误扫PNG），draw_white_space和highlight_line会触发渲染引擎反复重排，直接假死。
关掉这五项才能真正秒开
仅改large_file_size_limit没用，必须同步关闭后台高耗能行为：
-
"index_files": false——禁用全文符号索引，否则打开瞬间就stat()扫万级文件 -
"detect_indentation": false——避免扫描前200行猜缩进，日志/导出数据根本没缩进 -
"line_numbers": false和"gutter": false——行号区不生成DOM节点，悬停折叠按钮也不再触发重绘 -
"highlight_line": false——当前行高亮纯属冗余渲染，查错时完全不需要
这些要写进Preferences → Settings – User，不是临时开关。设"large_file_size_limit": 100（单位MB）只是让超100MB文件跳过语法分析，但若上面五项开着，照样卡。
已打开的文件怎么立刻恢复滚动
别等、别重启，直接打断渲染链：
- 右下角点击当前语法名（如
JSON），选Open all with current extension as… → Plain Text——跳过所有.sublime-syntax解析 - 按
Ctrl+Shift+P（macOS是Cmd+Shift+P），输入View: Toggle Syntax Highlighting回车——高亮关掉，滚动立刻恢复 - 再输
View: Toggle Line Numbers关行号；顺手View → Word Wrap → Off，否则超长行会让渲染引擎反复计算软换行
注意：Plain Text设置会继承后缀，下次同类型文件自动轻量加载。
哪些插件在背后偷偷拖垮大文件
哪怕你关了语法高亮，这些插件仍会全量扫描刚加载的文件：
-
SublimeLinter和ESLint：未配置lint_mode时，默认对每个打开的文件跑校验，遇到巨量嵌套JSON或无缩进日志直接卡死 -
GitGutter：为每行调用git status，千行日志=千次进程启动，尤其在含图片或构建产物的目录下 -
BracketHighlighter：默认不识别“大文件”，会在std::enable_if_t<...></...>这类模板展开体里反复匹配括号，CPU飙到100%
临时验证：启动时加--safe-mode参数（Windows命令行运行subl --safe-mode huge.log），若秒开，问题100%出在插件。禁用比卸载稳妥：Preferences → Package Control → Disable Package，保留配置和快捷键。
真正容易被忽略的是ask_before_opening_large_files——即使你把阈值设到100MB，Sublime默认仍弹确认框，点了“Yes”它照样偷偷做索引、检测缩进、高亮当前行。必须显式加"ask_before_opening_large_files": false，否则所有优化都打折扣。
