深色模式 UI 怎么做？变量系统实现日夜主题切换的实操与避坑

这两年深色模式已经成了各大 App 的基操，你想找个不支持的应用都难。现在iOS、Android 系统级别都支持日夜主题切换，产品如果只有浅色模式，体验上就先输了一截。

但很多设计师做

的方式，还在用“笨”办法，复制一套页面，对着色板一个页面一个页面去改色值……页面超过二三十个之后，你会明显感觉到绝望。

“深浅模式 UI 到底怎么做？”“日夜主题 UI 怎么做效率最高？”其实答案早就不神秘了，就是用好咱们手里的“变量系统”。这篇文章就来讲清楚几个问题：深浅模式 UI 怎么做，变量系统应该怎么用，以及几个避坑点。

日夜主题UI怎么做？以前我们做设计用的是样式，是写死的。但变量不一样，变量是一个“容器”。你不用去记住深色模式下背景是 #1A1A1A，浅色是 #FFFFFF。你只需要建立一个叫 Bg-Primary 的变量。

如果要用变量来实现深色和浅色模式的切换，实操起来其实就这么几步：

变量系统的思路不是复制页面，不是批量替换，是系统级别切换。这样做，后期维护成本会低很多。

如果只拿变量来切个日夜主题，那属实有点大材小用了。真正跑过大项目的同学都知道，UI设计变量能干的活儿多着呢。真正完整的变量系统，应该包含：

这些变量玩法，目前像

这样的主流工具已经跑得很通了。但考虑到国内团队的实际环境，比如网络协同、数据安全这些绕不开的坎，我们也在尝试国产工具。像团队最近在用的

，它的变量逻辑和Figma基本一致，上手没什么门槛，管理和交付都方便了不少。

变量不只是设计端的事情，它会直接影响研发协作。做日夜模式时，最怕的就是跟前端扯皮。前端问你深色模式下这个灰条是多少，你还得去翻标注。我有个特别喜欢的方法分享给你：如果你在Pixso里用了变量系统，配合

，变量是可以被识别的，前端可以映射成 token 或 CSS 变量。日夜主题最终是在代码里实现的，这一步要是设计端没处理好，研发就得自己猜、自己翻译，还原度肯定打折扣。

变量如果前期没规划好，后期就很难维护了。给大家盘盘我踩过的几个大坑。

创建变量的时候，千万、绝对不要用具体颜色去命名！比如你建了个变量叫 Black，在浅色模式下它是黑色的文字。结果一切换到深色模式，为了能看清，这个 Black 变量的值变成了白色（#FFFFFF）。你能想象前端看到 color-black: #FFFFFF 时的表情吗？

命名要有语义。用功能来命名，比如 Text-Primary（主要文字）、Bg-Secondary（次要背景）。管它深色浅色是什么值，功能永远是对的。

很多人建变量，就只是建了一套。其实高级的玩法是“套娃”，也就是变量的嵌套引用。比如你先建一套基础变量：蓝-100、蓝-200、黑-900。然后再建一套语义变量：比如 Brand-Color（品牌色）。

不要把 Brand-Color 直接写成具体色值，而是让它去引用“基础变量”里的“蓝-500”。这就是变量的引用功能。以后品牌色如果要从蓝色变成紫色，你只需要改一下引用关系，几百个页面的主题瞬间搞定。目前 Figma 和 Pixso 都支持这个套娃逻辑，别浪费了不用。

画图的时候顺手吸了个颜色，忘记绑定变量。结果一键切换深色模式的时候，整个页面都暗下来了，就中间突兀地亮着一个白色的按钮卡片。去排查这种漏绑的元素很消耗耐心。

做完一个页面的组件，立刻切一下Dark Mode测试。别等整个所有页面画完了再去统一查漏，那个时候你会想砸键盘的。

现在中大型项目里，日夜主题基本都会被列入需求。做变量系统就是“先苦后甜”的活儿，前期搭框架、定命名规则的时候确实有点麻烦，但这个骨架一旦搭好，后面不管是搞深色模式、多品牌换肤，还是丢给研发跑D2C代码，都会变得很丝滑。