sublime text 实时日志滚动卡顿的根本原因是渲染 overload，而非文件加载慢；具体包括 word wrap 触发断行计算、gutter/行号重绘、brackethighlighter 正则回溯、find_in_files 全量扫描及 logrotate 后权限变更导致轮询检测。
大吞吐日志打印时滚动卡顿，不是加载慢而是渲染 overload
Sublime Text 在 tail -f 类场景（如实时追加的 access.log、app.log）下卡顿，根本原因不是文件变大，而是它持续尝试为新行做语法高亮、行号更新、软换行计算和 gutter 重绘。哪怕你已设为 Plain Text，只要 word_wrap 开着，超长日志行（比如带完整堆栈的 ERROR）就会反复触发断行逻辑，CPU 占用飙到 90%+。
实操建议：
- 立刻关掉自动换行：
View → Word Wrap → Off（或按Alt+Z），这是最立竿见影的操作 - 禁用 gutter 区域：
"gutter": false和"line_numbers": false必须写进用户设置，否则新追加的行仍会触发 DOM 节点生成 - 避免右下角语法名被误点：一旦看到状态栏显示
Log或JSON，右键它 →Open all with current extension as… → Plain Text，防止下次同后缀又走高亮流程 - 别开 minimap：
"draw_minimap": false，它对实时追加日志毫无意义，却持续扫描整文件高度
tail -f 日志里光标悬停就卡死，是 BracketHighlighter 在正则回溯
即使你关了高亮、关了行号，BracketHighlighter 插件仍会在光标悬停时对当前行执行括号匹配——而日志里常见 {"error":"xxx", "stack":"..."} 这类长行，正则引擎会深度回溯，导致界面冻结数秒。这不是 Sublime 本身的问题，是插件没做「大文件豁免」。
实操建议：
- 临时验证：终端运行
subl --safe-mode app.log，如果滚动/悬停立刻流畅，问题就在插件 - 长期方案：在用户设置中加
"ignored_packages": ["BracketHighlighter", "SublimeLinter", "GitGutter"]，这三者默认不区分文件大小，一加载就扫全文 - 若必须保留某些插件，改用条件启用：在
BracketHighlighter.sublime-settings中设"bracket_highlighting_enabled": false，再配合 syntax-specific 设置只在Python等语法下开启
实时日志里 Ctrl+F 搜索越来越慢，因为 find_in_files 加载全量文本
find_in_files（快捷键 Ctrl+Shift+F）默认把整个文件读进内存再逐行匹配，对持续增长的日志，每次搜索都比上次更慢。它不会跳过已加载部分，也不会利用偏移索引，纯粹暴力扫描。
实操建议：
- 改用终端预筛：
grep -n "500" app.log | tail -20提取最近 20 条匹配行号，再在 Sublime 里按Ctrl+G输入行号跳转 - 限制搜索范围：先用
Ctrl+Shift+P输入View: Scroll to Selection定位到末尾，再手动选中最后 1000 行 → 右键 →Find in Selection - 关掉
regex模式：日志搜索多数是字符串匹配，勾选.*图标反而让引擎启动 NFA，关掉后速度提升明显
large_file_size_limit 设 100 不生效？它只管「新打开」，不管「实时追加」
"large_file_size_limit": 100 是 MB 单位，但它只影响「首次打开文件时」是否跳过语法分析。对已打开并持续追加的日志，Sublime 不会重新评估文件大小，仍按原模式渲染新行。所以你看到文件体积早超 1GB，但卡顿依旧，是因为这个配置压根没被触发。
实操建议：
- 真正起效的是 viewport 控制：
"viewport_size": 5000（字符数），它让 Sublime 只渲染可视区域前后各 2500 字符，滚动时动态加载，内存占用直降 95% - 配合
"ignore_whitespace_on_load": true，跳过日志里大量空格/制表符的归一化处理，避免字符串切片开销 - 不要设
"large_file_threshold": 0或负数——Sublime 会忽略该值，回退到默认行为
