Ctrl+Shift+K没反应通常因被输入法、插件或只读状态截获；可通过Preferences→Key Bindings检查用户绑定，若存在覆盖则删除或注释；无覆盖时排查输入法热键冲突或文件只读状态。
Ctrl+Shift+K 为什么按了没反应
它不是坏了，是被截胡了。最常卡在三处：Ctrl+Shift+K 被中文输入法（搜狗、QQ 拼音、微软拼音）默认设为中英文切换键；插件如 Emacs Pro Essentials 或 SideBarEnhancements 在用户键绑定里覆盖了原生命令；文件右下角显示 Read Only 时，所有编辑快捷键都会静默失效。
怎么确认当前快捷键绑定了哪个命令
打开 Preferences → Key Bindings，左侧是默认绑定，右侧是用户自定义绑定。在右侧搜索 "ctrl+shift+k"，看有没有类似这样的行：
{ "keys": ["ctrl+shift+k"], "command": "some_other_command" }
如果有，删掉或注释掉这行；如果没有，说明没被覆盖，问题大概率出在输入法或只读状态。
想换快捷键？别手写 JSON，用命令面板更稳
按 Ctrl+Shift+P（Win/Linux）或 Cmd+Shift+P（macOS），输入 Preferences: Key Bindings – User 回车，就会直接打开用户键绑定文件。在里面加一行即可：
{ "keys": ["ctrl+shift+l"], "command": "delete_line" }
注意：command 值必须是 delete_line，不是 delete_to_beginning_of_line 或拼错的变体，否则绑定静默失败。
删行后光标跳到上一行末尾？这是设计，不是 bug
delete_line 命令会把整行（含换行符）移除，所以下一行自动上顶，光标落在上一行末尾——这个行为会影响后续操作，比如你刚删完第 5 行，接着按 Ctrl+L，选中的其实是“新”的第 5 行（原第 6 行）。如果同时处理多光标或正则匹配，这点尤其容易导致错位。真正要小心的不是快捷键本身，而是删行后光标位置对下一步操作的隐性影响。
