深色模式设计:如何在不破坏第一套主题的前提下上线第二套主题

大多数深色模式都不是设计出来的,而是反转出来的。设计师把背景翻成近黑色,把文字调成近白色,然后宣布完工。结果就是一套刺眼、阅读体验比浅色版更差的主题,让品牌像是换到错误灯光下的另一个产品。

这篇文章是实战版。让深色主题显得有意为之的色彩计算,在黑暗中会崩坏的组件陷阱,以及在产品成长过程中让两套主题保持同步的 token 结构。没有 Dribbble 式的渐变,只有一套在设计系统中挣得自己位置的深色主题。

深色模式到底是什么

**深色模式是完整的第二套主题,而不是颜色反转。**它有自己的表面逻辑、自己的对比度规则,以及自己的字重调整。真正的深色模式是针对同一套组件从零设计,再通过共享 token 与浅色主题对齐。

反转这条捷径失败是有具体原因的。浅色模式依靠白色表面向上反射来体现层次。深色模式无法反转这一点,因为纯黑表面吸收层次而不是创造层次。整个层级(elevation)系统必须重建。设计系统指南拆解了为什么这必须在 token 内部完成,而不是在各个组件里完成。

为什么 2026 年深色模式很重要

三个理由,没有一个跟美学有关。

**OLED 屏幕的续航。**OLED 面板上每个黑色像素的功耗为零。在高亮度设置下,手机上的深色界面可以将屏幕功耗降低 30% 到 60%。对移动端用户来说,深色主题首先是一项电池功能,其次才是视觉功能。

**对光敏感人群的无障碍。**偏头痛、散光或畏光的用户无法长时间舒适地使用浅色界面。上线深色模式是对无障碍的承诺,而不是个人偏好。网页无障碍检查清单讲解了主题化在完整审计中的位置。

**用户预期。**操作系统自带适用于整个系统的深色模式开关。无视系统设置的产品显得过时。用户会按是否支持深色模式来筛选应用商店和扩展目录。缺少深色主题不只是 UI 缺口,更是营销问题。

第一条规则:永远不要用纯黑

