Sublime 是否启用 GPU 渲染需手动验证：控制台显示“OpenGL context created”且滚动大文件不卡顿才生效；macOS 默认启用，Windows/Linux 易受驱动、远程桌面或 Wayland 影响；正确配置为 "hardware_acceleration": "opengl" 和 "gpu_window_buffer": true（ST4），但须完全重启；卡顿多因 index_files、插件监听或缩进检测等后台任务，而非 GPU 本身；若输入延迟明显，可设 "hardware_acceleration": "none" 回退至 CPU 渲染。
确认 Sublime 当前是否真在用 GPU 渲染
Sublime 不会弹窗告诉你“GPU 已启用”，它只默默尝试创建 OpenGL 上下文——成功了就跑，失败了就 fallback 到 CPU 渲染，还不报错。所以你得自己验证：
打开命令面板（Ctrl+`），看控制台里有没有 OpenGL context created；再滚动一个百万行日志文件，如果卡顿明显、掉帧严重，大概率没生效。
- 看到
Failed to create OpenGL context或software rendering fallback→ GPU 加速已失效 - macOS 上几乎默认生效（走 Core Graphics + Metal），Windows/Linux 则高度依赖显卡驱动和桌面环境
- 远程桌面（如 Windows RDP）、Wayland 下 GNOME、或禁用 GPU 的企业策略，都会让
hardware_acceleration形同虚设
正确设置 hardware_acceleration 并启用辅助项
别写 true 或 on，Sublime 只认字符串值："hardware_acceleration": "opengl" 是唯一有效开关（ST4 默认值，但不保证实际生效）。加上 "gpu_window_buffer": true 能进一步优化高分屏或多标签下的缓冲区管理。
- 进
Preferences → Settings，在右侧用户设置中添加（不是左侧默认设置）：
{
"hardware_acceleration": "opengl",
"gpu_window_buffer": true
}
"hardware_acceleration": "none" 或 "direct3d" 的旧配置，否则会覆盖默认行为为什么开了 GPU 还卡？常见干扰项比渲染本身更致命
GPU 加速只是“图形输出通道”，而输入卡顿、按键延迟、光标跳动，90% 都跟它无关。尤其在 macOS M 系列芯片或 Intel UHD 集成显卡上，opengl 反而可能触发渲染线程阻塞。
-
"index_files": true（默认开启）→ 打开含node_modules的项目时，后台疯狂扫描数万文件，CPU 占满，敲字卡顿 - 插件实时监听：比如
GitGutter在每次按键后查 Git 状态，SublimeLinter开了on_input模式逐字符 lint -
"auto_complete_size_limit": 0（默认不限）→ 敲str.就加载整个项目符号表，卡两秒 - 伪卡顿：比如
"detect_indentation": true（默认），打开 50MB 日志时从头扫到尾猜缩进，期间完全无法输入
关 GPU 反而是最快解法？何时该果断切回软件渲染
如果你在 macOS（M1/M2）、Windows 笔记本（Intel UHD 620/630）、或某些 Linux 发行版上遇到输入延迟、方向键失灵、光标闪烁不同步，第一反应不该是升级驱动，而是试试关掉 GPU 渲染。
- 安全模式验证：关掉 Sublime，按住
Cmd（macOS）或Ctrl（Windows/Linux）再双击启动。如果此时变丝滑，说明问题出在插件或配置，而非 GPU - 确认是 GPU 冲突后，直接设
"hardware_acceleration": "none"—— 这是最彻底的 CPU 渲染方案，兼容性最好 - Windows 用户可选
"hardware_acceleration": "direct3d"，比 OpenGL 更稳，但不如"none"通用 - 务必删掉
"gpu_window_buffer": true（已废弃），留着可能干扰新版本行为
真正影响流畅度的，从来不是“开了没开 GPU”，而是你让 Sublime 同时干了多少件事。一个 index_files 关掉，比调十次 hardware_acceleration 更管用——但这个开关藏得深，很多人搜了一小时 GPU，却没翻到设置里第一行。
