配色这件事我踩过的坑比大多数人想象的多。早些年做移动端项目设计师丢过来一套色板我照着写进代码上线之后在低亮度屏幕上整个界面发灰用户反馈看着累。后来做数据可视化同一组颜色在浅色背景上区分度很好换到深色主题直接糊成一团。再后来带团队发现新人最常问的问题不是这个颜色怎么调而是我该去哪里找颜色。这三个场景——找灵感、定方案、写进代码——其实是三件完全不同的事但大多数人把它们混在一起用一个收藏夹解决所有问题结果就是收藏了几百个网站真到用的时候一个都想不起来。这篇清单就是按这三个场景重新梳理的。我不打算给你一个100个配色网站的大杂烩那种清单我见过太多收藏之后基本不会打开第二次。我要做的是把颜色相关的工具按使用阶段切开你是在毫无头绪地找感觉还是已经确定了主色要配一套完整的语义色板还是色板已经定了要转成工程可用的 token。每个阶段需要的工具类型完全不同评价标准也不同。看完之后你应该能建立起自己的分类逻辑而不是记住一堆网址。1. 先搞清楚你在哪个阶段再决定打开哪个网站很多人找配色网站的效率低根本原因不是网站不好而是用错了阶段。拿一个生成渐变色的工具去解决整套设计系统色板的问题就像拿螺丝刀去敲钉子能用但别扭。我把颜色工作流拆成四个阶段每个阶段的核心诉求和判断标准都不一样阶段核心诉求典型产出判断标准灵感探索找到感觉对的方向情绪板、参考图视觉冲击力、多样性方案生成把感觉变成可用的色板5-10 个色值的组合和谐度、可调性系统化扩展成完整的语义体系主色/辅助/状态色全套层级清晰、可扩展工程落地转成代码可用的格式CSS 变量、Design Token格式规范、可维护大部分人的问题出在跳过第二阶段直接进第三阶段。看到一个喜欢的配色直接拿去当设计系统的主色结果发现只有三四个颜色根本撑不起一个完整界面需要的十几种状态。或者反过来在灵感阶段就纠结具体的十六进制值本末倒置。提示判断自己处于哪个阶段有个简单方法——如果你能说出我想要偏暖的、低饱和的、带一点复古感这样的描述你已经在方案生成阶段了如果你只能说我想要好看的那你还在灵感探索阶段。下面几节我按这四个阶段分别展开每个阶段会讲清楚这个阶段该用什么类型的工具、为什么、以及我实际用下来哪些值得留。注意我不会给每个网站打星评分那种评分没有意义因为同一个工具对不同阶段的人价值完全不同。1.1 灵感探索阶段你要的是量和意外灵感阶段最忌讳的就是精准。你越知道自己要什么越容易陷入舒适区最后做出来的东西千篇一律。这个阶段需要的是大量、多样、甚至有点意外的视觉输入。我自己的做法是先花 20 分钟快速浏览不保存任何东西让眼睛过一遍。然后再花 10 分钟回头找那些刚才让我停顿了一下的页面。这个停顿就是直觉在告诉你方向。这个阶段我会用的工具类型包括社区驱动的配色分享站、按情绪/主题分类的色板库、以及从图片提取配色的工具。社区驱动的好处是你能看到别人在什么场景下用了什么颜色这种上下文比孤立的色值有价值得多。从图片提取配色的工具则适合你手头已经有一张参考图比如一张摄影作品、一张海报的情况。这里有个经验灵感阶段不要看热门配色榜单。热门意味着被大量使用被大量使用意味着你的作品会撞脸。我更喜欢按时间倒序看最新提交或者按特定主题比如复古自然科技筛选这样找到的东西更有辨识度。1.2 方案生成阶段从感觉到数值的转换当你有了方向之后就需要把模糊的感觉变成具体的色值。这个阶段的核心工具是色板生成器但生成器之间差异很大选错了会很痛苦。我评价一个色板生成器主要看三点是否支持锁定某个颜色你确定主色不想变只想让它配辅助色、是否支持调整色相/饱和度/明度的分布规律而不是随机生成、是否能导出多种格式。第一点尤其重要很多生成器一按空格全部重来你刚看中的那个主色就没了。这个阶段还有一个容易被忽略的需求色板的可调性。什么叫可调性就是当你把主色稍微调亮一点整套色板能不能跟着协调变化。好的生成器会基于色彩理论比如互补、三角、分裂互补这些关系来生成你调一个其他跟着动而且动完之后依然和谐。差的生成器就是给你一堆随机色改一个就崩。1.3 系统化阶段从色板到语义体系这是最多人卡住的阶段。一个界面需要的颜色远不止主色辅助色还有成功、警告、错误、信息这些状态色文字的一级二级三级背景的层级边框、分割线、禁用态……加起来轻松超过 20 个色值。这个阶段你需要的是能帮你建立层级关系的工具而不是单纯生成颜色的工具。核心思路是先定一个基准色通常是主色然后按明度阶梯生成一系列变体再给每个变体赋予语义比如 primary-100 到 primary-900。这样做的价值在于当品牌色调整时你只需要改基准色整套体系跟着变。我见过太多项目把颜色写死成#3B82F6这种后来品牌升级要换色全项目搜索替换漏掉几个就出 bug。系统化阶段偷的懒工程落地阶段都要还回来。1.4 工程落地阶段颜色怎么变成代码最后一个阶段是把设计稿里的颜色变成代码里可维护的 token。这个阶段的关键词是命名规范和格式转换。命名规范方面我强烈建议用语义命名而不是视觉命名。color-primary比color-blue好因为哪天主色从蓝变成紫color-blue这个名字就成了谎言而color-primary依然准确。这个道理听起来简单但实际项目里用视觉命名的还是占大多数。格式转换方面你需要的是能把色板导出成 CSS 变量、SCSS 变量、JSON、甚至 Tailwind 配置的工具。手动一个个复制十六进制值不仅慢还容易出错。这个阶段我会专门用一两个转换工具而不是靠生成器自带的导出功能因为转换工具通常支持更多目标格式。2. 灵感探索类工具怎么用才不浪费时间灵感类工具最大的陷阱是无限浏览。你打开一个配色社区一页一页翻下去两小时过去了收藏了五十个色板但一个都没用上。这不是工具的问题是使用方式的问题。我的做法是给灵感阶段设时间盒。比如明确告诉自己接下来 15 分钟只做浏览不保存15 分钟一到从记忆里挑出三个印象最深的再回去细看。这个方法的原理是真正打动你的东西会留在记忆里需要靠收藏才能记住的说明冲击力不够。2.1 社区型配色站看的是上下文不是色值社区型配色站的价值不在于色值本身而在于别人怎么用。同一个色板用在电商页面和用在数据看板上效果完全不同。看社区作品的时候我建议你关注三件事这个色板的主色占比多少、辅助色用在什么元素上、整体是高明度还是低明度。有个细节很多人忽略社区里的色板通常是展示用的为了好看会拉高饱和度、加大对比。但实际界面里大面积使用高饱和色会让人视觉疲劳。所以从社区拿色板通常需要降饱和、降对比再用。我一般的做法是把饱和度砍掉 20% 到 30%明度往中间收一收这样出来的颜色更适合长时间观看。另外社区型网站适合按标签筛选而不是按热度。热度高的往往是那些视觉冲击强的适合做海报不适合做界面。按柔和低饱和自然这类标签筛更容易找到能直接用的。2.2 图片取色工具从参考图到色板的桥梁当你手头有一张喜欢的图片——可能是一张摄影作品、一张电影截图、一张海报——图片取色工具能帮你把里面的颜色提取出来。这类工具的原理通常是色彩量化把图片里成千上万种颜色聚类成 5 到 10 种主色。用这类工具有个技巧不要直接用自动提取的结果。自动提取出来的颜色往往包含大量中间调看起来灰蒙蒙的。我的做法是提取之后手动挑把那些明显是过渡色的去掉只留最有代表性的几个。然后以这几个为基准再去生成器里扩展成完整色板。还有一个坑图片取色提取的是图片的颜色不是适合界面的颜色。一张夕阳照片提取出来的橙红色直接用在按钮上会非常刺眼。所以提取之后一定要做调整通常是降饱和、调明度让它适应界面的使用场景。2.3 按情绪和主题分类的色板库这类工具的好处是帮你把感觉翻译成关键词。你说不清想要什么颜色但你能说清想要什么感觉——安静的有活力的专业的温暖的。按情绪分类的色板库就是把这些感觉和具体的颜色对应起来。我特别推荐在项目启动初期用这类工具。跟客户或产品经理沟通的时候与其争论这个蓝色好不好看不如问你想要专业感还是亲和感然后拿出对应的色板。这样沟通效率高得多也避免了我觉得不好看这种无法推进的反馈。用这类工具的时候要注意情绪和颜色的对应关系不是绝对的受文化、行业、个人经历影响很大。同一个蓝色在金融行业代表可靠在食品行业可能代表冷淡。所以这类工具给的是起点不是答案最终还是要结合具体场景调整。3. 色板生成器锁定、调整、导出这三件事决定效率色板生成器是颜色工作流里最核心的工具类型但市面上的生成器质量参差不齐。我用下来决定一个生成器好不好用的就是三件事能不能锁定、能不能精细调整、能不能方便导出。这三件事缺一个用起来就会很别扭。3.1 锁定功能为什么它比生成功能更重要大部分生成器的主打功能是按空格生成新色板但实际工作中锁定比生成重要得多。因为你的工作流程通常是这样的先找到一个满意的主色然后希望其他颜色围绕它来配。如果一按生成全部重来你永远在重新开始。好的生成器应该支持逐个锁定。你锁定主色生成辅助色满意之后锁定辅助色再生成状态色。这样一步步收敛而不是每次推倒重来。我甚至见过支持锁定色相关系的生成器——你锁定主色和辅助色之间的互补关系调整主色时辅助色跟着按互补关系变化。这种设计才是真正理解工作流的。注意如果一个生成器只有随机生成没有锁定它基本只能用于灵感阶段不能用于方案生成阶段。选工具的时候先看这个。3.2 调整维度HSL 比 RGB 更符合直觉调整颜色的时候用 HSL色相、饱和度、明度比 RGB 直观得多。原因很简单人描述颜色的时候说的是再亮一点再淡一点偏红一点这些对应的是明度、饱和度、色相而不是红绿蓝三个通道的数值。好的生成器会提供 HSL 滑块而且会显示色相环让你直观地拖拽。更进一步的是提供色相分布规则——比如你定了主色的色相是 210生成器可以按互补21018030、三角210±120、分裂互补这些规则自动算出辅助色的色相。这样生成出来的色板在色彩理论上是站得住脚的不是随机拼凑。明度方面好的生成器会按等间距生成阶梯。比如从 10% 到 90% 分九档每档差 10%。这样出来的色板在明度上是均匀过渡的适合做层级。差的生成器明度分布随机出来的色板有的档位挤在一起有的档位跳得很大用起来很难受。3.3 导出格式别小看这一步导出看起来是小事但实际影响很大。如果一个生成器只能导出图片或者只能复制单个色值你在工程落地阶段就要手动一个个抄几十个色值抄下来出错概率很高。我理想的导出应该支持CSS 变量直接粘进样式文件、JSON给设计工具或构建脚本用、SCSS/LESS 变量如果用预处理器、Tailwind 配置片段如果用 Tailwind。格式越全越好因为不同项目用的技术栈不一样。还有一个细节导出的时候命名规则能不能自定义。有的生成器导出的是color-1、color-2这种无意义的名字你还得手动改成primary-500这种语义名。好的生成器允许你设置命名前缀和层级规则导出即用。4. 从色板到 Design Token系统化阶段的关键动作色板生成出来只是第一步真正让颜色在项目里可维护的是把它变成Design Token。这一步做得好不好直接决定了半年后你改品牌色是十分钟还是两天。4.1 语义分层为什么需要 50 到 900 这样的编号你可能见过primary-50到primary-900这种命名数字代表明度阶梯50 最浅900 最深。这种编号方式来自设计系统领域的实践好处是层级清晰、可扩展。具体怎么分我一般的做法是50 到 100 用于背景和浅色填充200 到 400 用于边框和次要元素500 是主色本身用于主要按钮、链接600 到 700 用于悬停和按下状态800 到 900 用于深色背景上的文字。这样一套下来一个主色就扩展出九个可用色值覆盖了大部分界面需求。状态色成功、警告、错误、信息也按同样的逻辑扩展。这样整个体系是同构的你学会了主色的用法就学会了所有颜色的用法。这种一致性对团队协作特别重要新人上手快review 的时候也容易发现问题。4.2 深色模式的色板映射深色模式是很多人做色板时忽略的场景。浅色模式下的primary-500直接放到深色背景上往往会显得刺眼或者对比不足。正确的做法是为深色模式单独映射一套。映射的逻辑不是简单反转。浅色模式下 500 是主色深色模式下主色可能需要用 400 或 300更亮一点因为深色背景会吃掉颜色的亮度。背景色也不是简单地把白色换成黑色而是用深灰比如#121212而不是#000000因为纯黑背景上的阴影和层级很难表现。我通常会在 Token 层面做两层一层是原始色板primary-50 到 900一层是语义 Tokenbackground、surface、text-primary、border 等。语义 Token 引用原始色板浅色和深色模式各有一套映射。这样切换主题的时候只需要换映射关系不用改组件代码。4.3 对比度检查别让颜色只是好看颜色除了好看还要可读。文字和背景的对比度不够用户看不清这是可用性问题不是审美问题。国际上有个通行的对比度标准WCAG正文文字要求对比度至少 4.5:1大号文字至少 3:1。做色板的时候我建议边做边检查对比度而不是做完再检查。因为如果做完发现一堆不达标返工成本很高。好的工具会实时显示对比度数值你调颜色的时候就能看到是否达标。我一般会把主要文字色和背景色的组合都过一遍确保没有漏网的。有个经验不要为了对比度牺牲太多美感。有时候稍微调整明度就能达标不需要大改色相。比如一个灰色文字在白色背景上对比度 4.2差一点点把明度降 5% 就达标了视觉上几乎看不出变化。5. 工程落地颜色进代码之后的那些事颜色写进代码不是终点而是另一个起点。这一节讲的是颜色在工程侧的实际问题这些是设计工具里不会告诉你的。5.1 CSS 变量的组织方式用 CSS 变量管理颜色关键是分层。我一般分三层第一层是原始色值--blue-500: #3B82F6第二层是语义变量--color-primary: var(--blue-500)第三层是组件变量--button-bg: var(--color-primary)。为什么要三层因为这样改动的影响范围可控。品牌色变了只改第二层的映射第一层的原始色值和第三层的组件变量都不用动。如果只有一层改一个色值全项目受影响风险很大。命名上我建议用短横线连接的小写kebab-case这是 CSS 社区的惯例。层级用数字后缀表示比如--color-primary-500。避免用驼峰或者下划线虽然技术上可行但和社区惯例不一致协作时容易混乱。5.2 构建时生成 vs 运行时切换颜色的工程实现有两种思路构建时生成和运行时切换。构建时生成是指用 SCSS 变量或者构建脚本在打包的时候把颜色写死进 CSS。运行时切换是指用 CSS 变量在浏览器里动态改变量值。构建时生成的优点是性能好浏览器不需要处理变量解析缺点是不灵活切换主题要重新加载。运行时切换的优点是灵活主题切换即时生效缺点是有轻微性能开销而且老浏览器可能不支持。我的建议是如果只需要浅色模式用构建时生成如果需要深色模式或者多主题用运行时切换。现在 CSS 变量支持已经很好了大部分项目用运行时切换没问题。关键是做好降级方案万一变量没加载要有默认值兜底。5.3 颜色的可访问性测试上线之前颜色的可访问性一定要测。除了前面说的对比度还要考虑色盲用户。红绿色盲是最常见的如果你的错误状态用红色、成功状态用绿色红绿色盲用户可能分不清。解决办法是不要只靠颜色传达信息。错误状态除了红色再加一个图标或者文字说明成功状态除了绿色也加图标。这样即使分不清颜色也能通过其他线索理解状态。测试工具方面浏览器开发者工具里一般有色盲模拟功能可以切换不同的色盲类型看效果。我一般会过一遍红绿色盲和蓝黄色盲确保关键信息不丢失。这个检查花不了几分钟但能避免很多可用性问题。6. 我实际用下来的一些经验和取舍说了这么多工具和阶段最后分享几个我实际用下来觉得重要的经验。这些不是工具推荐而是使用工具的思路可能比具体用哪个网站更有价值。第一个经验建立自己的色板库。每次做完项目把用过的色板整理归档标注适用场景比如适合工具类产品适合内容社区。下次做类似项目直接从库里找起点比从零开始快得多。我现在的库里大概有三十多套色板覆盖了大部分常见场景。第二个经验颜色不要超过必要数量。新手容易犯的错是颜色越加越多最后界面花里胡哨。我的原则是主色一个辅助色一到两个状态色四个中性色一套从白到黑分九档。加起来不超过二十个色值足够覆盖绝大多数界面。颜色少一致性容易保证维护成本也低。第三个经验在真实设备上看颜色。设计工具里的颜色和实际屏幕上的颜色有差异尤其是手机屏幕和显示器差异更大。我一般会在手机上、笔记本上、外接显示器上都看一眼确保颜色在不同设备上都不会出问题。有条件的话在低亮度环境下也看一眼很多颜色在暗光下会显得不一样。第四个经验颜色的调整要留记录。每次改色板记下改了什么、为什么改。这个习惯在项目后期特别有用因为改来改去很容易忘记当初为什么这么定。我一般会在项目的设计文档里维护一个颜色变更记录简单几行字但省了很多扯皮。关于工具的选择我的态度是不要迷信任何一个。每个工具都有它的适用场景重要的是理解自己的工作流知道每个阶段需要什么然后选对应的工具。工具会过时网站会关停但工作流的思路是稳定的。你把这套思路建立起来换什么工具都能快速上手。最后说一个我踩过的坑早期我特别喜欢收集配色网站浏览器书签里存了几十个。后来发现真正高频使用的就那么三四个其他的都是看起来有用但从来不用。所以现在我的做法是每个阶段只留一到两个工具其他的需要时再找。工具少了反而用得精了效率更高。