纯黑(#000000)是新手深色模式中最常见的错误。它看起来很对,因为它似乎是最暗的表面。但它读起来是错的,因为人眼无法对着纯黑判断深度。

解法:用带一点品牌色相的深灰作为基础表面。大多数产品在 #0B0B10 到 #121218 之间,有时高到 #1A1A1F。具体数值取决于品牌的色温。暖色品牌就偏暖一点的深色,冷色品牌就偏冷一点的深色。纯中性色读起来毫无生气。

同样的规则适用于对比度最高的文字。深色表面上的纯白(#FFFFFF)会产生光晕,也就是亮边模糊效应,让小字阅读起来很累。把文字降到大约 #E8E8EA,或使用 85% 到 92% 不透明度的白色。这个下调肉眼几乎察觉不到,却对可读性帮助巨大。

---

深色模式中的表面层级

浅色模式用阴影表示卡片在背景之上。深色模式做不到,因为阴影会被深色表面吞掉。变通办法是用明度来表达层级。

**每上升一个层级,表面就更亮,而不是更暗。**位于基础表面之上的卡片比基础表面略亮。位于卡片之上的模态框更亮。深色界面中的深度,表现为一层层朝用户方向抬升的表面渐变,而不是向下坠落的阴影。

Material Design 用五级层级刻度把这件事形式化了,这个思路在任何设计系统里都成立。适用于大多数产品的一套可用刻度:

具体数字因品牌而异,但逻辑不变。每个抬升的表面都比它下面那层更亮,每一处阴影都很克制,层级读起来是堆叠在空间中的表面,而不是画在页面上的方框。

深色主题的对比度计算

对比度词条介绍了 WCAG 的基准:普通文字 4.5 比 1,大号文字 3 比 1。深色模式不会放宽这些规则,但达标的方式不同。

在浅色模式中,白底上约 #222 的正文大约是 16 比 1。设计师习惯了远高于下限的巨大余量。深色模式要紧得多。#0E0E12 上的 #E0E0E0 正文约为 13 比 1,依然很强,但容错空间变小了。为了让观感柔和而把文字降到 #B0B0B0,可能悄悄让某个区块跌破 4.5 比 1。

纪律是:每一个深色模式的颜色决定都要过一遍对比度检查器。不是每个主题查一次,而是每个 token 配对查一次。基础表面上的文字、卡片上的文字、模态框上的文字、占位符文字、禁用文字、链接文字。每一对都是单独的检查。

一个常见陷阱是弱化文字 token。在浅色模式中,白底上的 #666 弱化文字对比度是 5.7 比 1,清晰可读。反转成 #0E0E12 上的 #999 后,比值降到约 4.2 比 1,不满足 WCAG AA。反转这条捷径悄悄破坏了无障碍合规,多数团队直到审计发现才会注意到。

深色模式中的颜色:不只是明度,还有饱和度

在白底上很出彩的品牌色,放到深色上往往显得浑浊或刺眼。原因在于深色表面会放大感知饱和度。100% 饱和的强调色在浅色表面上显得自信,同一个颜色在深色表面上却像放射性物质。

规则是为深色主题降低强调色的饱和度,通常降 10% 到 20%,并略微提亮。白底上 #3455FF 的主按钮,在深色上可能变成 #5C78FF。同一色相家族,针对新的对比环境做了调整。品牌依然是那个品牌,只是不再刺眼。

色彩方案词条介绍了这种调整所依附的基础结构。好的深色模式不会发明新颜色,而是上线一套并行的、同一品牌色针对新表面环境调校过的版本。

---

在黑暗中会崩坏的组件陷阱

大多数组件在深色模式下至少需要一处调整,少数不调整就会彻底崩坏。以下是常见的肇事者。

边框成为主要的分隔手段

在浅色模式中,一点细微的阴影或几乎看不见的边框就能分隔组件。在深色模式中,阴影消失,多数边框也随之消失。边框成为定义组件边缘的主要工具,通常需要从浅色模式下的 #EEE 之类提升到深色模式下约 #2A2A30 才能保持可见。

测试方法是在笔记本上以 80% 亮度查看 UI。如果组件边缘开始消失,说明边框 token 在深色主题中需要更亮的值。

阴影的作用反过来了

浅色模式中的阴影把表面向下、向后推。深色模式中的阴影必须暗示表面向上、向前。通常通过一个很微妙的更亮表面(层级),再加一层几乎看不见的深色阴影来实现,为元素增加分量而不显眼。

一组可用的深色模式阴影搭配:

• 外层:0 4px 12px rgba(0, 0, 0, 0.5),让元素落地
• 内侧顶部高光:inset 0 1px 0 rgba(255, 255, 255, 0.05),暗示被抬起的边缘

两者一起使用,组件读起来是凸起的,而不是被挖掉的。单独使用,两种效果都读不出来。

禁用状态消失了

浅色模式中的禁用按钮通常是白底上的去饱和灰色。同样的处理在深色模式中会让按钮完全融进表面。解法是提高禁用状态的不透明度,而不是降低。在抬升表面色之上用 40% 左右的不透明度,而不是降成发白的灰。禁用状态仍应读起来是个按钮,只是处于不可用。

图片和插画需要单独处理

白底拍摄的产品照放在深色表面上看起来是坏的。用白色描边绘制的品牌插画会彻底消失。图片需要单独的深色模式处理,可以是单独的素材、背景替换,或者精心调校的滤镜。这是深色模式中最昂贵、最难做对的部分,也是多数团队砍掉的部分。

无法提供并行图片素材的团队,务实的解法是:在深色模式下给每个图片容器加一层柔和的背景,大约 #F5F5F7,带圆角。原本在白底上拍的图片现在放在浅色容器上,其余 UI 保持深色。

输入框焦点状态需要更高对比度

在白底上好用的蓝色焦点环,放在深色表面上会失去冲击力。焦点状态词条介绍了 WCAG 要求的 focus-visible 指示。在深色模式中,焦点环通常需要比浅色模式下的同类更亮或更粗 10% 到 20%。无障碍要求没变,但视觉处理必须调整才能依然达标。

---

双主题的 token 结构

活在 CSS 覆盖里的深色模式,是注定会漂移的深色模式。每个新组件都会用不同方式处理主题,六个月内产品里就会有三种互相打架的主题化模式。

正确的结构是语义 token。设计 token词条介绍了基础概念。深色模式正是证明 token 不是可选项的那个用例。

三层 token:

**第一层:原始值(primitives)。**原始颜色值。color.neutral.900、color.brand.500。没有立场,没有语境。

**第二层:语义层。**基于角色的命名。color.surface.base、color.surface.raised、color.text.primary、color.text.muted、color.border.default。每个语义 token指向一个原始值。

**第三层:主题层。**两张完整的映射表,每个主题一张,决定每个语义 token 解析到哪个原始值。浅色主题把 color.surface.base 映射到 color.neutral.50。深色主题把 color.surface.base 映射到 color.neutral.900。

组件只使用语义 token。它们绝不直接引用原始值,也绝不写死主题。主题切换器换一张映射表,组件重绘,什么都不会坏。这是唯一能扩展到两位以上设计师团队规模的模式。

尊重系统偏好

浏览器通过 CSS 媒体查询暴露 prefers-color-scheme。产品必须尊重它。在操作系统层面开启了深色模式的用户,默认体验就是深色主题,没得商量。应用内的开关是细化,而不是替代。

正确实现的三条规则:

**首次加载时默认跟随系统偏好。**绝不要仅仅因为设计师更喜欢浅色稿,就用浅色主题覆盖用户的系统选择。

**持久保存用户在应用内的选择。**如果用户在应用内切换到深色,这个选择要在刷新后保留,并且在用户重置之前优先于系统偏好。

**提供“跟随系统”选项。**希望由系统设置驱动的用户需要一条回到这种行为的路。三态开关(浅色、深色、跟随系统)是用户预期的模式,应当默认上线。

测试深色模式

深色模式的 bug 很会躲。一个组件在设计文件里看起来没问题,在浅色主题下通过了代码评审,上线后带着只有用户夜里打开才会暴露的对比度问题。测试纪律必须严格。

**亮度测试。**在暗室里把笔记本调到 30% 亮度打开产品。任何消失的、任何糊成一片的、任何刺眼发光的,都记为 bug。这能抓出太淡的边框、太亮的文字,以及依然过饱和的强调色。

**对比度审计。**每次主题变更都触发对所有语义配对的完整对比度检查。axe、WAVE 或 Figma 内置的对比度检查器这类工具,能抓出目视评审漏掉的回归。

**截图对比。**每次发布都为每个关键页面截取浅色和深色模式的截图。视觉差异对比能在用户发现之前暴露无意的主题漂移。

**真机测试。**OLED 手机渲染深色表面的方式不同于 LCD 笔记本。在 MacBook 上看起来完美的深色模式,常常在 iPhone 上暴露出色带或生硬的过渡。要在真实手机上测试,而不只是浏览器的设备模拟器。

---

常见的深色模式失败

三种模式造成了大多数深色模式的上线质量问题。用上面的 token 结构,三种都能避免。

**半反转的 UI。**主要表面翻成了深色,但藏得深的组件(模态框、提示气泡、营销页、遗留的后台页面)仍以浅色上线。用户切到深色,一点击半个产品就跳回白色。解法是对产品中每个表面做一次审计,用清单追踪每个页面的主题覆盖情况。

**断裂的品牌时刻。**营销落地页保持浅色而产品变成深色,或者反过来。品牌识别在用户旅程中被割裂,产品像是两家公司。解法是提前约定营销网站是否上线深色模式。两种选择都成立,但两个界面必须一致。

**无障碍回归。**浅色模式符合 WCAG AA,深色模式在三处不达标,没人检查,直到合规审计。解法是语义 token 层加上 CI 中的自动化对比度检查。每个 PR 都跑一次对比度检查。失败就阻止合并。

如果你想要一支把深色模式作为一等系统决策来交付的团队,从 token 到测试,雇用 Brainy。深色模式很少是真正的难题。真正的难题是让这一对主题上线而不漂移。

FAQ

纯黑是深色模式最好的背景吗?

不是。纯黑(#000000)与白色文字形成刺眼的对比,并去掉了眼睛读取层级所需的视觉深度线索。请使用带一点品牌色调的深灰,通常在 #0B0B10 到 #121218 之间。深色界面中的深度表现为朝用户抬升的一层层表面,这就需要一个不是纯黑的起始表面。

没有阴影,深色模式如何做层级?

深色模式的层级来自明度,而不是阴影。每个抬升的表面都比它下面那层略亮,形成朝用户堆叠的表面渐变。一层微妙的深色阴影加一条非常淡的顶部高光可以强化效果,但主要线索是表面颜色本身。

深色模式应该直接反转浅色主题的颜色吗?

不应该。反转会把强调色饱和到令人不适的程度,把弱化文字拉到 WCAG 对比度阈值以下,并破坏依赖阴影的层级模型。深色模式是针对同一套组件从零设计的第二套主题,再通过共享的语义 token 对齐。

深色模式下如何处理图片和照片?

在白底上拍摄的图片会破坏主题的连贯性。可选方案:为深色模式提供并行素材,在深色模式下为每张图片加一层柔和的浅色容器,或者谨慎地应用滤镜。插画通常需要单独的深色模式版本。这是深色模式中最昂贵、也最常被跳过的部分。

如何为双主题支持构建 token 结构?

三层。原始值(原始颜色值)、语义 token(如 color.surface.base 这样基于角色的命名),以及主题映射表(每个主题一张,把每个语义 token 解析到某个原始值)。组件只使用语义 token,所以主题切换器换一张映射表,什么都不会坏。正是这种模式让深色模式能扩展到小团队之外。

深色模式能改善无障碍吗?

对光敏感、偏头痛或畏光的用户,能。对需要高对比度文字或有特定色觉的用户,不一定。深色模式是一个无障碍选项,而不是自动的无障碍加分项。正确实现的深色主题与浅色主题一样严格满足 WCAG 对比度规则,实现糟糕的则不满足。

深色模式是系统决策,不是一个开关

一个主题完好、第二个主题损坏的产品,比只有一个干净主题的产品更糟。深色模式要么作为完整设计、完整测试、完整 token 化的浅色主题的并行版本上线,要么就不要上线。

先搭 token 层。再做对比度计算。针对每一个层级、每一个组件、每一个图片容器来设计深色主题。在真实设备上用低亮度测试。两套主题一起上线,否则都别上线。

如果你想要把深色模式当作系统级承诺而不是偏好开关的品牌、网站和 UI 工作,雇用 Brainy。两套主题,一个产品,一个连贯的设计决策。

相关阅读

• 设计系统指南
• 无障碍色彩对比度
• 网页无障碍检查清单
• 设计师的色彩理论
• 视觉层级设计