颜色混合器，免费

颜色混合的原理

此工具在 RGB 颜色空间中进行加色混合。每种颜色的 RGB 分量按权重取平均值。这模拟了光线混合（例如重叠的投影灯光）的效果，与减色混合（如颜料混合）不同。

可以混合两种以上的颜色吗？

可以！点击「+ 添加颜色」最多可添加 8 种颜色。使用权重滑块控制每种颜色对混合结果的贡献。

使用方法

1. 选择颜色：使用选择器挑选每种颜色。点击「+ 添加颜色」可以增加颜色槽（最多 8 个）。
2. 调整每种颜色的权重：拖动每种颜色下方的滑块，控制其对最终混合结果的贡献。
3. 预览结果：混合后的颜色实时显示，并给出其 hex、RGB 和 HSL 值。
4. 复制混合颜色：点击即可复制结果的 hex 或 RGB 值，用在您的设计或代码中。

为什么使用颜色混合器？

颜色混合是设计中的一项基础操作 ， 创建淡色（与白色混合）、暗色（与黑色混合）、灰调（与灰色混合），或者在两种品牌色之间寻找和谐的中间色。设计师用它来生成调色板变体、寻找渐变色标中的中间色调、确保相邻颜色之间满足无障碍对比度，以及创建与基色视觉相关联的悬停/焦点状态。

人们说"混合颜色"时，其实在指三件事

当非专业人士说"把两种颜色混在一起"时，他们几乎总是在指三种完全不同的操作中的某一种。选错模型是颜色工具里最大的混乱来源。

加色混合是有色光束相互叠加时发生的事。一支红光手电和一支绿光手电同时打在同一块白墙上，会产生一块黄色。再叠加一支蓝光手电，则得到白色。模型是"光越多 = 越亮"，三原色是红、绿、蓝，因为人眼视锥细胞的灵敏度峰值大致就在这三个波段。每一块屏幕（手机、显示器、电视、投影仪）都使用加色混合。每个像素含有三个子像素 (R、G、B)，三者同时打满即为白色。这就是为什么 web 的默认颜色模型是 RGB：媒介是发光的，数学与媒介相匹配。

减色混合是颜料从白光中吸收波长时发生的事。青色油墨吸收红光，反射绿光和蓝光。黄色油墨吸收蓝光，反射红光和绿光。把青色叠在黄色之上，能同时通过两个过滤器的波长只剩下绿色。模型是"颜料越多 = 越深"，三种减色原色是青、品红、黄。理论上 CMY 在满强度下混合得到黑色，但实际上颜料并不完美，混合结果是浑浊的棕色，所以商业印刷加入了独立的黑色油墨（CMYK 中的 K）以获得真正的黑。在屏幕上跑的颜色混合器无法真正进行减色混合，因为屏幕本身是加色的；它只能模拟外观。

传统美术色彩理论告诉我们三原色是红、黄、蓝。绘画传统、歌德 1810 年的论颜色，以及伊顿 1961 年包豪斯教材色彩艺术都把 RYB 编纂为艺术家调色板的基础。RYB 并不符合物理。让色域最大化的真正减色原色是 CMY，不是 RYB。但 RYB 之所以能延续几个世纪，是因为真实颜料并非纯粹的减色滤镜：一管镉红和一管群青蓝混合后能得到可辨认的紫色，这个体系在画架前"管用"得足以教育一代又一代学生。本工具是一个加色 RGB 混合器，也就是 web 实际所做的，所以"红加绿"得到黄色，而不是颜料混合器会给你的棕色。

色彩空间：sRGB、Display P3、Rec. 2020、Adobe RGB

颜色模型（RGB、CMYK、HSL）告诉你有哪些维度。色彩空间则告诉你每一个数字三元组对应的物理颜色到底是什么：它确定了三原色的色度、白点和传递函数。两块同样说"RGB"的屏幕，如果瞄准的是不同的色彩空间，对同一个代码可能给出明显不同的红色。

