Sublime读取大文件卡顿的根本原因是后台执行五项高开销操作，而非CPU不足；应立即执行三步干预：切换Plain Text语法、关闭自动换行、右键设置同后缀默认纯文本，若命令面板无响应则用subl --safe-mode强制轻量加载，并在用户设置中硬性配置index_files、detect_indentation等关键项并彻底重启。
Sublime 读取大文件卡顿，根本不是 CPU 不够用，而是它在后台疯狂做五件事：语法高亮逐行正则匹配、自动换行反复计算断点、index_files 扫全项目建索引、detect_indentation 从头猜缩进、插件（如 SublimeLinter）偷偷 fork 子进程扫全文——这些加起来，CPU 拉满是必然结果。关掉它们，不是“降负载”，是直接砍掉执行路径。
怎么立刻让已打开的大文件不卡
别等加载完，也别重启编辑器，三步打断渲染链：
- 按
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 必加的硬核配置
这些不是“可选优化”，而是精准切断性能杀手链的开关，必须写进用户设置并完全退出 Sublime 后重启（仅重载设置无效）：
-
"index_files": false：禁用后台全文索引，否则GitGutter、SublimeLinter仍会偷偷启动子进程扫全文 -
"detect_indentation": false：对无缩进日志毫无意义，却要扫描前 200 行甚至整文件猜缩进，纯属耗时耗内存 -
"line_numbers": false和"gutter": false：行号区不生成 DOM 节点，悬停折叠按钮也不再触发重绘；全局关line_numbers是坑，应改用 syntax-specific 设置 -
"large_file_size_limit": 100：单位是 MB，设为 100 后，超过 100MB 的文件才启用轻量模式；设太小（如 50）会让日常.json文件也被误判，太大（如 1000）可能错过真正要查看的大文件
"viewport_size": 5000 必须配合 "word_wrap": false 才生效，否则超长行仍拖垮渲染器。
为什么插件比 Sublime 自身还慢
哪怕你关了语法高亮、行号、自动换行，某些插件仍会在文件加载后几秒内触发整文件扫描：
-
SublimeLinter：默认对所有文件跑 lint，不识别“大文件”概念，一开就 fork 子进程扫全文 -
GitGutter：逐行比对 Git 状态，百万行日志里每行都触发 diff 计算 -
BracketHighlighter：光标悬停就尝试匹配括号，长行里正则回溯直接卡死
验证是否是插件导致：终端运行 subl --safe-mode huge.log，如果秒开，问题就出在插件。临时排查可关闭插件目录（Data/Packages/ 下移走可疑插件），或在项目配置中用 folder_exclude_patterns 排除 node_modules、.git 等目录，比全局关 index_files 更精细。
别硬扛 GB 级文件，该换工具时就换
Sublime 再怎么调，本质仍是面向编辑的 GUI 编辑器。它能流畅处理 100MB 日志，但面对 2GB 的 dump 或导出数据，less、grep、tail -f（Linux/macOS）或 glogg、EmEditor（Windows）才是正解。尤其当只需查看、搜索、过滤时，GUI 渲染和撤销栈全是冗余负担。真正容易被忽略的是：large_file_size_limit 只影响后续新打开的文件，不改变已打开行为；而 index_files 关闭后必须彻底退出进程，旧索引上下文不会自动释放。
