軟體截圖原理：為什麼全螢幕截圖
所以下一次当你遇到「全萤幕截图失败」，第一个该问的问题不是「哪个软体有问题」，而是「我当时到底是哪一种全萤幕」。光是这一层釐清，就能解释掉一半以上的疑难杂症。
二、主流截图技术的原理与差异
理解了画面的三层结构之后，我们就可以来看各种截图技术分别站在哪一层。不同技术的能力边界，完全可以由它所处的层级推导出来。以下按照技术演进顺序介绍，这也是多数截图软体内部 fallback（备用）策略的顺序。
2-1 GDI 与 BitBlt：最古老、最普及，也最容易踩雷
GDI（Graphics Device Interface）是 Windows 最早期的绘图介面，其中的 BitBlt 函式可以把一块装置内容（Device Context，DC）的像素区块复制到另一块。传统截图的做法就是取得整个桌面的 DC（呼叫 GetDC(NULL)），然后用 BitBlt 把画面复制到一张 DIB（Device Independent Bitmap）里，再存成 BMP 或 PNG。
这个方法在 Windows XP 时代几乎万能，因为当时没有 DWM，所有视窗都直接画在萤幕上。但在 Vista 之后，状况就变了：由于 DWM 的介入，BitBlt 对桌面 DC 的抓取会走一条「软体重定向」的路径，系统必须额外准备一份软件渲染的副本，效能较差，而且在某些情况下（特别是硬体加速内容、视讯覆叠层、受保护内容）会直接抓到黑色。更麻烦的是，BitBlt 有时候会抓到「上一帧」的画面，导致截图与当下所见有微妙的时间差，这也是为什么有些截图拍到的滑鼠游标位置怪怪的。
尽管有这些限制，GDI 方案仍然被大量软体保留作为最后的备用手段。原因很简单：它几乎不需要特殊权限，不需要 DirectX，相容性最好，在纯桌面、纯文件、纯浏览器画面的情境下，成功率依然很高。多数现代截图工具的设计逻辑是「先用新 API，失败再退回 GDI」，而不是完全舍弃它。
2-2 PrintScreen 与 Windows 内建剪取工具
键盘上的 Print Screen 键，长期以来是 Windows 使用者最直觉的截图方式。按下后，系统会把当前画面放进剪贴簿。这个动作在实作上是由系统层面的键盘处理程序（以 csrss.exe 或相关系统元件）负责，因此它可以取得比一般应用程式更高的权限视图，包括某些一般程式抓不到的系统介面。
不过要注意，Print Screen 抓的通常仍然是「DWM 合成后的桌面」，所以面对独占全萤幕游戏或 DRM 保护内容，一样会得到黑画面。Windows 10 之后的「剪取工具」与「剪取与草图」则进一步整合了 Window Graphics Capture 的精神，支援矩形、视窗、全萤幕等模式，并且在 Windows 11 上加入了 HDR 截图与自动 SDR 转换，是日常使用最省事的选择。
2-3 DXGI Desktop Duplication API：直接向 DWM 要桌面纹理
Windows 8 引入了 DXGI Desktop Duplication API，这是微软第一次提供「官方、高效能」的桌面撷取方案。它的原理是让应用程式建立一份「桌面复制输出（Desktop Duplication Output）」，直接接收 DWM 合成后送出的画面纹理。因为是 GPU 端的直接复制，效能极高，可以轻松做到 60fps 甚至更高的连续撷取，这也是许多录影软体与远端桌面工具的核心技术。
Desktop Duplication 的限制也很明确。第一，它抓的是「桌面」的内容，所以当应用程式进入独占全萤幕、绕过 DWM 时，它会抓到黑画面或冻结的旧画面，并可能回传 DXGI_ERROR_ACCESS_LOST 之类的错误。第二，它无法取得受保护内容（例如 Netflix 的 HDCP 串流），这部分会被系统直接以黑色填充。第三，它对多显示器与旋转萤幕的处理需要额外的座标换算，写不好就很容易出现「只截到主萤幕」的情况。
2-4 Windows Graphics Capture：目前最全面的官方方案
Windows 10 1803 之后加入的 Windows Graphics Capture（WGC）是目前最推荐的撷取方式。它的设计目标就是「把视窗或萤幕当作可撷取的对象」，因此它可以指定要抓某个视窗、某个显示器，或整个系统。由于它同样基于 DWM 的合成结果，能捕捉绝大多数以 GPU 渲染的内容，包括硬体加速的浏览器、Direct3D 应用、部分游戏视窗。
WGC 的另一个优势是它内建了游标撷取、视窗边框处理、以及「避免撷取到自己的预览视窗」等机制，对开发者非常友善。Windows 11 上使用 WGC 时，被撷取的视窗右上角会出现黄色外框提示，这是系统的隐私设计。不过 WGC 依然无法突破 DRM 与安全桌面的限制，也无法捕捉独占全萤幕的内容，这是所有「合法」截图技术的共同天花板。
2-5 硬体覆叠层（MPO）与被幽灵吃掉的画面
除了上述三种主流方式，还有一个经常被忽略的机制：多平面覆叠（Multi-Plane Overlay，MPO）。为了节省电力与频宽，Windows 会让某些内容（最常见的是视讯播放，其次是部分游戏画面）不要经过 DWM 合成，而是交给显示卡的一个独立「覆叠平面」直接输出到显示器。这样做的好处是减少一次记忆体搬运，坏处是——这部分内容根本不在 DWM 的合成结果里，因此任何透过 DWM 取得的截图都抓不到它，只会得到一片黑。
这正是「为什么我截图播放器的画面是黑的，但截图其他程式都正常」的典型原因。使用者可以尝试在显卡驱动或播放器设定中关闭硬体加速来验证：一旦关闭，画面回到 DWM 合成路径，截图就正常了。这也说明了一件事——截图问题的解法往往不在截图软体本身，而在被截图对象与系统合成路径的设定。
2-6 浏览器内截图与 DRM 保护内容
还有一类截图是「发生在应用程式内部」的，例如浏览器的开发者工具截图、通讯软体的内建截图功能。这类功能通常直接向浏览器的渲染引擎索取画面，因此可以避开部分系统层级的限制，甚至能截取比视窗更大的完整网页。但同样地，当网页播放受 DRM 保护的影片时，保护机制会在渲染管线中插入一道「安全路径」，一旦检测到撷取行为，就会把画面替换成黑色。
这是 Widevine L1、PlayReady SL3000 等硬体级 DRM 的标准行为，属于内容保护而非软体缺陷。换句话说，看到「截图黑屏」时，先确认一下当时播放的是不是受保护内容，往往就能省下大量除错时间。
三、为什么「全萤幕截图」特别容易出问题？六大常见原因
前面介绍了各种技术的原理，现在把它们收敛到「全萤幕截图」这个具体情境。以下六个原因，几乎涵盖了论坛上九成以上的相关提问。
3-1 独占全萤幕模式绕过合成器
这是最经典、也最容易被误解的原因。当游戏或播放器进入独占全萤幕模式时，它会绕过 DWM 直接接管显示输出。此时 DWM 的桌面上「看不到」这个应用程式的内容，所有基于 DWM 的截图 API 自然只能拿到黑画面或桌面底图。如果用 Print Screen，得到的通常是黑画面；如果用 DXGI Desktop Duplication，可能拿到黑画面或完全冻结的旧帧。
解决方式通常很单纯：把游戏改成「无边框视窗」或「视窗全萤幕」模式。多数的竞技游戏在无边框模式下的延迟差异已经很小，而截图、录影、Alt+Tab 切换都会顺畅许多。至于非玩不可的独占全萤幕游戏，就只能依靠显示卡驱动层级的录影功能（例如 NVIDIA ShadowPlay 或 AMD ReLive），因为它们在更底层拦取画面。
3-2 硬体加速与 GPU 覆叠层
如前一节所述，硬体加速内容可能被放到独立的覆叠平面，绕过 DWM 合成。这不仅发生在影片播放器，也发生在部分浏览器、视讯会议软体、甚至某些 Electron 应用。使用者常看到的现象是：截图桌面很正常，唯独某个播放视窗永远是黑的。
验证方式很简单：把该软体的硬体加速选项关掉，再截一次图。如果画面出现了，就确认是 MPO 或覆叠层的问题。另一种解法是改用支援 Windows Graphics Capture 的截图工具，因为它对 GPU 渲染内容的支援度比传统 GDI 方案好得多。
3-3 受保护内容与 HDCP
当画面涉及 DRM 保护时，系统会在渲染管线的最末端插入黑色遮罩，并且这个遮罩是「原子性」的——任何合法的撷取 API 都只能拿到黑画面。这不是 bug，而是内容保护规范的一部分。使用者能做的只有两件事：改用官方提供的截图功能（若平台允许），或者接受这类内容本来就无法截图。
顺带一提，某些应用程式会主动呼叫 SetWindowDisplayAffinity 并设为 WDA_EXCLUDEFROMCAPTURE，让自己的视窗在截图时自动消失。这是应用层级的防截图保护，常见于密码管理器、金融软体与部分通讯软体。遇到这种情况，任何截图工具都无能为力，因为这是应用程式主动要求的。
3-4 多显示器、DPI 缩放与混合 DPI
这是「只截到一部分」最常见的元凶。Windows 上每个显示器可以有不同的缩放比例（例如主萤幕 150%、副萤幕 100%），而截图 API 使用的是「实体像素」座标，应用程式若使用「逻辑座标」去呼叫，就会产生位移与裁切。更麻烦的是 DPI 感知模式：一个没有宣告 Per-Monitor DPI Aware 的程式，在混合 DPI 环境下取得的座标系会被系统缩放，导致截图区域整体缩小或偏移。
典型症状包括：截图只涵盖左上角一块、截图内容被垂直拉伸、鼠标位置与截图不符、跨萤幕截图出现黑边。解决方式因工具而异，但共通原则是：确认截图软体支援 Per-Monitor DPI Awareness v2，并且在多显示器设定下正确枚举每个显示器的实体边界（EnumDisplayMonitors 搭配 GetMonitorInfo 取得的 rcMonitor 就是实体像素座标）。
3-5 HDR 与色彩管线
近年在 HDR 显示器普及之后，出现了新的截图灾情：画面截图后严重过曝、颜色惨白、或者整张图偏灰。原因是 HDR 桌面使用的是高动态范围的色彩空间（scRGB 或 PQ），而多数截图 API 输出的是 SDR 格式，若没有做色调映射（Tone Mapping），就会得到一张「被压扁」的图。
Windows 11 的剪取工具已经支援 HDR 截图并自动转换为 SDR，但许多第三方工具还没有跟上。如果你经常在 HDR 模式下截图，建议使用明确标示支援 HDR 的工具，或在截图前将显示器切换为 SDR 模式作为工作流程的折衷方案。
3-6 权限、UAC 安全桌面与钩子失效
最后一个是权限问题。Windows 的 UAC 提示画面运行在所谓的「安全桌面」上，这是一个与使用者桌面隔离的独立桌面，一般权限的应用程式无法撷取它。这也是为什么某些截图工具在 UAC 跳窗时会「失灵」或截到桌面底图。同样的状况也发生在锁屏画面、Ctrl+Alt+Del 安全选项画面，以及某些系统层级的全萤幕提示。
如果你需要撷取这些画面，唯一的办法是使用具备系统层级权限的工具，或者直接用手机拍下萤幕——后者虽然土法炼钢，但在实务上往往是最快的解法。
四、实作层面：一个好用的全萤幕截图工具该怎么设计
如果你不只是使用者，而是想自己写一支截图工具，那么前面这些原理就会变成具体的设计决策。以下从三个角度分享实务上的经验。
4-1 撷取顺序与备用策略
单一 API 绝对不够用。一个稳定的截图工具应该建立明确的 fallback 链，例如：优先尝试 Windows Graphics Capture（支援 GPU 内容与游标控制），失败则退回 DXGI Desktop Duplication（效能好、支援连续撷取），再失败才退回 GDI BitBlt（相容性最高、纯 CPU 路径）。每次 fallback 都应该记录原因，方便使用者除错，也方便开发者收集回报。
此外，工具应该主动侦测「黑画面」这个特例。很多 API 在失败时不会回传错误，而是安静地给你一张全黑的图。因此可以在撷取后做一次简单的像素统计，若整张图近乎全黑，就自动切换到下一个方案重试一次。这个小小的设计，可以救回大量使用者体验。
4-2 效能、延迟与记忆体
全萤幕截图在 4K 解析度下，一张未压缩的 RGBA 影像就是约 33MB。如果工具还支援连续撷取或滚动截图，记忆体管理就必须谨慎。建议使用 GPU 纹理作为中间缓冲，只在最后编码时才回读到系统记忆体，并尽量避免在每一次撷取都重新建立 D3D 装置——那会让延迟与耗电都明显上升。
另外，别小看「截图延迟」。使用者按下快捷键到画面被冻结之间，如果超过 200 毫秒，使用者就会感觉到明显的迟滞，甚至在截图瞬间改变画面内容（例如关掉选单），导致截到非预期的结果。这也是为什么现代工具多半采用「预先建立一个常驻的撷取会话」的设计。
4-3 游标、多显示器与缩放处理
游标要不要截进去，是一个看似简单却常有争议的问题。技术上，Windows Graphics Capture 提供 IsCursorCaptureEnabled 选项，DXGI 方案则可以选择是否叠加游标纹理，GDI 方案则是截图时游标本来就不会出现在画面里。好的工具应该把选择权交给使用者，并且在设定中清楚说明。
多显示器方面，务必以「实体像素」为单位计算每一台显示器的虚拟桌面边界，并且正确处理负座标（副萤幕可能位于主萤幕的左方或上方，座标会是负数）。这一点在混合 DPI 环境下尤其关键，许多截图错位的 bug 都是因为误用了被缩放过的逻辑座标。
五、实务工具比较与选型建议
回到使用者视角。市面上的截图工具非常多，但它们在「全萤幕截图」这个情境下的表现差异不小，原因正是它们采用的撷取技术不同。以下整理几款常见工具的特性，供读者参考。
工具
主要撷取技術
全螢幕表現
適合情境
Windows 剪取工具
WGC 為主
良好，支援 HDR 轉 SDR
日常快速截圖、系統內建免安裝
ShareX
可切換 WGC / DXGI / GDI
極佳，可針對失敗情境手動切換
進階使用者、需要自動化流程
PicPick
GDI 為主，部分版本支援新 API
一般，遇 GPU 內容可能黑屏
簡報、文件截圖、加註解
Greenshot
GDI
一般，遇硬體加速內容較易失敗
輕量、開源、基本需求
Snipaste
混合方案
良好，貼圖功能是其強項
設計工作者、需要畫面比對
Xbox Game Bar（Win+G）
系統層級擷取
遊戲情境佳，桌面情境較受限
全螢幕遊戲錄影與截圖
NVIDIA ShadowPlay / AMD ReLive
驅動層級擷取
可捕捉獨佔全螢幕遊戲
遊戲玩家、需要低延遲錄影
从表中可以看出一个规律：越靠近「系统合成层」的工具，对一般桌面情境的支援越好；越靠近「驱动层」的工具，越有能力突破独占全萤幕的限制，但通常只限于游戏或特定应用。至于 DRM 保护内容，则是在任何层级都无解，这一点请务必理解，不要为此浪费时间寻找「破解版截图工具」——那不仅无效，还可能带来安全风险。
六、常见问题 Quick FAQ
Q1：为什么我用 Print Screen 截游戏是黑的，但截桌面正常？
因为你的游戏进入了独占全萤幕模式，绕过了 DWM 合成器。Print Screen 抓的是合成后的桌面，当然抓不到。请把游戏改成无边框视窗模式，或改用显示卡驱动内建的录影功能。
Q2：为什么截图软体抓到的画面比实际慢半拍？
多半是因为该软体使用 GDI BitBlt 并走了软体重定向路径，或是在撷取前重新建立了装置。改用支援 WGC 或 DXGI 的工具，通常可以明显改善。
Q3：双萤幕截图只截到一半怎么办？
先检查截图软体是否支援 Per-Monitor DPI Awareness，并确认两台显示器的缩放比例是否一致。若软体不支援，可以暂时把缩放比例统一成 100% 再截图，作为临时解法。
Q4：截图后颜色怪怪的、過曝怎麼辦？
這是 HDR 色彩管線沒有正確轉換所致。請改用支援 HDR 截圖的工具，或在截圖時暫時關閉 Windows 的 HDR 模式。
Q5：有沒有辦法截到 UAC 提示或鎖定畫面？
沒有正規的方法。這些畫面執行在與使用者桌面隔離的安全桌面上，一般應用程式無法撷取。實務上請直接用手機拍攝。
結語：理解原理，才不會在錯的地方找答案
「全萤幕截图失败」这件事，表面上像是软体 bug，实际上是一个横跨绘图 API、桌面合成、显示卡覆叠、色彩管理与内容保护的综合性问题。当我们理解了画面是如何一层层被画出来、又是如何被合成与输出的，就能很快判断当下的情境属于哪一层，进而选择正确的工具或调整正确的设定。
对一般使用者而言，最实用的三个建议是：第一，日常截图优先使用支援 Windows Graphics Capture 的工具；第二，遇到游戏截图黑屏，先改无边框模式再说；第三，遇到受保护内容，认清现实，别再浪费时间找偏方。对开发者而言，则应该建立多层次的 fallback 策略、正确处理 DPI 与多显示器座标、并且把「黑画面」当成一种需要主动侦测与处理的状态，而不是例外。
截图看似是电脑操作里最微不足道的小事，但它其实是整个显示管线的一面镜子。把这一层弄清楚，你以后遇到任何「画面抓不到」的怪现象，大概都能在几分钟内找到方向，而不是无止境地换软体、重灌、然后怀疑人生。希望这篇文章能帮你在下一次截图失败时，少走一点冤枉路。
```