• sRGB（IEC 61966-2-1:1999）从上世纪 90 年代末起就是 web 的默认色彩空间。1996 年由惠普和微软联合创建，用于在 PC 显示器、扫描仪和早期 web 之间统一颜色。约占 CIE 1931 可见色度图的 35%。Web 上任何未指定色彩空间的东西，按约定都视为 sRGB。
• Display P3，苹果广色域的起点。苹果在 2015 年底为 iMac Retina 5K 配备了瞄准 Display P3 的广色域屏幕，随后逐步推广到 iPhone（iPhone 7，2016 年 9 月）、iPad Pro 和 MacBook Pro 产品线。色域比 sRGB 宽约 25%，尤其在饱和的红色和绿色上更宽。CSS Color Module Level 4 增加了 color(display-p3 r g b) 语法。
• Rec. 2020（ITU-R Recommendation BT.2020，最早发布于 2012 年）是超高清电视的色彩空间，也是大多数 HDR 工作流的基础。覆盖可见光谱的约 75%，三原色坐落在光谱轨迹上。目前几乎没有任何消费级显示器能完整重现 Rec. 2020 的色域；这是一份面向未来兼容的规范。
• Adobe RGB (1998) 由 Adobe Systems 定义，目的在于给摄影师和印刷设计师比 sRGB 更宽的色域。大约宽 50%。它不是 web 色彩空间，浏览器不会默认采用，但专业相机、Lightroom 和 Photoshop 的印刷工作流里默认使用它。

感知色彩空间：以及为什么在 sRGB 里混合会得到浑浊的中点

大多数 web 工具用以存储和处理颜色的 sRGB 与 HSL 坐标在感知上并不均匀。HSL 的 L 通道上一个单位的变化，并不对应颜色看起来"明亮程度"的一个单位变化。这正是"对两个颜色逐通道求平均"会得出反直觉结果的深层原因。

经典例子：取纯红 #ff0000 和纯绿 #00ff00。对 RGB 通道逐分量求平均：红 255 → 127，绿 0 → 127，蓝保持 0。结果是 #7f7f00，一个看起来沉闷、偏暗、略显浑浊的橄榄色。它和你真正用红光和绿光打在同一块墙上得到的耀眼黄色 #ffff00 完全不是一回事。两个互相叠加的问题解释了这一现象。

第一，sRGB 是伽马编码的。存储的数字 127 并不代表 255 一半的光强。传递函数是非线性的：sRGB 中的 127 对应大约 21% 的线性光强，而不是 50%。所以当你对伽马编码的值求平均时，相当于在对"强度的平方根"求平均，而不是强度本身，结果就比应有的暗得多。仅针对这一问题的修正办法是：在求平均之前先把 sRGB 转成线性 RGB，求完再转回去。在线性 RGB 中做平均后，红加绿除以二会变成一个亮度可信得多的偏黄绿色。

第二，即便是线性 RGB 也跟感知不一致。线性 RGB 中等距的步长，仍然不对应于感知上等距的亮度或色度差。红与蓝在线性 RGB 中的中点是一个低饱和度的薰衣草色，而不是设计师期待的饱满紫色。要解决这个更深层的问题，得在感知均匀的空间里混合，Lab、Oklab、OKLCH。把两端转成 Oklab，对 L、a、b 三个通道做线性插值，再转回 sRGB。红与绿在 Oklab 中的中点是一个鲜艳可信的黄色。红与蓝的中点是一个饱和的品红。黄与蓝的中点则是一个干净的中性灰，而不是朴素 RGB 给你的那种沼泽绿。

本工具目前在伽马编码的 sRGB 中做平均，这是最简单的模型，也正是产生那些浑浊中点的模型。对那种简单情况来说它是正确的，但和真实的物理光与人眼感知并不一致。如果你在挑选渐变停止点或调色板的中间色调、不想踩进浑浊灰的陷阱，请使用下文介绍的 CSS color-mix() 函数或其中一个色彩数学库。

CIE Lab、Oklab、OKLCH：感知色彩栈

CIE Lab（也写作 CIELAB）由国际照明委员会于 1976 年发表。它有三个轴：L* 表示明度（0 黑到 100 白），a* 是绿-红色品轴，b* 是蓝-黄色品轴。设计目标是让等量的数值差大致对应等量的感知差。在过去半个世纪中，它一直是图形学、视觉科学和色彩管理的标准感知空间。已知的弱点：蓝色在插值时会变得反常地偏紫；在高饱和度颜色上，明度轴并不能完美对应感知。

CIE LCH 只是把 CIE Lab 用极坐标表示：L 为明度，C 为色品（到中性轴的距离），H 为色相角。对设计师来说，它比原始的 a*/b* 更好用，因为"色相平移 30 度"或"把色品降到 0"这种操作能直接对应到自然的心智模型。

