WinForms高DPI自适应设置方法

WinForms高DPI自适应核心是设置AutoScaleMode为Dpi并配合Application.SetHighDpiMode(PerMonitorV2)，利用布局容器与DPI感知机制实现多显示器动态缩放。

WinForms实现高DPI自适应，核心思路其实就那么几条：首先是利用好框架提供的 AutoScaleMode 属性，将其设置为 Dpi 或 Font。但光靠这个还远远不够，尤其是在面对复杂布局或自定义绘制时，我们往往需要更细致、甚至手动介入的调整。对于现代.NET应用，引入 Application.SetHighDpiMode 更是必不可少的一步。

解决方案： 说实话，WinForms的高DPI自适应一直是个让人有点头疼的问题。它不像WPF那样天生就支持矢量缩放，WinForms更像是“像素为王”的时代产物。但我们并非束手无策。

最基础也最关键的一步，是为你的 Form 和所有 UserControl 设置 AutoScaleMode 属性。我个人倾向于使用 Dpi，因为它直接基于屏幕DPI进行缩放，相比基于字体大小的 Font 模式，在不同DPI下的表现通常更稳定、更符合预期。当你把 AutoScaleMode 设置为 Dpi 后，WinForms会在运行时根据当前系统的DPI设置，自动调整控件的大小和位置。这听起来很美好，对吧？但现实往往是，它只解决了部分问题。

比如，在一个典型的 .NET 5/6/7/8 WinForms项目中，你需要在 Program.cs 文件中，在创建主窗体之前，添加一行代码来告诉应用程序如何处理DPI：

ApplicationConfiguration.Initialize(); // 或者 Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false);
Application.SetHighDpiMode(HighDpiMode.SystemAware); // 或者 PerMonitorV2
Application.Run(new MainForm());

HighDpiMode.SystemAware 意味着应用程序会在启动时感知到DPI，并进行一次整体缩放。而 HighDpiMode.PerMonitorV2 则更进一步，它允许你的应用在不同DPI的显示器之间移动时，能够实时、动态地调整自身大小，这在多显示器工作环境下尤其重要。我的经验是，如果条件允许，尽可能选择 PerMonitorV2，虽然它可能带来一些新的挑战，但用户体验会好很多。

当然，仅仅设置这些还不够。布局的灵活性至关重要。我发现，那些大量使用 Anchor、Dock 属性，以及 TableLayoutPanel、FlowLayoutPanel 等布局容器的窗体，在高DPI下的表现总是比那些依赖固定 Location 和 Size 的窗体要好得多。它们天生就更“弹性”。对于自定义绘制的控件，你可能需要在 OnPaint 方法中，根据 e.Graphics.DpiX 或 e.Graphics.DpiY 来手动调整绘制的坐标和大小，甚至缩放图片资源。

WinForms高DPI自适应的核心原理是什么？

说到核心原理，我觉得可以从Windows自身的DPI缩放机制和WinForms的响应机制两方面来看。Windows操作系统本身就有一套DPI缩放逻辑，它会根据显示器的DPI设置，将UI元素放大或缩小，以确保在不同分辨率和尺寸的屏幕上，用户看到的文本和控件大小保持相对一致。

WinForms作为基于GDI+的UI框架，它并没有内置像WPF那样的矢量图形渲染能力。它的“自适应”更多的是一种“事后调整”或者说“基于测量值的缩放”。当你把 AutoScaleMode 设置为 Dpi 时，WinForms会记录下设计时（或者说首次加载时）的DPI值，然后在运行时，它会比较当前系统的DPI与设计时的DPI。如果DPI发生了变化，WinForms就会遍历窗体上的所有控件，根据DPI的比例因子（比如，从96 DPI到192 DPI，比例因子就是2），来重新计算并设置每个控件的 Size 和 Location。

