产品要不要做深色模式？先算场景价值，再算两套设计成本

深色模式看起来像一项视觉功能，实际是一套颜色、层级、资产、状态和测试体系。做得不好时，正文发灰、状态色刺眼、图表无法区分、白底图片像开着手电。真正的问题不是“用户喜不喜欢黑色”，而是产品是否存在足够明确的使用场景，值得长期维护两种外观。

深色模式看起来像一项视觉功能，实际是一套颜色、层级、资产、状态和测试体系。做得不好时，正文发灰、状态色刺眼、图表无法区分、白底图片像开着手电。真正的问题不是“用户喜不喜欢黑色”，而是产品是否存在足够明确的使用场景，值得长期维护两种外观。

01 哪些产品更值得优先支持深色模式

长时间使用、低光环境、媒体观看、开发工具、监控大屏和夜间操作，通常更有明确价值。偶尔使用的企业表单、内容很少的营销页或主要在明亮办公环境使用的工具，收益可能有限。

还要看平台预期。移动端和桌面端用户已经习惯系统级外观选择，如果产品长期忽略系统偏好，体验会显得割裂。企业内部系统则可以先调查真实使用环境，不必因为竞品有就立即跟进。

02 不要反转颜色，要建立语义色映射

浅色主题中的白色背景、黑色文字和品牌蓝不能简单反相。深色模式需要重新定义背景层级、文本层级、边框、填充、悬停、选中、禁用和状态色。

更稳妥的方式是使用语义Token，例如background/base、background/elevated、text/primary、border/subtle、status/danger，而不是在组件里写死颜色。浅色和深色主题分别映射到这些语义，组件逻辑保持一致。

03 组件状态是工作量最大的部分

按钮、输入框、下拉、表格、弹窗、Tooltip、代码块和图表都至少包含默认、悬停、按下、焦点、禁用、错误和选中状态。只设计几张深色页面截图，开发时仍会出现大量未定义组合。

设计系统需要为每个组件核对两种主题与高对比设置。焦点轮廓不能在暗背景消失；禁用状态不能与可操作状态混淆；错误不能只靠红色。

04 图表、地图和图片不会自动适配

数据可视化在深色背景上最容易出问题。颜色过亮会产生视觉疲劳，过暗又无法区分；网格线、Tooltip、选区和异常状态都要单独测试。

带白色背景的Logo、截图和商品图会在深色界面中形成强烈光块。可以准备透明资产、暗色版本或柔和容器，但不能随意改变品牌和产品图片本身。

• 图表系列不要只靠颜色，增加线型、形状或标签。
• 地图底图与覆盖物同时测试，避免道路和标记消失。
• 截图内容若无法适配，使用明确边框和中性容器。
• 品牌Logo准备正色、反白和单色版本。
• 媒体内容允许用户专注，但控制条仍需保持可见。

05 可访问性需要在两种主题分别验收

常用正文的前景与背景通常至少需要4.5:1对比度，大号文字和非文本元素有不同要求。不要假设深色模式天然护眼，也不要用低对比灰字制造“高级感”。

除了正常主题，还要测试系统增强对比、降低透明度、字体放大和色觉差异。透明玻璃、模糊和渐变在不同壁纸或内容背景上可能失去可读性。

深色模式不是一张皮肤，而是另一套必须通过同等质量门槛的界面。

06 三种实现方式，成本完全不同

产品可以只跟随系统、提供用户切换，或设计成永久深色。系统跟随最符合平台预期；手动切换给用户更多控制，但需要保存偏好并处理跨设备；永久深色只适合少数沉浸式或专业场景。

07 是否现在做，可以用一个简单判断

先回答四个问题：用户是否在低光或长时环境使用；系统平台是否普遍期待；现有设计系统是否已经Token化；团队是否能承担持续测试和资产维护。

若场景价值高但系统基础差，可以先完成颜色语义化和关键流程试点，不必一次覆盖全部旧页面。若只是为了新品发布截图，建议把预算用于核心任务、性能和可访问性。

常见问题

深色模式能省电吗？

在部分使用OLED等自发光屏幕的设备上，较暗像素可能降低能耗，但实际效果取决于屏幕、亮度、颜色和使用方式。产品是否支持深色模式不应只以省电作为理由。

深色模式的背景应该用纯黑吗？

不一定。纯黑可能造成过强对比和层级难表达。很多产品使用接近黑色的中性色，并用稍亮背景表示浮层和卡片。

只做一个深色开关需要多久？

如果设计系统已有语义Token和完整组件，成本可控；若颜色写死、图片多、图表复杂或页面历史包袱大，实际工作接近一次系统性改造。

官网需要深色模式吗？

取决于品牌与使用场景。企业官网通常不是刚需，除非内容、媒体或品牌体验有明确理由。支持系统偏好也要确保SEO、性能和无障碍不受影响。