Oklab 由 Björn Ottosson 于 2020 年 12 月在题为 "A perceptual color space for image processing" 的文章中提出，发表在 bottosson.github.io 上。Ottosson 是一位瑞典工程师，曾在游戏行业从事色彩相关工作。Oklab 修复了 CIE Lab 大部分已知缺陷（特别是插值中的蓝紫漂移以及对饱和颜色色品差的过度估计。W3C 在 Ottosson 这篇博客之后大约一年内就把 Oklab 纳入了 CSS Color Module Level 4）对一个新色彩空间来说，标准化速度异常之快。如今每个主流浏览器都原生支持 oklab()。

OKLCH 是用柱坐标表示的 Oklab：L 是明度（0 到 1），C 是色品（0 到约 0.4），H 是色相角（0 到 360 度）。它正成为最被推荐用于设计系统调色板的色彩空间，原因正是它的轴向操作能干净地映射到设计师的直觉，而且两个 OKLCH 颜色之间的插值会产生当前 CSS 中可得最平滑、最讨喜的渐变。

CSS color-mix() 函数：无 JS 的感知混合

CSS Color Module Level 5 引入了 color-mix()，它接受两个颜色、一个插值色彩空间以及可选的权重，由浏览器全程计算混合结果。语法形如 color-mix(in oklch, red 50%, blue 50%)。你可以切换空间（in srgb、in oklab、in lch、in hsl longer hue 等），数学就在那个空间里跑。浏览器支持在 2023 年初到位：

• Safari 16.2，2022 年 12 月（最先发布的浏览器）
• Chrome 111，2023 年 3 月
• Edge 111，2023 年 3 月（同一个 Chromium 版本）
• Firefox 113，2023 年 5 月

无 JavaScript、CSS 原生的颜色混合器，至今已经普及了两年多。任何建立在 color-mix() 之上的工具，都能"免费"获得感知正确的结果，转换栈交给浏览器处理。CSS Color Module Level 4 本身也在 2022 年达到了 Candidate Recommendation 状态，并在现代浏览器中得到了广泛支持。

色彩数学的 JavaScript 库

当你不能或不想依赖 color-mix() 时，有三个库最为常见：

• Dan Burzo 写的 culori.js，最灵活。几乎支持所有有名字的色彩空间（sRGB、线性 RGB、P3、Rec. 2020、Lab、LCH、Oklab、OKLCH、HSL、HSV、Cubehelix、OKHSL、OKHSV 等等）。Tree-shakable，ESM 优先。基于 OKLCH 生成调色板的参考实现。
• Lea Verou 和 Chris Lilley 写的 colorjs.io，某种意义上的"规范作者库"，因为 Lilley 是 CSS Color Module 规范的共同编辑者。忠实于 CSS Color 规范的语义，体积比 culori 略大。当你希望结果与浏览器计算完全一致时是好选择。
• Gregor Aisch 写的 chroma-js，更老、更顺手、更小。在色阶和简单插值上非常出色。支持 Lab 和 LCH，但截至最近一次主要版本未支持 Oklab；社区分支已经补上。

色彩理论简史

西方色彩理论始于 1665 年的伊萨克·牛顿。在因瘟疫被迫离开剑桥的隔离期间，牛顿让阳光穿过棱镜，识别出七种独立的颜色（红、橙、黄、绿、蓝、靛、紫）。随后他把它们排在一个闭合圆环上（牛顿色环）通过一种非光谱的品红把光谱两端的紫色和红色连起来。这个色环 1704 年发表在他的光学中，但实际是 1665-1666 年间的工作。

约翰·沃尔夫冈·冯·歌德在 1810 年出版了论颜色（Zur Farbenlehre）。牛顿是物理学家，而歌德是诗人，他考察的是色彩的心理学：颜色给观察者带来的感受、对比与组合。他的工作在许多点上并不科学，但他引入的互补色、色后像、暖色与冷色调的情感性格等思想直至今天仍在传授。

包豪斯大师 约翰内斯·伊顿在 1961 年出版了色彩艺术（Kunst der Farbe）。伊顿那十二辐的 RYB 色环以及他的七种色彩对比（色相、明暗、冷暖、互补、同时、饱和度、面积）成了 20 世纪下半叶设计教育的主导教学框架。

