Sublime Text 打开大文件卡顿的根源是语法高亮、软换行、行号渲染及插件全量扫描，需禁用高亮、行号、自动换行，并配置 large_file_size_limit 等四项设置，配合安全模式排查插件。
关掉语法高亮和自动换行，卡顿立刻缓解
大文件一打开就卡死，90% 是因为 sublime_text 正在对百万行日志逐行跑正则高亮、反复计算软换行断点。这不是加载慢，是渲染链被撑爆。
已打开的文件卡住不动时，别等、别重启，三步干预：
- 按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入View: Toggle Syntax Highlighting回车——高亮引擎立即停摆，滚动基本恢复 - 再输
View: Toggle Line Numbers关行号，避免为每行生成 DOM 节点 - 右下角点击当前语法名（如
JSON或Log），选Open all with current extension as… → Plain Text——跳过所有.sublime-syntax解析，不建树、不着色、不索引
顺手关掉 View → Word Wrap → Off，否则超长日志行会让渲染器反复重排，拖慢十倍。
用户设置里必须加这四条硬核配置
只临时关高亮治标不治本。真正起效的是在 Preferences → Settings – User 里写死以下四项，它们精准切断性能杀手链：
-
"index_files": false：禁用后台全文索引，否则GitGutter、SublimeLinter仍会偷偷 fork 子进程扫全文 -
"large_file_size_limit": 100：单位 MB，设为 100 是平衡点；太小（如 50）会让日常.json文件也被误判轻量模式，太大（如 1000）可能错过真正要查的大日志 -
"detect_indentation": false：对无缩进日志毫无意义，却要从头扫描猜缩进，纯属耗时耗内存 -
"viewport_size": 5000：默认是 100000，砍掉 95% 渲染字符数；但必须配合"word_wrap": false才生效，否则长行仍拖垮渲染器
注意：large_file_size_limit 只影响后续新打开的文件，不改变已打开行为。
按文件类型做 syntax-specific 设置，别全局关行号
你不需要对所有文件都关 line_numbers，日常写 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和ESLint：未配lint_mode时，默认对每个打开的文件跑 lint，不识别“大文件”概念 -
GitGutter：逐行比对 Git 状态，百万行日志里每行都触发 diff 计算 -
BracketHighlighter：光标悬停就尝试匹配括号，长行里正则回溯直接卡死
验证是否是插件导致：终端执行 subl --safe-mode huge.log，如果秒开，问题就出在插件。别信“只是看一眼”，GB 级日志不是用来编辑的，而是用来查的——方向错了，再调参也白搭。
