Ctrl+Shift+K（Windows/Linux）或Cmd+Shift+K（macOS）在Sublime Text中默认执行right_delete，即从光标位置删至本行末尾（不含换行符），不跨行、不吞换行符、原子性生效，非删整行。
Ctrl+Shift+K 是删到行尾，不是删整行
很多人按 Ctrl+Shift+K 后发现整行没了，以为它“失效”或“太猛”，其实是误解了它的行为：在绝大多数默认配置下，Ctrl+Shift+K 执行的是 right_delete，即「从光标位置删到本行末尾（不含换行符）」。它不会吞掉换行符，所以上一行不会和下一行连起来。
常见错误现象包括：
- 光标在行中时按了没反应——检查是否已开启软换行（
soft_wrap: true），此时End键停在视觉行尾，但Ctrl+Shift+K仍作用于物理行尾，表现正常 - 删完发现光标“卡住”在原位——这是对的，它删完后光标留在原位置（现在就是行尾）
- 多光标下只删了部分行——确保所有光标都在有效文本行内，空行或仅含空白符的行可能被跳过
为什么不要用 Ctrl+K, Ctrl+K 替代？
Ctrl+K, Ctrl+K 表面看也删到行尾，但它本质是两步操作：set_mark + delete_to_mark，依赖临时标记点。一旦中间误触方向键、鼠标或切换 Tab，标记就丢失，第二次 Ctrl+K 就变成空操作。
更麻烦的是，在多光标场景下，每个光标独立设 mark，但删除时执行顺序不可控，容易漏删某一行。而 Ctrl+Shift+K 是原子命令，每次触发都独立生效，不残留状态。
使用场景上：Ctrl+K, Ctrl+K 更适合需要“先锚定再删”的复合操作（比如删到下一个括号），日常清尾注释、砍日志时间戳，Ctrl+Shift+K 更稳更快。
删整行和删到行尾别混用
同一个快捷键 Ctrl+Shift+K 在不同上下文里行为不一致，这是最易踩的坑：
- 如果当前没有选中文本，且光标不在行首/行尾特殊位置，它执行
right_delete（删到行尾） - 如果当前有整行被选中（比如刚按过
Ctrl+L），它会执行delete_line（删整行+换行符） - 某些插件（如旧版 Emacs Pro Essentials）可能强行重绑为
right_delete，但这种绑定不稳定，重启或更新后常失效
所以别靠“感觉”记快捷键，遇到异常，先确认当前是否处于选中状态，再查 Preferences → Key Bindings 里有没有冲突规则。
macOS 用户注意 Cmd+Shift+K 的行为一致性
macOS 下对应的是 Cmd+Shift+K，逻辑完全一致，但要注意系统级热键冲突：
- 某些输入法（如搜狗、百度）会劫持
Cmd+Shift+K做中英文切换，导致 Sublime 不响应 - 终端或远程桌面工具（如 Microsoft Remote Desktop）有时会拦截该组合键，需在客户端设置里关闭“发送修饰键”
- Sublime 自身不区分大小写绑定，但 macOS 系统偏好设置里的“键盘快捷键”若自定义过类似组合，优先级更高
真要验证它是否生效，打开命令面板（Ctrl+Shift+P / Cmd+Shift+P），输入 right_delete，手动运行一次看效果——这是绕过所有快捷键干扰的最终校验方式。