Pantone 由 Lawrence Herbert 创立，他 1956 年作为雇员进入 Pantone Inc.，1962 年买下公司。1963 年他推出了 Pantone Matching System (PMS)：一套以编号识别的标准化专色油墨库，配以印刷的色样册，使得纽约的设计师和香港的印刷工能够无歧义地指定并复制完全相同的颜色。Pantone 在 CIE 的技术意义上并不是一个色彩空间（它是一个专有的物理油墨混合目录）但它对专业色彩流程的影响巨大。

HSL 与 HSV 由 Alvy Ray Smith 在 1978 年发表的论文 "Color Gamut Transform Pairs" 中提出，发表于 SIGGRAPH 论文集，那时他在 Xerox PARC（Smith 后来联合创办了 Pixar）。他在寻找比 RGB 更贴近艺术家直觉的颜色坐标。HSL 成为 web 上默认的"对设计师友好"的颜色模型，在 CSS 中至今仍是被广泛认可的非 RGB 标记法。然而它在感知上并不均匀，OKLCH 是它的现代继任者。

对比度与无障碍：WCAG 1.4.3

当设计师把两个颜色混出第三个颜色（一个悬停态、一个着色背景、一个渐变停止点）结果颜色仍然必须与放在它上面的任何文本或图标满足对比度要求。WCAG 2.x 的成功准则 1.4.3 "对比度（最低）" 要求：

• 对于普通正文文字，至少 4.5:1 的对比度。
• 对于大号文字（18pt 常规或 14pt 粗体及以上）以及图形对象和 UI 组件，至少 3:1。

对比度通过相对亮度计算，也就是上文描述的线性 RGB 转换以及对线性化通道加权求和（L = 0.2126·R + 0.7152·G + 0.0722·B）。两个颜色之间的对比度是 (L_较亮 + 0.05) / (L_较暗 + 0.05)。一个实用含义：渐变中间的某些停止点可能在两端通过对比度检查，但在中间彻底失败。如果一个品牌把深海军蓝和明黄色混成一个悬停态橄榄色，那个橄榄可能在白字与黑字两边都落入 WCAG 失败区。

更多问答

为什么红加绿没有给我棕色？

因为这个工具（和所有屏幕一样）使用的是加色 RGB 混合，红光加绿光给出黄色。棕色是你把红绿两种颜料混在一起得到的，那是减色：每种色素吸收不同的波长，残存的波长看起来就偏棕。要在屏幕上准确模拟"颜料混合"，需要光谱或感知颜料的模型（Procreate 和 Adobe Fresco 在绘画 app 中做了这件事）；通用的 web 颜色混合器（包括这一个）都是诚实的加色 RGB 混合器，给你的就是黄色，而不是棕色。

我的中间点看起来很浑浊，怎么修？

两层修法。最低限度的正确性是线性光混合：在求平均之前把 sRGB 转成线性 RGB，再转回去。仅此一项就能让红+绿→黄看起来明亮且可信得多。完整的感知修法是在 OKLCH 或 Oklab 中混合，把两端转成 OKLCH，插值，再转回。浏览器的 CSS color-mix(in oklch, red, green) 一行就完成了，所有 2023 年 5 月之后发布的浏览器都支持。在 JavaScript 流水线里，culori.js 是参考实现。

做设计系统调色板时，应该在哪个色彩空间里混合？

当前的共识答案是 OKLCH。它感知均匀，轴向干净并匹配设计师直觉（明度 / 色品 / 色相），渐变插值不会出现浑浊中点，并且通过 CSS Color 4 的 oklch() 和 CSS Color 5 的 color-mix(in oklch, ...) 在每一款现代浏览器中可用。在 2024-2026 年构建的设计系统正出于完全相同的原因，从基于 HSL 的调色板逐步切换到基于 OKLCH 的调色板。

我混出来的颜色能通过 WCAG 对比度检查吗？

本工具目前未展示结果的对比度，但你可以自己算：WCAG 亮度是线性化 sRGB 通道之后的 L = 0.2126·R + 0.7152·G + 0.0722·B，两色对比度是 (L_较亮 + 0.05) / (L_较暗 + 0.05)。目标是正文 4.5:1、大号文字或 UI 组件 3:1。相关工具区里的 Color Contrast Checker 直接执行这套计算。

相关工具