Windows窗体磁性吸附本质是拖动中通过WndProc拦截WM_MOVING消息，在系统移动前修正Location；需统一DPI坐标单位，按方向独立计算边界距离并写回lParam。
Windows 窗体拖动时怎么监听边缘碰撞
磁性吸附的本质，不是“自动吸过去”，而是「在窗体即将越过屏幕或其它窗体边界时，主动修正 location」。关键在于捕获拖动过程中的位置变化——但 winforms 默认不暴露拖动中的实时坐标，得靠重写 wndproc 拦截 wm_moving 消息。
这个消息会在用户拖动窗体边框、标题栏时持续触发，且系统会把待更新的矩形区域（含左上角坐标）通过 lParam 传入，比轮询 Location 或监听 Move 事件更准、更及时。
-
WM_MOVING是唯一能拿到“即将到达的位置”的时机；用Move事件只能拿到“已经移完的位置”，吸附会滞后甚至抖动 - 必须在
WndProc中调用base.WndProc(ref m)前处理，否则系统已按原坐标移动，再改就无效 - 别用
SetWindowPos强制重设——它会再次触发WM_MOVING，导致无限递归或卡死
C# 怎么获取当前屏幕和相邻窗体的可吸附边界
吸附目标只有两类：显示器工作区（Screen.FromHandle(Handle).WorkingArea）和其他顶层窗体（FindWindowEx 遍历，过滤掉子窗、隐藏窗、任务栏等）。
特别注意：多屏环境下，Screen.PrimaryScreen 不可靠；必须用 Screen.FromHandle(Handle) 拿到当前窗体所在的屏，否则跨屏拖动时吸附逻辑会错乱。
- 显示器边界要用
WorkingArea，不是Bounds——后者包含任务栏区域，会导致窗体被“吸”进任务栏下面 - 判断其他窗体是否可吸附，至少要满足：
IsWindowVisible为真、GetWindowLong(hwnd, GWL_EXSTYLE)不含WS_EX_TOOLWINDOW、且不是自身句柄 - 建议只对
WS_OVERLAPPEDWINDOW类型窗体做吸附，避免干扰对话框、通知窗口等临时 UI
为什么吸附距离设成 10 像素却没反应
常见问题不是代码没写，而是阈值判断逻辑有漏洞：直接比对窗体四边与目标边界的绝对差值，忽略了窗体自身的尺寸和方向。
比如右边界吸附，应判断的是 this.Right - target.Left 是否在 [0, 吸附距离] 内，而不是 this.Location.X - target.Location.X。漏掉宽度、高度参与计算，等于拿错了参考点。
- 每个方向（左/右/上/下）需独立计算：例如“左吸附”看
this.Left和target.Right的距离，“上吸附”看this.Top和target.Bottom - 吸附生效后，要一次性修正全部相关边——比如右边缘贴住另一窗体左边缘，同时可能左边缘也接近主屏左边界，得优先处理更高优先级的（如屏幕边界 > 其他窗体）
- 修正坐标后，必须把新矩形写回
lParam指向的内存（用Marshal.WriteInt32），否则系统仍按原值移动
WinForms 磁吸在高 DPI 下偏移怎么办
根本原因是：当系统 DPI > 100% 时，WM_MOVING 传入的坐标是 DPI 缩放后的逻辑坐标，但 Screen.WorkingArea 返回的是物理像素值。两者单位不一致，比较结果必然出错。
解决方案不是禁用 DPI 感知，而是统一换算：调用 Graphics.FromHwnd(Handle).DpiX 获取当前缩放比例，再将 WorkingArea 的坐标除以该比例，转成逻辑单位参与比较。
- 别用
AutoScaleMode = DPI试图让窗体自动适配——它影响的是控件布局，不改变WM_MOVING的坐标体系 - 如果应用设为
PerMonitorV2高 DPI 模式，需监听WM_DPICHANGED并缓存当前 DPI，否则跨屏拖动时缩放比例突变会导致吸附跳变 - 调试时可在
WndProc里打印原始lParam解析出的矩形和WorkingArea值，一眼看出单位是否对齐
真正麻烦的从来不是算距离，而是搞清每一步坐标是在哪个空间里——逻辑坐标、设备坐标、DPI 缩放前还是后。漏掉一次单位转换，整个吸附就漂移了。
