应响应FormClosing事件并设e.Cancel = true来阻止Alt+F4关闭窗体，因Alt+F4触发系统级WM_SYSCOMMAND消息，ProcessCmdKey等键盘拦截不可靠；需结合_closeFlag等标志区分用户关闭方式。
如何在C# WinForms中阻止Alt+F4关闭窗体
Alt+F4 触发的是窗体的 FormClosing 事件，不是键盘预处理能直接“屏蔽”的快捷键——你不能靠拦截 KeyDown 就稳住它，因为系统级快捷键在消息到达控件前就已触发关闭流程。真正可靠的方式是响应并取消该事件。
-
FormClosing事件中检查e.CloseReason == CloseReason.UserClosing，这是 Alt+F4 或点击关闭按钮的典型标识 - 设置
e.Cancel = true即可阻止关闭，但注意：这不会阻止任务管理器结束进程，也不影响Application.Exit()等主动退出调用 - 别在
FormClosed里做取消操作——它已不可逆，此时设e.Cancel完全无效
为什么重写ProcessCmdKey不推荐用于Alt+F4拦截
有人试过重写 ProcessCmdKey 并对 Keys.Alt | Keys.F4 返回 true，但这在多数情况下失效。Windows 对 Alt+F4 的处理发生在更底层（WM_SYSCOMMAND + SC_CLOSE），WinForms 默认已跳过键盘消息链直接响应。
-
ProcessCmdKey主要针对菜单快捷键或自定义命令，对系统级关闭无控制权 - 即使它偶尔“生效”，也依赖焦点控件和消息泵状态，行为不稳定，调试困难
- 某些 .NET 版本（如 .NET 6+ Windows Forms）中，该方法对 Alt+F4 的捕获率进一步下降
FormClosing中区分关闭来源的关键判断
用户可能通过多种方式试图关闭窗体：Alt+F4、标题栏×、任务栏右键关闭、甚至代码调用 this.Close()。若只想拦 Alt+F4，需排除其他 UserClosing 场景（比如程序内按钮触发的 Close()）。
- 仅靠
CloseReason.UserClosing不够精确——它涵盖所有用户发起的关闭，包括Close()调用 - 更稳妥的做法是结合标志位：在你自己的关闭按钮点击中设
_allowClose = true，然后在FormClosing中检查!_allowClose && e.CloseReason == CloseReason.UserClosing - 不要依赖
Control.ModifierKeys判断 Alt 键状态——此时键盘消息早已过去，值不可靠
WPF项目怎么办？不是WinForms
WPF 没有 FormClosing，对应的是 Window.Closing 事件，逻辑一致但签名不同：参数是 CancelEventArgs，同样靠 e.Cancel = true 阻止。
- WPF 中 Alt+F4 同样走
Closing，且CloseReason不可用——WPF 不提供该枚举，只能靠上下文判断 - 若需区分，建议统一用命令（
ICommand）触发关闭，并在命令执行时设标记，再在Closing中检查 - 避免 hook
PreviewKeyDown去吃掉 Alt+F4：和 WinForms 的ProcessCmdKey一样，不可靠，且会干扰辅助工具（如屏幕阅读器）
实际最简可行代码就一行关键逻辑：e.Cancel = (e.CloseReason == CloseReason.UserClosing);，但要不要取消、何时取消，得看你真正想守住什么——是防止误关，还是禁止所有用户退出？这点一旦模糊，后面所有拦截都容易变成障眼法。
