C#窗体最大化禁用：一个被低估的“系统工程”
如果你认为只需将窗体的 MaximizeBox 属性设置为 false 就能彻底禁用最大化，那么你可能已经陷入了一个典型的误区。实际上，这仅仅是禁用了窗体右上角的可视化按钮，而Windows操作系统层面至少存在四五种常见方式可以绕过这一限制，导致你的窗体“失控”地铺满整个屏幕。
为什么一个简单的属性会失灵？
根本原因在于，MaximizeBox = false 只是一个用户界面层面的开关，它并未触及Windows窗口管理的核心机制。系统并不会因为这个属性的设置而停止响应那些深入人心的窗口操作习惯。例如：
- 用户习惯性双击标题栏？系统会收到
WM_NCLBUTTONDBLCLK消息，并执行最大化操作。 - 将窗口拖拽到屏幕顶部（利用Aero Snap功能）？同样会触发最大化。
- 用户或第三方代码直接调用
ShowWindowAPI，并传入SW_MAXIMIZE参数？此属性对此类调用毫无防御能力。 - 甚至使用系统级快捷键 Win + 上箭头，也能轻松实现窗体最大化。
更棘手的是，在多显示器或高DPI缩放环境下，此属性的行为可能变得更加“不稳定”，窗体有时会短暂“闪烁”进入最大化状态，这本质上是因为窗口的系统样式未被彻底清除。
治本之道：在消息层面“截胡”
要真正封堵所有漏洞，关键在于深入到Windows消息循环内部。我们需要重写窗体的 WndProc 方法，专门拦截代表系统命令的 WM_SYSCOMMAND 消息，并过滤掉其中与最大化、还原相关的指令。
protected override void WndProc(ref Message m)
{
const int WM_SYSCOMMAND = 0x112;
const int SC_MAXIMIZE = 0xF030;
const int SC_RESTORE = 0xF120;
const int SC_MOVE = 0xF012;
if (m.Msg == WM_SYSCOMMAND)
{
switch (m.WParam.ToInt32())
{
case SC_MAXIMIZE:
case SC_RESTORE:
case SC_MOVE: // 防止拖拽标题栏触发还原
return;
}
}
base.WndProc(ref m);
}
这里有一个关键细节：为什么连 SC_RESTORE（还原命令）也要拦截？因为当用户双击标题栏时，系统通常会先发送一个最大化命令，紧接着又发送一个还原命令。如果不拦截后者，窗体就会先最大化再立即还原，从而在视觉上产生令人不适的“抖动”效果。
构建防御体系：组合拳才有效
仅靠拦截消息还不够稳固，必须结合一套完整的窗体属性设置，构建多层次防御体系：
- 固定边框样式：将
FormBorderStyle设置为FixedSingle。这直接禁用了用户通过拖拽边框来调整窗体大小的能力（虽然None样式更彻底，但会失去整个标题栏，需谨慎权衡）。 - 保持UI一致性：依然设置
MaximizeBox = false。此举主要目的并非功能限制，而是为了保持界面逻辑的一致性，避免用户看到可用按钮时产生困惑。 - 显式设定尺寸：明确使用
this.Size = new Size(800, 600)这样的代码来固定窗体初始大小。这可以防止某些布局管理器（如Anchor属性）在高DPI缩放时进行意料之外的自动调整。
此外，如果窗体在初始化时就被设置为 WindowState = FormWindowState.Maximized，务必记得先将其改为 Normal 状态，否则后续的 WndProc 消息拦截可能会失效。
高DPI与多屏环境：那些隐藏的“坑”
现代Windows应用的运行环境日趋复杂，这带来了新的挑战。在125%或150%的DPI缩放下，FixedSingle 边框样式可能导致边框绘制模糊或内部控件布局轻微错位。而在多显示器场景中，直接使用 Screen.PrimaryScreen.WorkingArea 获取的是主显示器的工作区，未必是当前窗体所在屏幕的准确尺寸。
稳妥的应对策略包括：
- 在.NET 5及以上版本中，启用
Application.SetHighDpiMode(HighDpiMode.SystemAware)来改善应用程序的高DPI感知能力。 - 使用
Screen.FromControl(this).WorkingArea来动态获取窗体所在屏幕的正确工作区范围。 - 关于彻底禁用Aero Snap功能，虽然可以通过修改注册表项
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\DisallowSnap来实现，但这需要管理员权限且会影响整个系统，在生产环境中应极其慎重地考虑。
最后，还有一个极易被忽略的细节：即便完成了以上所有设置，如果未处理 WM_GETMINMAXINFO 消息，系统在用户拖拽窗体的过程中，仍可能根据内部算法计算出一个“最大尺寸”，导致窗体边缘偶尔能稍微被拖出边界。如果追求100%的绝对锁定，就需要额外重写此消息，并硬编码设置 ptMaxSize 和 ptMaxTrackSize 这两个关键参数。这，才是构建真正“铜墙铁壁”式窗体锁定方案的最终步骤。