这个过程，你可以简单理解为WinForms在背后悄悄地调用了控件的 Scale 方法。它会尝试缩放控件的字体、边框、内边距等等。但是，这种缩放并非完美无缺。例如，如果你在设计时使用的图片是固定的像素大小，那么在高DPI下，图片可能会被拉伸模糊，而不是被高质量地重新渲染。这就是为什么我说它更像是一种“基于像素的缩放”，而不是真正的矢量缩放。理解这一点，对于我们后续如何处理图片、自定义绘制等问题至关重要。

为什么我的WinForms应用在高DPI屏幕上看起来还是模糊或布局错乱？

这绝对是WinForms开发者最常遇到的痛点之一。我见过太多这样的情况，明明设置了 AutoScaleMode.Dpi，结果应用在高DPI屏幕上，要么文字模糊得像打了马赛克，要么控件挤成一团，甚至重叠起来。

其中一个常见的原因是图片资源处理不当。如果你在应用中使用了位图（BMP, PNG, JPG等），并且这些图片是为低DPI（比如96 DPI）设计的，那么当系统DPI翻倍到192 DPI时，WinForms会简单地将这些图片放大两倍。结果就是图片变得模糊不清。正确的做法是提供多套不同分辨率的图片资源，或者使用矢量图（如SVG），并在运行时根据DPI动态加载或缩放。当然，SVG在WinForms中原生支持并不好，通常需要第三方库或自己实现渲染。

再者，硬编码的像素值是布局错乱的罪魁祸首。很多开发者习惯于在设计器中直接设置控件的 Width、Height，或者在代码中用 new Size(X, Y) 来固定尺寸。一旦DPI发生变化，这些固定值就成了障碍。我的建议是，尽可能利用 Anchor（锚定）、Dock（停靠）属性，以及 TableLayoutPanel 和 FlowLayoutPanel 这类布局容器。它们能让控件的尺寸和位置根据父容器的变化而弹性调整，从而更好地适应DPI缩放。

还有一种情况是自定义绘制。如果你在 OnPaint 方法中直接使用了 e.Graphics.DrawLine(pen, x1, y1, x2, y2) 这样的代码，而没有考虑DPI缩放因子，那么在高DPI下，线条可能会显得过细，或者绘制的位置不准确。你需要在绘制前，获取当前的DPI缩放因子，然后将所有的坐标和尺寸都乘以这个因子。例如，float scaleFactor = e.Graphics.DpiX / 96.0f; 然后 e.Graphics.DrawLine(pen, x1 * scaleFactor, y1 * scaleFactor, x2 * scaleFactor, y2 * scaleFactor);

最后，别忘了第三方控件。有些老旧的或设计不当的第三方控件可能根本就没有考虑DPI自适应，或者只支持部分模式。这时候，你可能需要寻找替代品，或者尝试通过继承并重写其 ScaleControl 等方法来强制进行缩放，但这通常会比较麻烦。

如何在WinForms中实现更精细的Per-Monitor DPI自适应？

Per-Monitor DPI自适应，顾名思义，就是让你的应用在不同DPI的显示器之间移动时，能够智能地、实时地调整自身大小和布局，以保持视觉上的一致性。这在多显示器工作场景下，尤其是在笔记本外接高分屏时，体验差异是巨大的。

要实现这种更精细的Per-Monitor DPI自适应，我们主要依赖于 .NET Core/.NET 5+ 引入的 HighDpiMode.PerMonitorV2 模式。

首先，你需要修改 Program.cs 文件，将 Application.SetHighDpiMode 设置为 PerMonitorV2：

// Program.cs
ApplicationConfiguration.Initialize();
Application.SetHighDpiMode(HighDpiMode.PerMonitorV2);
Application.Run(new MainForm());

光有这行代码还不够，你还需要在应用程序的 app.manifest 文件中声明DPI感知模式。如果你的项目没有 app.manifest 文件，可以在项目上右键 -> 添加 -> 新建项 -> 搜索“应用程序清单文件”来添加。然后，在 节点内部，添加或修改 元素：