WinForms高DPI适配需三步：设AutoScaleMode为Dpi（InitializeComponent后）、manifest启用PerMonitorV2 DPI Awareness、自绘时用GetDpiForWindow换算尺寸与字体。
WinForms在4K或高DPI屏幕下模糊，不是代码写错了，而是系统默认把它当“老古董”强行拉伸——你得明确告诉Windows：“我自己会算尺寸，别动我的像素。”否则所有控件、字体、自绘内容都会糊成一片。
app.manifest里必须启用PerMonitorV2 DPI Awareness
只改AutoScaleMode没用，清单文件才是系统识别DPI能力的“身份证”。缺这一步，哪怕代码全对，副屏切换时UI照样错位、文字发虚。
-
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>只是基础声明，已过时，必须配合PerMonitorV2 -
<dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>才是关键，要求Windows 10 1607+，支持每块显示器独立缩放 - VS项目属性 → “应用程序” → 必须勾选“启用Visual Studio生成清单文件”，否则
.manifest不会打包进exe - 不要用
System或Unaware模式——前者仍走系统虚拟化，后者直接糊到底
this.AutoScaleMode = AutoScaleMode.Dpi要放在InitializeComponent()之后
设计器生成的InitializeComponent()会重置AutoScaleMode为Font（默认值），而Font模式在非整数缩放（比如125%、150%）下计算严重失准，导致控件堆叠或留白异常。
- 必须写在
InitializeComponent()调用之后、Show()或Application.Run()之前 - .NET Framework 4.7+ 和 .NET Core 3.0+ 才真正支持
Dpi模式生效；旧版本即使设了也无效 - 如果窗体用了
LayoutControl或TableLayoutPanel，还要检查子控件是否也继承了缩放行为，否则布局仍会崩
自绘逻辑里别信Graphics.DpiX，改用GetDpiForWindow
很多开发者在OnPaint里用e.Graphics.DpiX算缩放比例，结果在多屏不同DPI下返回值错乱——因为GDI+的DpiX是逻辑DPI，不是物理DPI，PerMonitorV2下它根本不更新。
- 正确做法：P/Invoke调用
GetDpiForWindow(this.Handle)，返回真实物理DPI（如144、192） - 换算缩放比直接用
(double)dpi / 96，这个值可安全用于字体大小、边距、线条粗细等计算 - Windows 10 1607以下系统不支持
GetDpiForWindow，需fallback到GetDeviceCaps(hdc, LOGPIXELSX) - 第三方控件（比如老旧
ListView重绘）若硬编码像素值（如DrawLine(..., 0, 20, ...)），必须手动乘上缩放比，否则线条永远在20px位置“钉死”
设计器缩放提示“请设置为100%”不是警告，是陷阱
VS设计器本身不支持高DPI感知，它强制按96 DPI渲染设计界面。如果你在150%缩放的系统下打开设计器，它会把控件坐标按逻辑像素显示，但实际运行时按物理DPI渲染——结果就是“设计时正常，运行时乱飞”。
- 这不是Bug，是VS设计期与运行期DPI处理机制分离导致的固有限制
- 不要为了设计器方便把系统缩放调回100%，那会掩盖真实问题
- 验证适配效果唯一可靠方式：编译后直接双击exe运行，观察多屏切换、缩放切换（Win+Plus/Minus）下的表现
- 特别注意OwnerDraw控件和自定义
Panel，它们最容易在设计器里看着对、跑起来全偏
