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 时就得静默加载。全局设 "line_numbers": false 会反向影响开发效率。
- 打开一个大日志文件，确认右下角显示语法为
Plain Text或Log - 执行
Preferences → Settings – Syntax Specific，生成对应语法的配置文件（如Plain Text.sublime-settings） - 在里面写入：
{ "line_numbers": false, "gutter": false, "highlight_line": false } - 注意：
gutter是隐藏性能杀手——它控制整块行号区（含折叠按钮、断点图标）的渲染，光标悬停、滚动都会触发重绘，只关line_numbers不管用
subl --safe-mode 不是备选方案，是第一响应手段
当 Ctrl+Shift+P 已无响应，说明渲染线程已锁死，此时任何设置修改都无效。必须用终端强制启动：
- macOS：
subl --safe-mode /path/to/bigfile.log - Windows：
subl.exe --safe-mode "C:\data\huge.csv" - Linux：
subl --safe-mode /var/log/syslog
--safe-mode 不加载任何插件、不读取用户设置，但保留搜索、跳转、保存等基础能力。它不是“降级”，而是让 Sublime 从第一行开始就放弃编辑幻想，回归查看器本质。
真正容易被忽略的是：即使做了全部配置，只要某个插件（比如 BracketHighlighter）没配 "bracket_highlighter.ignore_syntaxes": ["Plain text"]，它仍会在后台默默扫描整文件——卡顿不是来自 Sublime 自身，而是来自你以为“已关”的第三方代码。
