Web Safe 颜色在现代 CSS 中已无实际必要，因其仅适用于1990年代256色显示器，而今浏览器全面支持24位真彩色；其216种颜色由RGB各取00/33/66/99/CC/FF构成，如#336699，旨在避免早期抖动，但如今强制使用会导致色彩灰暗、对比度下降、可访问性变差及工具链警告。
Web Safe 颜色在现代 CSS 中已无实际必要，浏览器和设备早已全面支持 24 位真彩色（即 #RRGGBB 或 rgb() 的全部 1677 万种组合），所谓“Web Safe 色表”（216 种）仅适用于 1990 年代的 256 色显示器，如今强行限制只会让颜色显得灰暗、不准确。
什么是 Web Safe 颜色表？
它指由 R、G、B 各取 00、33、66、99、CC、FF 六个值（共 6³ = 216 种）组成的颜色集合，例如 #336699、#FF0033。这些值在早期 8 位色模式下能避免浏览器抖动（dithering）——但今天所有主流浏览器和操作系统都忽略该限制，直接渲染指定值。
为什么不要主动用 Web Safe 颜色写 CSS？
现代开发中硬性套用 Web Safe 表，会带来明确副作用：
- 设计稿中的
#4A90E2被改成#336699，视觉明显偏暗偏浊 - UI 组件（如按钮悬停态）用
rgb(102, 102, 153)替代rgb(74, 144, 226)，对比度下降，可访问性变差 -
工具链（如 PostCSS、Tailwind JIT）可能对非标准十六进制值报 warning，尤其当
#336这类缩写被误判为非 Web Safe 时 - 设计师给的 Figma 色值（如
hsl(210, 60%, 60%)）若转成 Web Safe，会丢失色相饱和度精度
如果必须兼容极老环境（比如嵌入式 WebView）怎么办？
极少数场景（如某款定制工控屏的 IE6 内核 WebView）真有要求，可手动映射，但不要全局替换：
立即学习“前端免费学习笔记（深入）”；
function toWebSafe(hex) {
const safeValues = [0x00, 0x33, 0x66, 0x99, 0xCC, 0xFF];
const r = parseInt(hex.slice(1, 3), 16);
const g = parseInt(hex.slice(3, 5), 16);
const b = parseInt(hex.slice(5, 7), 16);
const closestR = safeValues.reduce((a, v) => Math.abs(v - r) < Math.abs(a - r) ? v : a);
const closestG = safeValues.reduce((a, v) => Math.abs(v - g) < Math.abs(a - g) ? v : a);
const closestB = safeValues.reduce((a, v) => Math.abs(v - b) < Math.abs(a - b) ? v : a);
return `#${closestR.toString(16).padStart(2, '0')}${closestG.toString(16).padStart(2, '0')}${closestB.toString(16).padStart(2, '0')}`;
}
// toWebSafe('#4A90E2') → '#3399CC'
注意：该函数只在明确需要时调用，且应作为构建时静态处理（如通过 PostCSS 插件），而非运行时反复计算；rgb() 参数同理，直接四舍五入到最近的 0、51、102、153、204、255 即可。
真正该关注的是 WCAG 对比度（AA/AAA）、色弱模拟（如 Chrome DevTools 的 Rendering 面板）、以及色彩空间一致性（sRGB vs display-p3）。Web Safe 是一个过时的概念，把它当成“安全”反而更危险。
