你打开活动监视器，因为 Mac 感觉变卡了，结果 CPU 列最顶端的进程是一个叫 WindowServer 的东西——有时占用 80%、150%，甚至 300%。杀掉它不是选项（那会让你被注销），而通常那句”重启 Mac”的建议也解释不了到底发生了什么。本文将解释 WindowServer 到底是什么、为什么它的高 CPU 几乎总是症状而不是原因，以及如何找到那个真正让它飙升的应用或工作负载。
快速结论
WindowServer 是 macOS 中负责将你在屏幕上看到的每一个像素合成出来的进程——窗口、菜单、光标、Dock、动画。它本身几乎什么都不做。当它显示高 CPU 时，那部分负载是其他东西在驱使它去绘制：行为异常的应用、大量可见窗口或图形繁重的浏览器页面、多台高分辨率外接显示器，或是某个基于 Electron 的应用中带 bug 的 GPU 加速图层。你不能也不应该杀掉 WindowServer；强制退出它会终止你的用户会话。正确的解决方式是找出上游应用并处理它。ProcXray 能让这一过程变得快速：按逐进程 GPU 列排序找出图形密集型进程，用系统仪表盘确认整体 GPU 压力，再用窗口拾取器把任何可见窗口对应回它所属的应用。
WindowServer 是什么？
WindowServer 是 macOS 中负责屏幕合成的部分——它接收每个正在运行的应用的图形输出，并将它们组合成显示器最终展示的画面。它位于 /System/Library/PrivateFrameworks/SkyLight.framework/Resources/WindowServer，在用户登录时自动启动。每个登录的用户会话对应一个 WindowServer 进程。
在底层，每个可见应用都会以一组 Core Animation 图层的形式提交渲染内容。然后 WindowServer 让 GPU 把这些图层组合起来——应用透明、模糊、阴影和动画——并按显示器刷新率（通常是 60Hz，或 ProMotion 显示器最高 120Hz）把结果推送出去。
正常情况下，WindowServer 占用 1% 到 15% 的 CPU。在一台只有内置显示器、开着几个应用的 Mac 上，它不应该是占用最高的进程。
关于百分比的说明：在活动监视器里，100% 等于一个完整 CPU 核心的算力。在多核 Mac 上，单个进程的占用可以远超 100%。所以 WindowServer 占 300% 并不是”整机的 300%“——而是它占用了相当于三个完整核心的资源。
为什么 WindowServer 占用过高通常并不在于 WindowServer
这是本文最重要的视角重塑：WindowServer 是下游。它不会自己启动工作。它消耗的每一个 CPU 周期，都来自有东西让它去绘制——某个应用、某个窗口、某段动画，或是系统本身。
所以当 WindowServer 占用 200% CPU 时，诊断的问题不是”WindowServer 出了什么问题？“而是：
当前是什么让
WindowServer干得这么辛苦？
那个上游原因才是你需要找出并解决的。杀掉 WindowServer 不仅会让你被注销——就算你能立刻把它替换回来，同样的上游负载会立马卷土重来。
这与 kernel_task 占用 CPU 过高的诊断模式是一样的：活动监视器顶端那个可见的进程，是症状，不是病因。
是什么触发了 WindowServer 飙升
常见的上游原因有六类，大致按出现频率排序：
1. 一个硬件加速的应用行为异常
基于 Chromium 的浏览器（Chrome、Edge、Arc、Brave）、Electron 应用（Slack、Discord、VS Code、Notion、Figma）、视频编辑器和游戏，都会把硬件加速的图层推给 WindowServer。其中任意一个出现 bug 或卡死的图层，都可能在应用看起来已经空闲后仍把 WindowServer 钉住。典型例子包括 Chrome 和 Slack。
2. 多台或高分辨率的外接显示器
每多一台外接显示器，就增加一份合成工作。一台 4K 或 5K 外接显示器——尤其是被缩放到非原生分辨率时——会成倍地增加每帧的负载。两台 4K 外接显示器可以把 WindowServer 推得相当高，在较老的 Intel Mac、功耗较低的 Apple Silicon 配置上，以及在需要额外渲染通道的缩放（非原生）模式下尤为明显。
3. 大量可见窗口或图形繁重的网页内容
每一个可见窗口——包括每一个打开的浏览器窗口——对 WindowServer 来说都是一组独立的、需要合成的 Core Animation 图层。现代浏览器中的后台标签页通常会被挂起，不会直接增加 WindowServer 的负载，但视频密集型页面、WebGL 或 canvas 内容、以及带动画的网页（自动播放的广告、复杂的 CSS 动画）会。几十个可见窗口，或几个吃资源的标签页，都会让 WindowServer 每一帧要跟踪和合成的东西显著变多。
4. 卡死的动画或泄漏的 CALayer
当某个应用没能正确释放它的图形资源时，WindowServer 会一直持有并重新评估这些资源。这通常表现为：经过数小时的开机时间后，CPU 缓慢爬升，而在你退出那个出问题的应用的瞬间又骤然下降。
5. 透明度、动效与壁纸效果
macOS 的动态壁纸以及系统的透明和动效效果，全都通过 WindowServer 运行。在较老的 Intel Mac，或在集成显卡已经负载较重的 Apple Silicon Mac 上，这些可能变得格外昂贵。
6. macOS 或 GPU 驱动 bug
历年来，多个 macOS 小版本中都出现过有记录的 WindowServer 内存和 CPU 泄漏。如果你刚更新过系统、飙升就立刻开始，请查阅 Apple 针对该特定版本的发行说明和 Apple 讨论区。
如何找到真正的元凶
活动监视器是顺理成章的起点，并且在最近几个 macOS 版本中有所改进，但它在这个具体问题上仍有缺口。它能显示整体 GPU 活动（窗口 → GPU 历史记录）以及使用 GPU 的进程的 %GPU 列，但它没有给你一个与 WindowServer 时间线对齐的、逐进程、连续的 GPU 趋势，也没法把屏幕上的某个窗口关联到拥有它的进程。而这两样东西正是你真正需要的。
第一步：在活动监视器里收割低垂的果实
打开活动监视器 → CPU 标签页，按 CPU 排序。记下 WindowServer 的百分比。打开窗口 → GPU 历史记录，确认整体 GPU 负载是否偏高。如果你能在进程上看到 %GPU 列，按它排序，找出此刻 GPU 占用最重的那个。
这能告诉你症状是真实的，并把矛头指向图形密集型的应用，但你仍然需要在时间线上把它与 WindowServer 对应起来，并确认到底是哪个应用的窗口在负责这些负载。
第二步：用 ProcXray 锁定上游应用
ProcXray 正是为这类跨资源诊断而设计的：
- 每个表格视图中的逐进程 GPU 列（以及它所驱动的逐进程 GPU 使用率追踪）让你能按持续 GPU 用量排序进程并观察趋势，而不仅仅是当前快照——这样你就能确认到底是 Chrome、Slack 还是某个视频类应用，在持续制造
WindowServer所要合成的那份负载。 - 系统仪表盘对此形成补充，展示整机层面的整体 GPU 压力，让你把逐进程的视图与系统级视图相互印证。
- 窗口拾取器让你能用十字光标对准屏幕上任意一个窗口，瞬间识别出拥有它的进程。如果你能看到一个卡住或在视觉上冻结的窗口，这一功能能在两秒内找到它的归属。（关于这一流程的更多细节，参见如何在 macOS 上查找某个窗口属于哪个进程。）
- 资源历史视图让你能向后回溯到
WindowServer开始攀升的那一刻，看看在同一时间还有哪些进程在飙升。这正是你抓出经过数小时积累的慢速泄漏的方法。
关于活动监视器在这类调试上更广泛的不足之处，参见 ProcXray vs 活动监视器。
第三步：通过逐个退出嫌疑对象做 A/B 测试
锁定一两个嫌疑对象后，逐个退出它们，观察 WindowServer 的 CPU 是否下降。这能在不重启、不打断整个会话的情况下确认原因。
分步解决方案
请按从代价最低、干扰最小的顺序逐项尝试。
1. 退出可疑的应用
一旦你识别出上游进程，退出它。需要的话再重新打开。这能立即解决大多数 WindowServer 飙升的情况。
2. 断开外接显示器作为诊断手段
如果你无法锁定某个具体应用，断开一台外接显示器，观察 CPU。如果 WindowServer 大幅下降，说明显示器是主要成本。你可以选择降低分辨率、让外接显示器运行在原生分辨率（不缩放），或在不需要时直接断开它。
3. 减少透明度和动效
这两项设置会把合成工作从 WindowServer 转移到更简单的绘制路径。免费、可逆，在集成显卡的 Mac 上常能感觉到明显改善：
- 减少透明度：系统设置 → 辅助功能 → 显示 → 减少透明度
- 减少动态效果：系统设置 → 辅助功能 → 动态效果 → 减少动态效果
4. 在重度 GPU 应用中关闭硬件加速
Chrome 中：设置 → 系统 → 关闭”可用时使用图形加速”，然后重启 Chrome。大多数 Electron 应用在各自的设置中都有类似选项。这会把渲染从 GPU 转移到 CPU——可能修复 WindowServer 飙升，代价是该应用本身的 CPU 略微升高。
5. 关闭多余窗口和图形繁重的页面
大多数后台标签页已经被挂起，不会直接给 WindowServer 添加负载。重点应放在关闭你不需要的可见窗口、暂停自动播放视频或带动画的页面、关掉仍在后台窗口中运行的 WebGL 或 canvas 演示。如果你经常开着很多浏览器窗口，把标签页合并到更少的窗口里也有帮助。
6. 注销后重新登录
注销会干净地终止 WindowServer，并以全新状态重新启动它——无需完全重启。这通常能解决退出单个应用未能解决的卡死图层问题。
7. 更新 macOS 和可疑的应用
如果问题是在最近的 macOS 或应用更新之后开始的，留意是否有后续补丁。Apple 已多次通过小版本更新修复 WindowServer 泄漏问题。
8. 最后手段：重启，并且只在老款 Intel Mac 上重置 SMC
完全重启会重置 WindowServer 和 GPU 驱动状态。如果同样的工作负载在重启后仍然触发飙升，说明原因在上游——而非临时状态——你应当专注于找出负责的应用，而不是继续做更彻底的系统重置。仅在老款 Intel Mac 上，如果显示器或电源管理相关的症状与 WindowServer 负载同时存在，重置 SMC 偶尔会有帮助；Apple Silicon Mac 没有用户可访问的 SMC 重置方式，而且无论如何，这都很少是 WindowServer 问题的正确解决方案。
如果排查中没有出现任何具体嫌疑对象、需要更通用的性能排障，请参见如何通过终止合适的进程来修复 Mac 运行缓慢。
常见问题（FAQ）
我可以杀掉或禁用 WindowServer 吗？
不行。WindowServer 负责运行你的整个图形用户会话。强制退出它会立即把你注销，丢掉任何未保存的工作。当你重新登录时，macOS 会自动重启它。没有任何受支持的方法可以禁用它。
WindowServer 占用 CPU 过高会损坏我的 Mac 吗？
不会直接损坏。持续的高 CPU 确实会增加发热并缩短电池续航，但 WindowServer 本身在干这份活并不构成硬件风险。更值得关注的是是什么让它干得这么辛苦——一个失控的应用在耗电池才是真正的代价。
为什么 WindowServer 占用了那么多内存？
WindowServer 会缓存每个可见应用渲染出来的图层，以加快合成。内存占用会随窗口数量、显示器分辨率和会话已运行时长而扩大。长时间开机后占用几个 GB 并不罕见。如果内存无止境增长，请怀疑图层泄漏的情况（上文原因 #4），并注销再重新登录。
为什么只在我连接外接显示器时它才飙升？
接入一台外接显示器，会按其分辨率成比例增加每帧的合成工作。一台 4K 外接显示器大约会让 WindowServer 每帧需要合成的像素翻一到两倍。如果飙升明显，请尝试让外接显示器运行在原生分辨率——缩放模式开销显著更高，因为它们需要一次额外的渲染通道。
重启能彻底解决 WindowServer 占用过高吗？
仅当底层原因是临时泄漏时才行。重启会把 WindowServer 重置为干净状态，但如果你重新打开同一个应用、或重新连接同一台显示器，飙升就会回来。真正的解决方案是找出上游原因；重启是一张白纸，不是治疗手段。
参考资料
- Apple 支持 — 如何使用活动监视器
- Apple 支持 — 在活动监视器中查看 GPU 活动
- Apple 支持 — 更改 Mac 上的”显示”辅助功能设置
- Apple 支持 — 自定 macOS 中的屏幕动态效果
- Apple 开发者文档 — Core Animation 编程指南（已归档；关于 Core Animation 图层和 macOS 合成器的背景介绍）
- ProcXray vs 活动监视器
- 如何在 macOS 上监控进程：开发者完整指南
免费下载 ProcXray → — 找出真正驱动 WindowServer 负载的那个应用。支持 macOS Sonoma+，Apple Silicon 与 Intel。