KeyPress无法捕获Ctrl+S等组合键，因其只处理可打印字符，不接收修饰键信息；应使用KeyDown（需KeyPreview=true）或ProcessCmdKey实现。
Ctrl+S 这类组合键不能用 KeyPress 捕获，必须用 KeyDown 或 ProcessCmdKey —— 因为 KeyPress 根本收不到 Ctrl 键信息。
为什么 KeyPress 对 Ctrl+S 完全无效
KeyPress 只处理“可打印字符”，它看到的是字母、数字、符号的 ASCII 值，而 Ctrl 是修饰键（Modifier），不产生字符。按下 Ctrl+S 时，KeyPress 甚至不会触发；即使触发，e.KeyChar 也只会是 '\x13'（ASCII 19，即 XOFF 控制符），既不可靠也不直观。
-
KeyDown能拿到完整的物理按键状态：e.Control、e.KeyCode、e.KeyData -
KeyPress的e.KeyChar无法区分 Ctrl+A 和 Ctrl+Shift+A - WinForms 默认不把快捷键事件“透传”给窗体，必须设
KeyPreview = true
KeyDown 事件怎么写才真正生效
直接在窗体上写 KeyDown 处理器是最快路径，但有三个硬性前提：
- 窗体的
KeyPreview属性必须设为true（否则焦点在 TextBox 时，窗体收不到事件） - 判断逻辑必须用
e.Control && e.KeyCode == Keys.S，别用e.KeyData == (Keys.Control | Keys.S)—— 后者会误判 Ctrl+Alt+S 等多修饰键场景 - 处理完要设
e.Handled = true和e.SuppressKeyPress = true，否则系统可能继续触发默认行为（比如在 TextBox 中插入乱码）
示例：
private void Form1_KeyDown(object sender, KeyEventArgs e)
{
if (e.Control && e.KeyCode == Keys.S)
{
SaveDocument();
e.Handled = true;
e.SuppressKeyPress = true;
}
}
ProcessCmdKey 适合什么场景
当你的快捷键需要“无视焦点在哪”都生效（比如 Ctrl+N 总是新建文档，哪怕当前 TextBox 正在编辑），就该重写 ProcessCmdKey —— 它比 KeyDown 更早拦截消息，且天然绕过控件级焦点干扰。
- 返回
true表示“我已处理”，后续事件链终止；返回false或调用base.ProcessCmdKey才会继续传递 - 用
keyData == (Keys.Control | Keys.S)是安全的，因为keyData是系统合成值，不含 Alt/Shift 冗余位 - 注意：如果窗体启用了菜单（
MainMenuStrip），某些 Ctrl+字母会被菜单自动吞掉，需检查ToolStripMenuItem.ShortcutKeys是否冲突
常见踩坑点：Ctrl+S 没反应，但 F1 或 Enter 可以
这不是代码问题，而是环境配置缺失：
- 忘了在构造函数里写
KeyPreview = true—— 这是最高频原因 - 快捷键被子控件“吃掉”了：比如 RichTextBox 默认响应 Ctrl+S，需手动禁用其
ShortcutsEnabled = false - 测试时没关输入法：中文输入法状态下，Ctrl+S 可能被输入法框架劫持，切到英文模式再试
- WPF 用户注意：
KeyDown在 WPF 中默认不冒泡到窗体，得用PreviewKeyDown或绑定KeyBinding
真正麻烦的不是写几行判断，而是确认快捷键路径没被任何一层（输入法、控件、菜单、焦点策略）悄悄截断——建议从最简空窗体开始验证，再逐步加功能。
