Sublime Text 卡顿主因是插件不当轮询或事件监听：Clipboard History 默认500ms轮询剪贴板，易因系统工具响应慢而堆积异步调用；多光标复制常绕过标准事件导致历史丢失；Linux中xclip缺失或Wayland环境会拖慢初始化。
Sublime Text 本身不缓存剪贴板内容，所谓“读取性能”问题，90% 是插件在后台反复轮询或事件监听失当导致的卡顿，不是 Sublime 内核慢。
Clipboard History 插件默认会高频扫描剪贴板
它为每 500ms 检查一次系统剪贴板变化（可通过 poll_interval 配置），在 macOS 或 Linux 上若底层工具（xclip/xsel）响应慢，或 Windows 上被 Ditto/WeChat 截获，就会堆积未完成的异步调用，拖慢 UI 线程。
- 打开
Preferences → Package Settings → Clipboard History → Settings – User，加入：{ "poll_interval": 2000, "max_items": 30, "ignore_empty": true } - 避免设为
0（禁用轮询）：那样 Ctrl+Shift+V 就不会自动更新历史，得手动刷新 - 若只偶尔用历史粘贴，可干脆禁用自动监听，在需要时按
Ctrl+Shift+P输入Clipboard History: Refresh手动触发
多光标 + 复制 = 剪贴板事件丢失
MultiEditUtils、Emmet 等插件在多光标模式下常绕过 Sublime 的标准 on_post_text_command 链，导致 copy 事件不被 Clipboard History 捕获——你复制了，但历史里没存，下次调出面板就是空的。
- 临时解法：复制前按
Esc退出多光标，再用鼠标框选 +Ctrl+C - 长期解法：在
Key Bindings – User中重绑复制命令，强制走标准路径：[{"keys": ["ctrl+alt+c"], "command": "copy"}] - 别依赖
Ctrl+Shift+L后直接Ctrl+C：那只是创建光标，不触发复制逻辑
Linux 中键粘贴失败会连带拖慢剪贴板插件响应
启用 enable_middle_click_paste 后仍无反应，往往是因为 xclip 缺失或运行超时，而 Clipboard History 在初始化时会尝试调用它做兼容检测——失败后反复重试，造成启动延迟。
- 先确认环境：
which xclip必须有输出；若无，运行sudo apt install xclip（Ubuntu/Debian） - 检查是否在 Wayland 会话：该协议下
xclip不可用，此时应关闭enable_middle_click_paste，避免插件徒劳等待 - 在插件设置中加
"skip_primary_selection_check": true，跳过中键相关探测
真正影响体验的从来不是“读取快不快”，而是插件有没有在你不注意的时候反复调用系统 API。关掉轮询、避开多光标陷阱、清理底层依赖，比调任何性能参数都管用。
