Sublime滚动卡顿源于渲染层重排而非加载慢，主因是word_wrap开启、gutter/行号/高亮行等布局计算及插件全量扫描；需禁用word_wrap、设viewport_size为5000、验证GPU加速生效、按语法类型配置轻量设置。
滚动卡顿不是加载慢，是渲染层在反复重排
Sublime 滚动卡顿和文件是否“加载完成”无关，而是 GPU 或 CPU 渲染器在处理超长行、高亮、gutter 图标时不断重排布局。尤其当 word_wrap 开启且某行长达数万字符，Sublime 会为每个软换行位置做字符串切片+测量，一帧卡几百毫秒。
关键判断：快速拖动滚动条时，光标悬停 gutter 区域是否明显延迟响应？如果是，问题大概率出在 line_numbers、gutter、highlight_line 这三项的 DOM 节点生成上。
-
word_wrap必须设为false，否则viewport_size再小也无效 -
viewport_size建议设为5000（默认100000），但仅对当前视口内字符生效，不减少内存占用，只降低单次渲染量 - 不要依赖
scroll_past_end或preview_on_click，它们不缓解滚动卡顿
GPU 加速开了但没生效？看控制台日志才作数
改了 hardware_acceleration 配置不等于 GPU 就跑了。Sublime 不提示、不报错，只默默 fallback 到软件渲染——你感觉不到区别，直到滚动时 CPU 拉满。
必须打开控制台（Ctrl+`），输入 sublime.log_commands(True)，再滚动一个真实大文件（比如 50MB 的 access.log），盯住输出：
- 看到
OpenGL context created（Windows/Linux）或Metal context created（macOS）→ 成功 - 看到
Failed to create OpenGL context或software rendering fallback→ 失败
hardware_acceleration 只认字符串值："opengl"（Win/Linux）、"metal"（macOS）、"none"（禁用）。写 true、"on"、1 全部被忽略。
插件在后台偷偷扫全文，比 Sublime 自身还慢
即使你关了语法高亮、设了 Plain Text，某些插件仍会在文件加载后几秒内触发全量扫描：
-
SublimeLinter默认对每个新打开文件跑 lint，不识别大文件阈值 -
GitGutter在on_modified中逐行 diff，千万行日志里每行都调一次git status -
BracketHighlighter光标一悬停就尝试匹配括号，长行正则回溯直接冻结 UI
验证方法：终端执行 subl --safe-mode huge.log，如果秒开且滚动流畅，问题 90% 出在插件。临时禁用可加到用户设置："ignored_packages": ["SublimeLinter", "GitGutter"]。
syntax-specific 设置才是安全开关，别碰全局 line_numbers
全局设 "line_numbers": false 看似省事，实则反向伤害日常开发——写 Python 时没了行号，查错效率暴跌。真正该做的是按语法类型覆盖：
打开一个大日志文件 → 确认右下角显示为 Plain Text 或 Log → 执行 Preferences → Settings – Syntax Specific → 在生成的 Plain Text.sublime-settings 里写：
{"line_numbers": false,"gutter": false,"highlight_line": false,"draw_white_space": "none"}
这样 .log、.out、.dump 文件自动套用轻量配置，而 .py、.js 仍保持完整编辑体验。注意：这个文件必须保存在 Packages/User/ 下，且文件名严格匹配语法名（如 Plain Text.sublime-settings，不能写成 plain_text.sublime-settings）。
