在C#桌面应用开发中，屏幕截图功能常用于远程协助、屏幕录制、自动化测试等场景。实现该能力的核心在于访问Windows图形子系统，将显示缓冲区中的像素数据捕获到托管代码的位图对象里。传统做法依赖System.Drawing命名空间下的GDI+封装，这种方式上手简单且与WinForms技术栈无缝集成。理解截图背后的坐标体系和设备上下文概念，是写出稳定代码的前提。
一、基于GDI+的屏幕截图基础实现
GDI+是Windows平台传统的二维图形接口，C#通过System.Drawing.Graphics类暴露了其大部分能力。截图操作的本质就是创建一个与目标屏幕区域等大的Bitmap画布，然后利用Graphics对象的CopyFromScreen方法，将屏幕设备上下文的像素直接绘制到我们的内存画布上。这个过程不涉及任何压缩或编码，得到的是原始的ARGB像素数据，方便后续处理与保存。
在具体编码时，首先需要确定要截取的区域范围。对于最简单的全屏截图，可以使用Screen.PrimaryScreen.Bounds获取主显示器的逻辑分辨率矩形。需要注意的是，Bounds属性返回的是以像素为单位的逻辑坐标，在未开启DPI缩放的系统中，它等同于物理像素；但在高分屏上，它可能不等于实际物理像素数，这点我们会在第二节展开。下面的代码展示了最基础的单屏截图实现，它能在绝大多数传统桌面环境下工作。
using System;
using System.Drawing;
using System.Windows.Forms;
public class SimpleCapture
{
public static Bitmap CapturePrimaryScreen()
{
// 获取主屏幕逻辑边界
Rectangle bounds = Screen.PrimaryScreen.Bounds;
Bitmap bmp = new Bitmap(bounds.Width, bounds.Height);
using (Graphics g = Graphics.FromImage(bmp))
{
// 将屏幕左上角像素复制到画布原点
g.CopyFromScreen(bounds.X, bounds.Y, 0, 0, bounds.Size);
}
return bmp;
}
}
上述代码虽然简短，但揭示了截图的三大要素：目标区域（bounds）、承载图像的Bitmap、执行拷贝的Graphics。这种方法的优势是零外部依赖，在.NET Framework和.NET Core（需安装System.Drawing.Common包）中均可运行。缺点是CopyFromScreen调用会触发跨进程图形数据拷贝，在主线程频繁调用可能造成界面卡顿，因此生产环境建议放在后台任务中执行。
另外，Bitmap对象在使用后必须及时调用Dispose释放GDI+资源，否则会引发句柄泄露。在上面的示例中，我们通过using语句确保Graphics释放，但返回的Bitmap交给了调用者，调用者有责任释放。若需保存为文件，可链式调用bmp.Save("shot.png", ImageFormat.Png)，但保存操作本身也可能抛出异常，需要异常捕获机制。对于初学者，容易忘记释放资源导致程序运行一段时间后报错，养成using习惯非常重要。
二、处理多显示器与高DPI缩放问题
现代办公环境常配备多台显示器，且系统可能设置了125%或150%的缩放比例。如果直接沿用第一节的主屏幕截图代码，当用户聚焦在副屏时，程序可能只截到主屏内容，或者截图尺寸与预期不符。要解决此问题，必须理解Windows坐标体系中的逻辑像素与物理像素区别。在启用了DPI感知的进程中，Screen.AllScreens集合里的Bounds给出的是逻辑坐标，而实际显卡输出的像素量需要通过乘以缩放因子获得。
为了截取所有显示器拼接而成的完整桌面，可以遍历Screen.AllScreens，利用Rectangle.Union计算出包容全部屏幕的总矩形。随后一次性拷贝该总区域。但需注意，若进程未声明DPI感知，Windows会采用兼容模式虚拟化坐标，导致Bounds返回的值被拉伸，此时截图可能模糊。推荐在程序清单或运行时调用SetProcessDpiAwareness声明感知级别，确保拿到真实分辨率，否则后续计算都会基于错误基准。
public static Bitmap CaptureAllScreens()
{
Rectangle total = Rectangle.Empty;
foreach (Screen s in Screen.AllScreens)
{
total = Rectangle.Union(total, s.Bounds);
}
Bitmap bmp = new Bitmap(total.Width, total.Height);
using (Graphics g = Graphics.FromImage(bmp))
{
// 注意total.Location可能是负坐标（副屏在左）
g.CopyFromScreen(total.Location, Point.Empty, total.Size);
}
return bmp;
}
当副屏位于主屏左侧时，其Bounds.X为负值，CopyFromScreen支持负源坐标，但目标画布坐标必须非负，因此代码中使用重载方法将源点映射到画布原点。如果忽略这一点，直接传入bounds.Left可能抛出异常。此外，高DPI下若想获取物理像素截图，应当查询每台显示器的ScaleFactor，将Bitmap尺寸乘以因子后再拷贝，并在拷贝时指定正确的源尺寸，否则图像会被拉伸变形，出现边缘虚化。
实践中，很多开发者发现截图模糊便盲目提高Bitmap分辨率，却未调整拷贝尺寸，结果只是放大了逻辑像素。正确的做法是在DPI感知模式下，使用Screen.GetBounds获取的值直接创建Bitmap，因为此时Bounds已反映真实像素。如果必须在非感知模式下运行，可通过PInvoke调用GetDeviceCaps获取桌面物理宽高，再执行拷贝。这种底层调用虽然繁琐，但能兼容老旧系统，是项目迁移时的临时方案。
三、捕获特殊窗口与性能优化策略
并非所有屏幕内容都能被GDI+的CopyFromScreen捕获。对于使用DirectX硬件加速的全屏游戏、或启用了桌面合成加速的某些窗口，GDI截图往往得到黑屏或空白图像。这是因为GDI截取的是窗口管理器维护的软件缓存，而硬件加速表面绕过该缓存直接写入显存。此时需要切换到Windows Graphics Subsystem的更底层接口，例如Desktop Duplication API（需Windows 8以上），它基于DirectX 11提供桌面纹理拷贝，能完美捕获包括视频播放在内的任何画面。
从架构角度看，如果项目仅需偶尔截图，GDI+方案足够；若要做实时屏幕共享，则应评估Desktop Duplication或第三方库如SharpDX。在性能优化方面，避免每帧都新建Bitmap，可采用对象池复用画布；拷贝操作尽量指定最小必要区域，减少像素传输量。以下伪代码展示了后台线程截图的骨架，通过定时采集降低对UI线程的影响，同时利用using确保资源回收。
// 后台定时截图示例
System.Threading.Tasks.Task.Run(() =>
{
while (running)
{
using (var bmp = CapturePrimaryScreen())
{
// 将bmp送入处理队列，注意跨线程访问UI需调度
ProcessFrame(bmp);
}
System.Threading.Thread.Sleep(100);
}
});
在多线程环境中，Bitmap本身不是线程安全的，确保同一时刻只有一个线程在读写它。如果要将截图显示在WinForms的PictureBox上，必须通过Invoke将图像赋值操作封送到UI线程。另外，截图功能可能涉及用户隐私，发布软件时应明确告知并请求授权，避免法律合规风险。企业内网工具也建议在界面上常驻提示，告知用户截图正在进行。
最后，关于图像格式选择，PNG无损但体积大，JPEG有损但体积小，实时传输推荐JPEG质量70左右。若需进一步降低延迟，可考虑只截取变化区域（差分截图），利用BitmapData锁存像素并比对前后帧，仅编码差异矩形。这种高级策略能显著减少带宽，但编码复杂度也相应提升，团队需权衡维护成本。对于大多数业务系统，直接全屏压缩上传已能满足需求，无需过早优化。
屏幕截图ScreenCaptureGraphics修改时间：2026-09-14 15:31:19