Sublime处理大文件卡顿的根源是默认将日志当代码解析，关闭语法高亮、自动换行、索引、缩进检测、行号渲染五项可解决90%问题；已卡死时用命令面板切Plain Text、关Word Wrap或safe-mode启动，并配置index_files、viewport_size、detect_indentation、large_file_size_limit四项及syntax-specific设置实现高效查看。
Sublime 处理大文件卡顿，不是内存或硬件问题，而是它默认把 access.log 当成 main.py 在逐行解析——语法高亮、缩进检测、后台索引、行号渲染全开，一碰几百 MB 就 CPU 拉满、滚动冻结。关掉这五项核心行为，90% 卡顿当场消失。
已打开的大文件卡死，怎么 5 秒内恢复滚动
别等加载完，也别重启，直接干预正在运行的实例：
- 按
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 必加的四条硬核配置
这些不是“越狠越好”，而是精准切断性能杀手链，缺一不可：
-
"index_files": false：禁用后台全文索引，否则GitGutter、SublimeLinter仍会偷偷启动子进程扫全文 -
"viewport_size": 5000：默认是 100000，砍掉 95% 渲染字符数；但必须配合"word_wrap": false才生效，否则超长行仍拖垮渲染器 -
"detect_indentation": false：对无缩进日志毫无意义，却要从头扫到尾猜缩进，纯属耗时耗内存 -
"large_file_size_limit": 100：单位是 MB，设为 100 后，超过 100MB 的文件才启用轻量模式；设太小（如 50）会让日常.json被误判，太大（如 1000）可能错过真正要编辑的大文件
为什么全局关 line_numbers 是坑？该用 syntax-specific 设置
你不需要对所有文件都关行号，日常写 Python 时仍需定位；但打开 app.log 时就得静默加载：
- 打开一个大日志文件，确认右下角显示语法为
Plain Text或Log - 执行
Preferences → Settings – Syntax Specific，生成对应语法的配置文件（如Plain Text.sublime-settings） - 在里面写入：
{"line_numbers": false,"gutter": false,"highlight_line": false} - 注意：
"syntax"字段值需与实际一致，可在控制台运行view.settings().get('syntax')查看
哪些插件在背后偷偷拖垮大文件
哪怕你关了语法高亮，这些插件仍会全量扫描刚加载的文件：
-
SublimeLinter和ESLint：未配置lint_mode时，默认对每个打开的文件触发分析 -
GitGutter：即使文件不在 Git 仓库中，也可能尝试git status或遍历父目录 -
BracketHighlighter：对超长 JSON dump 会反复匹配括号层级，触发深度正则回溯 - 临时验证是否插件导致：用
subl --safe-mode启动，若不卡，就逐个禁用插件排查
真正卡住的点往往不在设置本身，而在「语法识别滞后」和「插件无感知扫描」——右下角显示 JSON 的那一刻，解析已经开始了；而 SublimeLinter 不管你是不是在看 2GB 日志，只要文件一 open，它就准备 lint。
