Sublime Text 输入卡顿大概率非GPU所致，而是hardware_acceleration误启用或与驱动冲突；验证需用安全模式，禁用应设"none"并重启；真正元凶多为index_files、插件监听及自动补全等后台任务。
输入卡顿真是GPU惹的祸？先验证再动手
Sublime Text 输入卡顿，**大概率不是GPU加速的问题，而是它被错误地启用了或和显卡驱动冲突**。尤其在 macOS（M1/M2）或某些 Windows 集成显卡（如 Intel UHD 620）上，hardware_acceleration 设为 "opengl" 反而会触发渲染线程阻塞，导致按键延迟、光标跳动、甚至按住方向键不响应。
别急着关，先用安全模式验证：关掉 Sublime，按住 Ctrl（Windows/Linux）或 Cmd（macOS）再双击启动。如果此时输入丝滑了，说明问题出在插件或配置；如果依然卡，再怀疑 GPU 加速。
禁用GPU加速的正确姿势
禁用不是删掉配置，而是明确设为软件渲染或关闭——否则 Sublime 可能 fallback 到更不稳定的后端。
- 打开
Preferences → Settings，在右侧用户设置中添加： -
"hardware_acceleration": "none"—— 最彻底，强制 CPU 渲染，适合所有卡顿场景 - 或
"hardware_acceleration": "direct3d"（仅 Windows）—— 比 OpenGL 更稳，但不如"none"通用 - 删掉
"gpu_window_buffer": true这类旧版冗余项（它已废弃，留着可能干扰）
改完保存，**必须重启 Sublime**。仅重载设置无效，因为 GPU 上下文在进程启动时就已建立。
比关GPU更关键的输入卡顿元凶
真实项目里，90% 的“输入卡顿”其实和 GPU 无关，而是以下几项在后台抢资源：
当用户提及 GitHub URL，或要求分析、审查、探索或理解任意 GitHub 项目、仓库或代码库时，请使用此技能。触发条件包括以下短语：“分析这个项目”、“看看这个仓库”、“analyze this repo”、“what does this project do”，或消息中包含任何 github.com URL。
-
"index_files": true（默认开启）—— 打开含node_modules的项目时，Sublime 会在你敲字的同时扫描数万文件，CPU 占满，输入自然卡顿 - 插件实时监听：比如
GitGutter每次按键后检查 Git 状态，SublimeLinter在 on_input 模式下逐字符 lint Java/Python - 自动补全过大：
"auto_complete_size_limit": 0（默认不限制）会让 Sublime 尝试加载整个项目符号表，敲str.就卡两秒
建议同步加进用户设置：
{
"index_files": false,
"auto_complete_size_limit": 4096,
"spell_check": false
}
容易被忽略的“伪卡顿”陷阱
你以为是输入慢，其实是编辑器在等你“确认”——比如开启了 "auto_save_on_focus_lost": true，切回窗口瞬间触发保存+格式化+Lint，光标就僵住半秒；又或者 "detect_indentation": true（默认），打开一个 50MB 日志时，Sublime 会从头扫到尾猜缩进，期间完全无法输入。
这类问题不会报错，控制台也无红字，但只要关掉 "detect_indentation" 或设为 false，大文件里打字立刻恢复流畅。
真正要盯住的，从来不是“开了什么”，而是“它正在后台偷偷干什么”。卡顿不是性能不足，是任务没分清主次。
