sublime text 打开大文件卡顿主因是默认启用语法解析等五项功能，关掉语法高亮、行号、自动换行、索引及插件扫描可解决90%卡顿；已打开文件可通过命令即时关闭高亮与行号，并设为纯文本语法。
Sublime Text 打开大文件卡顿，根本不是内存不够，而是它默认把 access.log 当成 main.py 在认真解析——语法高亮、行号、自动换行、索引、插件扫描全开，一碰几百 MB 就 CPU 拉满、界面冻结。关掉这五项，90% 的卡顿当场消失。
怎么立刻让已打开的大文件变流畅
文件已经卡住不动？别等、别重启，直接干预渲染链：
- 按
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，否则超长日志行会反复计算软换行位置，拖慢十倍
为什么改 large_file_size_limit 比弹窗点 “Yes” 管用
默认 10MB 就弹警告，但点了 “Yes” 只是允许加载，Sublime 仍会偷偷做索引、检测缩进、高亮当前行——CPU 还是 100%。必须让它从第一行开始就“放弃编辑幻想”：
- 进
Preferences → Settings – User，加这行："large_file_size_limit": 100（单位 MB） - 值设 100 是平衡点：太小（如 50）会让日常
.json文件也被误判；太大（如 1000）可能错过真正要编辑的大文件 - 这个配置生效后，超过阈值的文件会跳过语法分析、折叠、符号索引，加载速度接近
less - 注意：它不改变已打开文件的行为，只影响后续新打开的文件
哪些插件会在后台偷偷拖垮 Sublime
即使你关了语法高亮，某些插件仍会扫描整文件触发卡顿，尤其在大文件刚加载完的几秒内：
-
SublimeLinter和BracketHighlighter是头号嫌疑——它们默认不识别「大文件」概念，会照常跑正则或调用外部命令 - 临时禁用全部插件：
Preferences → Package Control → Disable Package，挨个试；确认能流畅打开后，再单独启用SideBarEnhancements这类只响应右键/快捷键的轻量插件 - 若必须用
BracketHighlighter，加配置："bracket_highlighter.ignore_syntaxes": ["Plain text"] - 别信“我就看一眼”，只读场景下这些插件全该关
真正棘手的是混合场景：比如一个 300MB 文件，既要查错又要改几行
这时候全局关 line_numbers 或 index_files 就会反向影响日常开发。更稳妥的做法是用 syntax-specific 设置：
- 打开一个大日志文件（如
app.log），确认右下角显示语法为Plain Text或Log - 执行
Preferences → Settings – Syntax Specific，会生成对应语法的配置文件（如Plain Text.sublime-settings） - 在里面写入：
"line_numbers": false、"gutter": false、"highlight_line": false、"syntax":"Packages/Text/Plain text.tmLanguage" - 如果语法名不确定，可先在控制台运行
view.settings().get('syntax')查看实际值
最易被忽略的一点：Sublime 的内存模型是把整个文件加载进内存并构建语法树，200MB 文件实际占用内存常超 1GB。这时候硬撑只会拖垮整个系统——该用 less、grep 或 vim -u NONE 的时候，就别强求 Sublime 编辑。
