核心要点
- Electron 在桌面外壳内渲染 Web 内容，这意味着您的应用程序继承了所有 Web 视觉缺陷——再加上桌面特有的问题
- 可变窗口尺寸、原生菜单、多显示器支持以及跨操作系统的渲染差异，构成了常规 Web 中不存在的视觉缺陷类别
- 把 Electron 应用当作普通网站来测试是错误的：桌面环境从根本上改变了视觉体验
- 自动化视觉测试是覆盖 OS × 分辨率 × DPI × 窗口大小这一组合空间的唯一可行方法
Electron 在其官方文档中被定义为 "一个使用 Web 技术（HTML、CSS、JavaScript）构建原生桌面应用的框架，它将用于渲染的 Chromium 与用于系统级访问的 Node.js 结合在一个跨平台运行时中"（Electron 官方文档，electronjs.org）。
在这个优雅的定义背后，是每位 Electron 开发者都熟知的现实：您获得了 Web 最好的部分（生态、生产力、丰富的 UI 组件），也获得了 Web 最糟的部分（CSS 不一致、渲染问题、性能不稳定）。所有这些之上，还叠加了来自桌面环境的额外复杂性。
如果您正在开发 Electron 应用——而且您很可能在使用多个 Electron 应用（VS Code、Slack、Discord、Figma、Notion、Obsidian）——本文将向您说明为什么您的桌面应用视觉测试值得特别关注，以及为什么"像测 Web 一样测试"虽然不够，却仍是正确的起点。
Electron 继承了 Web 所有的视觉问题
CSS 仍然是 CSS
您的 Electron 应用使用与 Chrome 相同的渲染引擎（Chromium，通过捆绑特定 Chromium 版本的 Electron 项目）。这意味着每一个 Web 视觉问题都适用：依赖更新后的 CSS 回归、文本溢出、z-index 问题、尺寸不当的图片、卡顿的动画、加载失败的字体。
如果您已经做过 Web 的视觉测试，您熟悉这些问题。它们在 Electron 中同样存在。
但这里有一个陷阱：许多构建 Electron 应用的团队并非来自 Web。他们来自原生桌面开发（C++、C#、Java Swing），那里不存在 CSS 渲染问题。他们第一次遇到这些问题，却没有相应的经验或工具来应对。
Chromium 更新：沉默的风险
每次 Electron 重大更新都会捆绑新的 Chromium 版本。每一个新的 Chromium 版本都可能微妙地改变渲染。亚像素抗锯齿的修改、舍入计算的变更、字体处理的演进——这些变化很少被记录为破坏性变更，但它们可能引发可测量的视觉回归。
Electron 团队大约每八周发布一个新的主要版本。根据 Electron 官方博客，每个主要版本都集成了一个 Chromium 版本、一个 Node.js 版本和一个 V8 版本。这是大量的潜在变更面。
如果您没有在每次 Electron 更新前后运行视觉测试，您就在默默接受整个界面发生回归的风险。
改变一切的桌面特定问题
可调整大小的窗口：响应式的升级版
在 Web 上，"响应式设计"意味着将布局适配到几个预定义断点（移动端、平板、桌面）。可能的视口数量众多，但受现有屏幕尺寸的限制。
在桌面上，您的 Electron 应用窗口实际上可以是任意尺寸，从 400×300 像素到 3840×2160，覆盖每一个中间尺寸。用户可以自由调整大小，而且他们确实会这么做。
这创造的是一个连续的可能布局光谱，而不是一组离散的断点。您的应用必须在任何尺寸下都视觉正确——而中间尺寸（您断点之间的尺寸）往往是问题出现的地方。
典型的调整大小缺陷场景包括：
侧边栏在窗口太窄无法显示两者却又太宽不足以触发"折叠"模式时，与主内容重叠。
在某些宽度下，表格溢出其容器并产生意外的水平滚动。
页眉中的操作按钮在水平空间不足但尚未达到移动端断点时发生重叠。
浮动面板（检查器、终端、命令面板）在窗口过小时跑出屏幕。
原生菜单：您无法控制的界面
Electron 应用可以使用操作系统的原生菜单（macOS 上的菜单栏、Windows 和 Linux 上的窗口菜单）。这些菜单由操作系统渲染，而非您的 CSS 代码。它们的外观因操作系统、操作系统版本和用户的系统主题而异。
从视觉上看，原生菜单与您的 Web 内容之间的过渡区域是常见的问题来源。在 macOS 上，标题栏和菜单由系统管理。在 Windows 上，许多 Electron 应用使用自定义标题栏（无边框窗口配合 CSS 重新创建的控制按钮）以获得更现代的外观。
这个自定义标题栏是一个视觉关键组件。关闭、最小化和最大化按钮必须在正确的位置、正确的尺寸、正确的颜色，并在悬停时正确响应。所有这些在不同平台上都不同：在 macOS 上，按钮在左侧且为圆形；在 Windows 上，按钮在右侧且为方形；在 Linux 上，则取决于窗口管理器。
如果您的应用使用自定义标题栏，视觉测试必须在每个目标操作系统上覆盖它。这是用户持续看到和使用的组件，这里的视觉缺陷会立即被察觉。
多显示器和可变 DPI
现代桌面环境通常意味着一台带 Retina 显示屏（2x DPI）的笔记本电脑连接到外接 1080p 显示器（1x DPI）。用户在不同屏幕之间移动您的应用。当应用从 2x 屏幕移动到 1x 屏幕时，所有内容都必须正确地重新渲染。
与 DPI 相关的视觉问题特别隐蔽：
为单一 DPI 设计的位图（PNG、JPG）在高分辨率屏幕上显得模糊，或在低分辨率屏幕上显得像素化。图标和插图必须以多种分辨率提供，或采用矢量格式（SVG）。
1 像素的边框在 1x 和 2x 下显示效果不同。在 2x 屏幕上，1 像素的 CSS 边框相当于 0.5 物理像素，根据渲染引擎的不同，它可能不可见或不一致。
阴影、渐变和模糊效果在不同分辨率间的渲染会发生微妙变化。在 1x 屏幕上是轻微模糊的内容，在 2x 屏幕上可能变成明显模糊，反之亦然。
文本经历不同的抗锯齿处理。细字体的可读性在 2x 上可能极佳，而在 1x 上则较差。在您的开发屏幕（很可能是 Retina MacBook）上效果良好的字体选择，在用户的外接显示器上可能是灾难性的。
任务栏、Dock 和系统托盘
您的应用通过任务栏图标（Windows/Linux）、Dock（macOS）和系统托盘与桌面环境交互。这些微小的图标（16×16 到 48×48 像素）必须完美无瑕。通知徽章、状态叠加、上下文菜单——这些是您用户持续看到的视觉元素，即使您的应用不在前台。
三个操作系统：三种渲染、三套问题
macOS：苛刻的参考
macOS 通常是主要的开发平台。视觉特性包括左侧的红绿黄交通灯按钮、Core Text 字体渲染（在相同字重下视觉上比 Windows "更粗"），以及必须与您应用主题协调的原生暗色模式处理。
Windows：配置多样性
Windows 提供了最大的配置多样性。分辨率从 1366×768（根据 StatCounter，2025 年仍占屏幕的 20%）到 3840×2160。缩放因子（100% 到 200%）增加了 macOS 上不存在的复杂性。
DirectWrite 字体渲染产生的结果与 Core Text 明显不同：字体更细、更锐利，有时在小尺寸下可读性较差。"高对比度"无障碍模式如果您的 CSS 样式不支持，可能会大幅改变您应用的外观。
Linux：特殊情况
桌面环境的碎片化（GNOME、KDE、XFCE）使标准化变得困难。但根据 Stack Overflow 2024 年开发者调查，约 27% 的开发者使用 Linux。如果您的应用面向开发者，Linux 值得覆盖。最低限度可行：带 GNOME 的 Ubuntu。
Electron 的视觉测试策略
定义您的测试矩阵
第一步是明确定义您将测试的组合。您的矩阵至少应包括：
目标操作系统。macOS（最新版本和上一版本）、Windows 10、Windows 11。如果受众适合，加上 Linux Ubuntu LTS。
优先屏幕分辨率。对于每个 OS，列出您用户使用最多的两到三种分辨率。在 macOS 上：1440×900 和 2560×1600（Retina）。在 Windows 上：1920×1080 和 1366×768。根据您的实际分析数据进行调整。
DPI 因子。至少 1x 和 2x。在 Windows 上，加上 1.5x（150%），这是非常常见的设置。
窗口尺寸。全屏、半屏（分屏）和一个最小可用尺寸。这三种尺寸覆盖了真实使用场景。
跨多个操作系统自动化捕获
Electron 视觉测试的主要技术挑战是跨多个 OS 捕获截图。您有几种选择。
多平台 CI 方法。GitHub Actions、GitLab CI 和 Azure Pipelines 都支持在 macOS、Windows 和 Linux 上运行 job。为每个 OS 配置一个视觉测试 job，启动您的应用，导航到要测试的屏幕，然后捕获截图。
Playwright 方法。Playwright 自 1.20 版本起原生支持 Electron 自动化：启动应用、交互、截图捕获，全部跨平台。
Delta-QA 方法。对于不想维护脚本的团队，Delta-QA 提供无代码方式来捕获并视觉对比您应用的屏幕。
需重点监控的优先区域
在 Electron 应用中，某些区域比其他区域更容易出现视觉回归。请将您的视觉测试聚焦在这些区域：
标题栏和窗口控件。如果您使用自定义标题栏（无边框窗口），请在每个 OS 上测试它。关闭/最小化/最大化按钮、拖动区域、应用标题——所有这些都必须像素完美并符合平台惯例。
可调整大小的面板。如果您的应用有用户可调整大小的面板（侧边栏、底部面板、检查器），请在不同面板尺寸下测试渲染。调整手柄、最小和最大尺寸、自适应内容——所有这些都必须视觉正确。
上下文菜单。原生上下文菜单在每个 OS 上的渲染不同。自定义上下文菜单（CSS 实现）必须测试其定位（不溢出窗口）、可读性以及与应用主题的一致性。
模态框和对话框。系统对话框（打开文件、保存、打印）是原生的，无需您方进行视觉测试。但您应用的自定义模态框必须经过测试，特别是它们的居中、遮罩层以及窗口较小时的行为。
加载状态和过渡。启动 Electron 应用可能需要几秒钟。用户在此期间看到的内容（启动画面、加载界面、空窗口）是体验的一部分，值得做视觉测试。
最常见的错误
仅在一个操作系统上测试
这是最常见也代价最高的错误。如果您的团队在 macOS 上开发并在 macOS 上测试，Windows 和 Linux 特有的视觉缺陷会未经过滤地进入生产环境。而 Windows 通常占据您 Electron 用户群的大部分（根据 Electron Fiddle 和许多流行 Electron 应用的数据，Windows 通常占 60% 到 70% 的安装量）。
忽略 DPI 因子
如果您只测试 1x，而相当大比例的用户使用 2x（反之亦然），那是导致意外的根源。DPI 问题很微妙——稍微模糊的文本、消失的边框、像素化的图标——但它们给人一种缺乏精致感的印象，会侵蚀信任。
把 Electron 当作 Web 浏览器
您的 Electron 应用不是一个浏览器标签页。它是用户已安装的桌面应用，在任务栏中有自己的位置，并以原生应用的标准被评价。用户能容忍布局略微破损的网站。他们不能容忍已安装的桌面应用出现明显的视觉问题。
忽视中间窗口尺寸
如果您只在全屏下测试，您会错过用户在半屏（与另一个应用分屏）运行您应用时出现的所有缺陷。这是桌面上极常见的使用方式，尤其对于生产力工具。
常见问题
Electron 使用 Chromium，所以普通的 Web 测试就够了，对吗？
不对。Electron 使用 Chromium 渲染，这是事实。但环境从根本上不同：可无限调整大小的窗口、没有地址栏、原生 OS 菜单、任务栏集成、多显示器支持、可变 DPI。您的常规 Web 测试覆盖了浏览器中的 Chromium 渲染。它们不覆盖 Electron 桌面环境的特性。两个层级都有必要。
如何处理 macOS 与 Windows 之间的字体渲染差异？
字体渲染在 Core Text（macOS）和 DirectWrite（Windows）之间存在结构性差异。处理这些差异的唯一可靠方式是为每个 OS 维护独立的视觉基准。不要将 macOS 截图与 Windows 截图比较——它们总是不同的，而这些差异是正常的。请将 macOS 与 macOS 比较，Windows 与 Windows 比较。
应该在每次 Electron 版本更新时都进行测试吗？
是的，且不可妥协。每次 Electron 主要更新都捆绑新的 Chromium 版本，可能改变渲染。最佳实践是在更新前后运行完整的视觉测试套件，比较结果，并验证差异。某些差异是渲染引擎的改进（您可以通过更新基准来接受），其他差异是回归（您必须修复或上报）。
如何测试 Windows 高对比度模式？
Windows 高对比度模式是一项无障碍设置，它将您应用的颜色替换为高对比度配色方案。您可以在 CI 测试环境中以编程方式启用它（通过系统设置或自动化工具）。在此模式下捕获截图并维护专用基准。如果您的应用面向无障碍政策严格的专业环境，这一点尤为重要。
我的 Electron 应用只针对 macOS。多 OS 测试还有必要吗？
如果您的应用确实只支持单一 OS，多 OS 测试显然就没有必要。但请验证这一假设：许多"仅 macOS"的应用发现，他们的部分用户通过非官方安装或企业请求在 Windows 上运行该应用。如果您正在考虑未来支持 Windows，现在投资多 OS 测试将极大地简化过渡。
Electron 应用的理想视觉测试频率是多少？
每次涉及界面的提交，以及每次 Electron 版本或 UI 依赖更新时。在实践中，将视觉测试集成到您的 CI/CD 流水线中，使其在每个 pull request 上自动运行。偶尔出现一次假阳性的成本，远远低于一个视觉回归交付到数千名桌面用户手中的成本。
延伸阅读
- WCAG 无障碍与视觉测试：检测回归的完整指南
- AI与视觉测试：承诺、现实，以及为什么确定性方法仍然更可靠
- 2026年 Applitools 的5个最佳替代方案
- Applitools 的 5 个免费替代方案：视觉回归测试工具推荐
Electron 让您能够使用 Web 技术创建桌面应用。这是一种超能力。但这种超能力伴随着责任：Web 视觉缺陷会跟随您到桌面，而且它们还会与原生环境特有的一系列问题一起出现。
好消息是，如果您已经知道如何对 Web 进行视觉测试，您已经掌握了所需 80% 的技能。剩下的 20%——多 OS 矩阵、DPI 因子、可调整大小的窗口、原生菜单——是您现有方法的自然延伸。
Electron 继承了 Web 的所有问题。像测 Web 一样测试它，然后再走得更远。