系统级色温调节（如“夜览”）会实时偏移所有rgb输出，导致css颜色失真；唯一可控方式是开发时关闭该功能并实机验证，而非依赖color-scheme或媒体查询。
系统级色温调节（如 macOS 的“夜览”、Windows 的“夜间模式”、Android 的“护眼模式”）会实时偏移所有 RGB 输出，CSS 里写的 #FF6B6B 在开启后可能变成偏橙的暗红——这不是 CSS 错了，而是浏览器渲染前就被系统层劫持了颜色通道。目前没有 API 能检测或绕过它，唯一可控动作是提前规避+实机验证。
为什么 color-scheme 和 @media (prefers-color-scheme) 都不顶用
这两个机制只响应用户对亮/暗主题的手动选择，和色温偏移完全无关。开启“夜览”时，window.matchMedia('(prefers-color-scheme: dark)').matches 仍返回 false，<meta name="color-scheme"> 也毫无反应。系统色温是底层图形栈的全局滤镜，浏览器无权读取其强度或状态。
哪些 CSS 写法会被色温调节明显干扰
-
rgb(255, 107, 107)和#FF6B6B：红色通道被压低，整体发橙、饱和度下降 -
hsl(0, 100%, 50%)：色相角被拉偏，359.9° 可能直接截断为 0°，但亮度同步衰减 -
background-color上的浅灰（如#F5F5F5）：在暖色温下显黄，在冷色温下显蓝，对比度骤降 -
border-color和box-shadow：边缘颜色失真后，视觉层次感崩塌，尤其深色背景下
真正有效的应对策略
放弃“修复”，转向“收敛”：
- 开发阶段关闭所有系统色温功能：macOS 关掉“夜览”，Windows 关掉“夜间模式”，Android 关掉“护眼模式”——否则 DevTools 里看到的值 ≠ 用户实际看到的
- 关键色块避免依赖绝对 RGB 值：用
color(srgb 1 0.4196 0.4196)显式锚定 sRGB，并前置color: #FF6B6Bfallback；虽然不能阻止系统滤镜，但至少确保不同浏览器起点一致 - 文字与背景对比度主动加余量：WCAG AA 要求 4.5:1，但在色温开启后实测常跌破 4.0:1，建议设计稿中按 5.0:1 标准验收
- 禁用
filter: brightness()或contrast()：这类 CSS 滤镜和系统色温叠加后会产生非线性漂移，调试极其困难
实机测试比任何声明都重要
Chrome DevTools 的“Rendering”面板无法模拟色温调节，matchMedia 也查不到。必须在真机上手动开关“夜览”/“夜间模式”，用同一张图、同一段 CSS，肉眼比对文字可读性、按钮活性、阴影层次。最容易被忽略的是 iPad Pro 的“原彩显示”——它不仅调色温，还动态响应环境光，连屏幕朝向都会影响最终色感。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
