当同一张设计稿在不同电脑、不同手机上呈现出“发黄”“偏紫”“更饱和”“更灰”的差异时，很多人第一反应是怀疑配色。实际上，颜色的最终呈现取决于一条很长的链路：设计软件的工作色彩空间、文件是否嵌入 ICC、系统是否开启色彩管理、显示器的色域与校准状态、浏览器或应用是否尊重色彩配置，以及导出时是否被转换为 sRGB。链路里任何一环偏离，都可能把你精心调好的颜色带到另一个世界。
在互联网产品中，sRGB 之所以重要，不是因为它更高级，而是因为它更像一个共同约定：大多数设备、浏览器、图片管线对 sRGB 的支持最稳定。当你在广色域显示器上用 P3 或更宽的色域调色，视觉会非常鲜艳，但如果导出或展示环节没有正确管理色彩，用户看到的可能是被错误解释的颜色，饱和度会被夸大或被压扁。
稳妥的做法是：界面类交付默认以 sRGB 为基准进行评审与导出；如果项目明确面向支持广色域的设备，再额外提供 P3 版本，并明确说明使用场景。把“默认交付”做稳，比在少数设备上追求极致更重要。
你可能会遇到一种诡异情况：同一张图在 A 设备上看起来层次丰富，在 B 设备上却像被压扁。很多时候这与伽马曲线和对比增强有关。部分设备会做动态对比或“鲜艳模式”，让中间调更亮、暗部更深，从而让界面看起来更“有冲击力”。这对摄影作品可能有吸引力，但对 UI 设计会造成严重误判：你以为按钮的层级足够，其实只是设备在帮你加了滤镜。
因此评审时尽量关闭系统级的“鲜艳/增强/护眼”类模式，至少在一个相对中性的设备上把关键页面看一遍。你要保证在“不过度增强”的条件下，层级依然成立。
很多人以为导出 PNG/JPG 就结束了，但导出时如果没有把颜色转换到目标空间，或者没有嵌入正确的配置文件，后续显示环节就会用默认假设去解释它。对 web 交付而言，优先选择明确转换到 sRGB 的导出方式，并确保资源在压缩、CDN、图床处理时不会被二次转换。
如果团队里有人负责切图与资源管线，把“颜色空间转换”写进交付约定非常值得。因为一旦进入生产环境，颜色问题往往很难追溯：你看到的是最终渲染结果，很难反推出是哪个环节出了偏差。
纯色块的偏差往往还可接受，但渐变、半透明阴影、叠加层会把差异放大。原因是这些元素涉及大量中间调，任何伽马差异都会让过渡变得“断层”或“脏”。当你发现某些设备上渐变不干净，不要先怪渐变本身，而要先确认色彩空间与导出是否一致。
想要更稳，可以减少在关键 UI 中依赖极其细腻的多段渐变，把氛围留给背景，把信息留给更清晰的层级。你会发现这种克制反而更耐看。
如果你经常遇到颜色争议，建议把流程固定下来：选一台相对中性的设备作为基准；规定默认工作空间与导出空间；明确资源经过哪些压缩与托管环节；在关键页面上做一次跨设备抽检。这样你讨论的就不是“谁的眼睛更准”，而是“链路在哪一步发生了偏差”。这会让沟通成本直线下降。
如果团队经常因为颜色起争议，建议在规范里明确：默认交付与验收以 sRGB 为准；关键页面至少在一台普通 sRGB 设备与一台广色域设备上抽检；导出图片必须转换到 sRGB 并保留一致的配置策略；前端不得对 UI 资源做额外的“增强/锐化/饱和”处理。这样问题出现时，你们能快速定位是“资源不一致”还是“设备模式差异”。
截图与录屏常常经历二次压缩、色彩空间重新解释与播放器处理，最终呈现并不等同于真实渲染。讨论颜色时尽量用原始资源或在线页面在同一设备上对比，并记录设备的显示模式与色彩设置。把对比条件统一，才能减少无意义的拉扯。
验收颜色时，先固定三个变量：设备显示模式（标准/鲜艳/护眼）、系统色彩管理是否开启、以及浏览器/应用是否尊重 ICC。然后再对比同一资源在不同设备上的观感。你会发现很多争议并不是“谁的审美更准”，而是对比条件不一致。把条件写进验收说明，后续就能复用。
如果你的资源会经过图床、CDN、压缩服务，务必确认：颜色空间转换发生在压缩之前，且压缩不会剥离配置导致二次解释。最稳的方式是导出时就转换到 sRGB，并把“压缩后是否保持 sRGB”作为抽检项。这样即便后续服务变更，也能快速发现问题。
在不可控的显示环境里，完全依赖细微色差来表达层级风险很高。你可以用更稳定的手段兜底：空间（间距/留白）、字体（字号/字重层级）与边界（描边/分割）来承载主要层级，让颜色更多承担情绪与强调。这样即使某些设备把颜色“拉偏”，信息结构仍然不会塌。
把默认交付锁定在 sRGB，你就能用最小的成本覆盖最多的设备；当项目确实需要 P3 等广色域时，再把它作为明确的增强项单独交付与验收。这样既不牺牲一致性，也不阻碍高端设备的表现。
