立刻让已打开的大文件变流畅：先按Ctrl+Shift+P输入View: Toggle Syntax Highlighting关高亮，再输View: Toggle Line Numbers关行号，右下角选Plain 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，否则超长日志行会反复计算软换行位置，拖慢十倍。
为什么改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设置：打开该文件，确认右下角语法为Plain Text，执行Preferences → Settings – Syntax Specific，在生成的Plain Text.sublime-settings里写入："line_numbers": false"gutter": false"highlight_line": false"syntax": "Packages/Text/Plain text.tmLanguage"
这样既保住了日常 Python/JS 文件的完整功能，又让日志类文件静默加载。真正的难点不在参数本身，而在区分「查看」和「编辑」意图——一旦混淆，所有优化都会互相抵消。
