WinForms 中用 KeyDown 事件获取按下的 Keys 值最直接，通过 KeyEventArgs.KeyCode（如 Keys.A、Keys.F1）或 KeyData（含组合键如 Keys.Control | Keys.S）即可准确识别物理按键。
WinForms 中用 KeyDown 事件获取按下的 Keys 值最直接
WinForms 窗体或控件（如 TextBox、Panel）只要获得焦点，就能通过 KeyDown 事件拿到原始按键信息。关键不是“监听全局”，而是“响应当前焦点控件的按键”。
常见错误是把事件绑在窗体上却没设 KeyPreview = true，导致子控件（比如文本框）吞掉事件，窗体收不到。
-
KeyEventArgs.KeyCode返回的是Keys枚举值，例如Keys.A、Keys.F1、Keys.Left -
KeyEventArgs.KeyData包含组合键信息（如Keys.Control | Keys.S），比单纯看KeyCode更可靠 - 避免用
KeyPress事件读功能键——它只触发字符键，Keys.F5、Keys.Tab这类根本不会进来
.NET 6+ 的 Console.ReadKey() 只适用于控制台程序
如果是在命令行工具里做交互，Console.ReadKey(intercept: true) 是唯一能实时捕获按键的方式，返回 ConsoleKeyInfo，其 Key 属性对应 ConsoleKey 枚举。
注意：Console.ReadKey() 会阻塞线程，不能直接扔进 UI 线程；也不能在 WinForms/WPF 后台线程里调用它来“偷偷监听”——控制台输入句柄不属于 GUI 程序。
- 返回值
ConsoleKeyInfo.Key和 WinForms 的Keys枚举不兼容，比如ConsoleKey.A≠Keys.A - 想在控制台中识别 Ctrl+C，得检查
ConsoleKeyInfo.Modifiers，而不是只看Key - 别在循环里无条件调用
Console.ReadKey()却不加超时或退出判断，容易卡死
全局钩子（SetWindowsHookEx）才能真正捕获任意窗口的按键
WinForms 或 WPF 自身机制无法跨进程监听键盘，必须调用 Windows API 的低级钩子。核心是 SetWindowsHookEx(WH_KEYBOARD_LL, ...)，配合一个静态回调函数。
这不是“加个事件就行”的级别：它运行在系统消息层面，所有参数和内存管理都需严格匹配，稍错就导致程序崩溃或钩子失效。
- 回调函数必须是静态的，且标记
[UnmanagedFunctionPointer(CallingConvention.StdCall)] - 钩子过程里不要调用任何托管对象（如
Console.WriteLine、UI 控件属性），否则极大概率引发AccessViolationException -
LowLevelKeyboardProc返回非零值表示“已处理”，该按键就不会继续下发；返回 0 才放行——这点常被反着写 - .NET Core/.NET 5+ 默认禁用部分 P/Invoke 调用，需在项目文件加
true
WPF 里用 PreviewKeyDown 比 KeyDown 更早拦截
WPF 的路由事件机制决定了 PreviewKeyDown 在冒泡前触发，比 KeyDown 多一层控制权。尤其对 TextBox 这类自带行为的控件，想禁用 Backspace 或方向键，必须在这里下手。
但要注意：WPF 的 Key 属性（如 e.Key == Key.LeftCtrl）和 WinForms 的 Keys 枚举不是同一套体系，不能混用判断逻辑。
-
e.Key是 WPF 自己的Key枚举，比如Key.System对应 Alt，Key.LeftCtrl不等于Keys.LControlKey - 想判断 Ctrl+S 组合，应同时检查
Keyboard.Modifiers和e.Key，而不是拼KeyBinding——后者只适用于命令绑定场景 - 若在
PreviewKeyDown中设e.Handled = true，后续的KeyDown和输入法处理都会被跳过
真正难的不是拿到 Key 值，而是搞清“谁在发这个 Key”、“当前焦点在哪”、“有没有其他组件已经劫持了它”。很多问题表面是“没收到按键”，实际是焦点丢失、事件被吞、或者钩子没正确卸载导致残留。调试时先确认 FocusManager.GetFocusedElement 返回什么，比盲目加断点更有效。
