App 一开始没做深色模式，用户晚上看发白刺眼，现在补适配还来得及吗？

App 深色模式要不要做、什么时候补，取决于用户的使用时段、系统深色占比与设计成本，而不是「别人有我也要有」。按 2026 年移动端项目交付习惯，跟随系统做一套基础深色适配，常见只占前端界面工时的 5%~15%；但如果第一版就把颜色写死在各个页面里，后期再补，改稿加回归测试的成本常会上升到前端总工时的两三成。内容阅读、夜间使用明显的 App 值得早做，纯内部工具类可以先不做，但要留好可替换的色值结构，避免系统深色下出现黑底黑字或白底白光。

一、先分清：深色模式有三种形态，成本差很多

很多人说的「深色模式」其实是三件不同的事，混在一起讨论就会把预算估错。第一种是跟随系统开关，系统切深色时 App 跟着变；第二种是 App 内自带「浅色/深色/跟随系统」手动选项，多一层设置与记忆逻辑；第三种是只在阅读页、夜间看板等局部页面做深色。前两种是全局体验，第三种是场景补丁。

按 2026 年常见做法，跟随系统是投入产出比相对高的一档，因为系统已经提供了开关和状态回调，App 只需要响应。而手动开关带来的额外价值，主要在用户不信任系统设置或系统版本较老时，是否值得取决于你的用户构成。

• 跟随系统：覆盖主要页面即可，常见不需要额外的设置入口。
• App 内手动：要多做设置项、状态存储和跨页同步，工时通常比前者多两三成。
• 局部深色：适合只有阅读、视频等少数场景，但容易出现「一半深一半浅」的割裂感。

二、判断要不要做，用「时段—系统—成本」三看法

不必凭感觉决定。给企业项目做交付判断时，常用一个三步核对法：先看用户什么时候用，再看系统层面深色开启比例，最后看设计资源和预算能不能接住。三步中只要前两步都指向「夜间使用明显」，就值得排期；如果前两步都不成立，第三步的成本再低也是浪费。

1. 看使用时段：通过后台活跃时段或埋点，确认晚间（如 20 点后）是否构成明显使用高峰；白天为主的作业类 App 优先级低。
2. 看系统环境：参考平台官方文档与自有统计数据，判断目标用户中开启系统深色的比例；这个比例在不同人群里差异较大。
3. 看成本承接能力：设计能否再出一套深色稿、图片素材是否有源文件、色值是否已收敛为主题变量，这三点决定补做是「改一处」还是「翻全站」。

还有一个容易被忽略的点：品牌色不能直接平移到深色背景上。浅色下深而饱和的主色，放到深底上常因对比度不足发灰，需要单独调一版更亮的同色系，并按对比度规范核对文字可读性。

三、四种落地路径的可核对对比

把可选路径摊开对比，比只问「要不要做」更容易做决定。下面按项目交付中常见的经验区间给出差异，具体仍要看项目本身的设计资源和技术栈；写进需求文档后，验收才有依据可对。

• A 跟随系统自动适配：常见前端工时增加 5%~15%，设计需补一套深色色板；适合多数 To C 内容类 App。
• B 跟随系统 + App 内手动开关：在前者基础上再增加设置与状态同步工作，整体常见增加 10%~20%；适合用户年龄跨度大、系统版本分散的产品。
• C 只做局部页面深色：增量常在前端 2%~5%，见效快，但要接受体验不一致。
• D 不做深色，只保证可读：几乎不增加工时，前提是颜色不能硬编码，要避免系统深色下出现黑底黑字或白底白光。

选择逻辑可以简化成：用户夜间占比高就选 A 或 B，只要求不出错就选 D，先验证需求可以先选 C。把这四种路径写进需求文档，验收时才有依据可对，也能避免后期被一句「别人都有」追加范围。

四、交付现场：为什么「做过深色」还是发白刺眼

在项目里常见的情况是：团队按系统开关做了深色，用户仍反馈刺眼或看不清。约束条件往往是预算有限、设计只出了浅色稿、素材还是浅色底 PNG；做法是把颜色统一收进主题变量、图标换成可染色的矢量图、插画补一份深色版；代价是首版多花几天设计时间，但换来的是后续换主题时不必逐页重画。反之如果前期图省事把色值写在页面里，第二次调整就要全量回归。这类首版深色适配的时间投入，按常见区间看约多出设计 2~5 人日、前端 3~10 人日，老项目返工则常翻倍。

深色适配做得好不好，验收时不要只看首页，要逐项过状态页和边界页面。合格线是：主要页面在系统深色下文字对比清晰、状态栏与导航栏不跳色、弹窗和空状态不出现白块。

• 色值是否集中管理，改一处能否全局生效。
• 图片、插画、启动图是否有深色版本，浅色底图在深底上会发白。
• 状态栏、导航栏、键盘、下拉刷新等系统组件是否同步切换。
• 内嵌 H5 与第三方页面（支付、客服、地图）多为浅色，是否提前接受这种不一致。
• 弹窗、空状态、加载态、错误页是否也覆盖到，避免漏测后反复返工。

五、适用场景与不适用边界

深色模式适合夜间使用明显、连续阅读时间较长、屏幕停留时间高的产品，比如内容资讯、社区、影音和部分工具类。它也能顺带降低 OLED 屏幕在暗环境下的亮度刺激，这是用户主动要求深色的常见原因。

反过来，纯内部员工使用、白天作业为主、生命周期只有几个月或上线后很快重做的 App，通常不必专门排一轮深色适配。如果项目预算和工期已经很紧，先把浅色体验和系统深色下的可读性做扎实，比勉强做一套半成品更划算。这类边界建议在需求评审时就写清楚，避免后期被拿来追加范围。

常见问题

深色模式不做会影响应用商店上架吗？

应用商店审核一般不把深色模式列为硬性条件；但系统深色下若出现黑底黑字、白底白光等严重可读性问题，容易被用户差评或在整改中被点名，建议至少让文字可读。

只做跟随系统，用户想手动切换行不行？

可以，但要多加一层设置与状态记忆。常见做法是以系统设置为默认，App 内补「浅色/深色/跟随系统」三选项，额外工时通常有限，主要落在设置页与跨页同步逻辑上。

深色模式适配一般要花多久？

已有主题变量、色值集中的项目，覆盖主要页面常见需要前端 3~10 人日；色值散落在各页面的老项目返工量常翻倍，还要叠加设计出稿与回归测试时间。

用第三方 UI 组件库是不是能省一大半事？

能省一部分。主流组件库多自带深色主题令牌，但自定义组件、业务卡片、图片素材仍要逐个核对，不能假设套上主题就全部正常。

深色模式下的品牌色要不要照搬浅色版？

不必照搬。浅色下饱和的主色放到深底上常因对比度不足发灰，常见做法是单独调一版更亮或更淡的同色系，并按对比度规范核对可读性。

如果 2026 年正准备启动或改造 App，建议在原型阶段就把颜色收敛成主题变量，并把深色适配写进验收清单，犀跃公司在移动端交付中通常也按这个口径执行。判断依据仍是三看法：夜间使用明显、系统深色占比不低就排期；用户集中在白天、产品生命周期又短，先保证系统深色下文字可读即可。