秒级响应大文件需禁用语法解析与行号渲染：设plain text语法、关行号、禁自动换行；配置large_file_size_limit为100mb、index_files为false、line_numbers和gutter为false、detect_indentation为false、viewport_size为5000；禁用sublimelinter等插件；用ctrl+p跳转行号；只读模式最彻底。
直接关掉语法解析和行号渲染，几十万行文件就能秒级响应；不改设置只靠“等它加载完”，基本等于放弃控制权。
已打开的大文件卡死，怎么立刻恢复滚动
别重启、别等进度条，当前窗口就能救回来：
- 按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入Set Syntax: Plain Text回车——语法高亮引擎当场停摆，滚动立刻恢复 - 再输
View: Toggle Line Numbers关掉行号，避免为每行生成 DOM 节点（几十万行 ≈ 几十万次 DOM 操作） - 右下角状态栏点击当前语法名（如显示
Log或JSON），右键 →Open all with current extension as…→Plain Text，防止下次同后缀文件重蹈覆辙 - 顺手关自动换行：
View → Word Wrap → Off，超长日志行不再反复计算软断点
用户设置里必须改的几项硬性配置
这些不是“可选优化”，而是几十万行场景下的必要约束：
-
"large_file_size_limit": 100：单位 MB，设为 100 后，超过该大小的文件从第一字节起跳过语法分析、折叠、符号索引 -
"index_files": false：关掉后台全文索引，否则SublimeLinter、GitGutter会默默扫完整个文件 -
"line_numbers": false和"gutter": false：二者都得关，gutter是行号区容器，关了它才能真正释放渲染压力 -
"detect_indentation": false：日志没缩进，却要扫描全文件猜缩进，纯属 CPU 浪费 -
"viewport_size": 5000：配合"word_wrap": false使用，单次最多渲染 5000 字符（默认 100000），内存占用直降 90%+
插件才是隐藏的卡顿源，不是语法高亮
即使你手动切了 Plain Text，以下插件仍会在后台触发整文件扫描：
-
SublimeLinter：默认对所有文件跑 lint，不识别“大文件”概念，一开就 fork 子进程扫全文 -
GitGutter：逐行比对 Git 状态，几十万行 = 几十万次 diff 计算 -
BracketHighlighter：光标悬停就尝试匹配括号，长行正则回溯极易卡死
验证方式：终端执行 subl --safe-mode huge.log，如果秒开，问题就出在插件。长期方案是禁用或卸载这三类插件，或至少加 "index_files": false 削弱其行为。
别靠鼠标滚到底，用行偏移索引跳转
滚动几十万行本质是反复 seek + buffer 重分配，延迟明显；而 goto_line 走的是预建的行偏移索引，快一个数量级：
- 按
Ctrl+P输入:123456（冒号开头），回车直跳第 123456 行 - 拆左右视图：
Ctrl+Shift+2，左边固定看时间戳格式，右边Ctrl+G定位具体行 - 查关键词别用
find_in_files扫全量——它会把每行加载进内存；先用终端grep -n "ERROR" app.log | head -20提取行号，再贴进 Sublime 跳转
真正容易被忽略的是：几十万行文件一旦开始编辑，撤销栈、缓存写入、后台 diff 就会指数级放大开销；只读查看时，系统级设为只读（右键 → 属性 → 只读）比编辑器内任何设置都彻底。
