prefers-contrast 媒体查询用于检测系统级高对比度设置，非屏幕类型识别；需显式声明CSS响应，JS动态改font-weight无效，且color-contrast()函数尚未被主流浏览器支持。
如何用 prefers-contrast 媒体查询区分高对比度模式
系统级高对比度模式（如 Windows 高对比主题、macOS 的“增加对比度”）会覆盖网页默认颜色，但不会自动改写你的 CSS；必须显式监听 prefers-contrast 才能响应。它不是“检测屏幕类型”，而是检测用户是否启用了系统级对比度增强设置。
常见错误是把它和 prefers-color-scheme 混用，或以为它能识别 OLED/IPS 屏幕差异——它完全不能。
-
prefers-contrast: high：用户开启高对比主题（此时浏览器会禁用背景图、强制使用系统色板） -
prefers-contrast: low：极少见，某些辅助设置下触发，多数浏览器不支持 - 未匹配时按普通样式渲染，不会 fallback 到深色/浅色模式
/* 正确写法：叠加判断 */
@media (prefers-color-scheme: dark) and (prefers-contrast: high) {
body { color: <code>#ffffff</code>; background-color: <code>#000000</code>; }
}
@media (prefers-contrast: high) {
/* 单独适配高对比：确保文字与背景有硬性色差 */
* { text-shadow: none !important; }
a, button { outline: 2px solid <code>#000000</code> !important; }
}为什么不能靠 window.matchMedia 动态切换字体粗细来提升可读性
有人试图在 JS 中监听 prefers-contrast 变化后，用 element.style.fontWeight = 'bold' 强行加粗文字——这反而破坏可访问性。高对比模式下，系统已接管文本渲染逻辑，JS 修改的 fontWeight 会被忽略，或导致文字模糊、重影。
真正起效的是 CSS 中声明的 font-weight，且必须配合足够大的 font-size 和明确的 color/background-color 对比。
立即学习“前端免费学习笔记（深入）”；
- 高对比模式下，
font-weight值必须是具体数字（如700），避免用bold这类关键字 - 字号建议 ≥
16px，小字号加粗后边缘锯齿更明显 - 禁用
opacity或半透明色值，它们在高对比下常被渲染为纯黑/纯白，丢失层次
color-contrast() 函数在实际项目中基本不可用
CSS color-contrast() 是 Level 5 规范草案，截至 2024 年底，Chrome、Firefox、Safari 均未实现。你查 MDN 看到的示例代码，在任何主流浏览器里都会静默失效。
想做对比度校验，只能靠构建时工具（如 axe-core、stylelint-a11y）或手动用 WCAG 公式计算：(L1 + 0.05) / (L2 + 0.05)，其中 L1、L2 是两种颜色的相对亮度。
- AA 级要求文本对比度 ≥ 4.5:1（正常大小文字）
- AAA 级要求 ≥ 7:1，但对浅灰文字（如
#999）几乎无法达标 - 别信在线“对比度检测工具”的 RGB 输入——它们常忽略 sRGB 转换，结果偏乐观
移动端 Safari 对 prefers-contrast 的兼容陷阱
iOS 17+ 才开始支持 prefers-contrast，且仅限于“设置 > 辅助功能 > 显示与文字大小 > 高对比度”开启时生效。它不响应“智能反转”或“经典反转”——这两个选项走的是另一套渲染路径，CSS 无权干预。
更麻烦的是：Safari 在高对比模式下会强制将 background-color: transparent 渲染为纯黑，哪怕父容器有背景图。这不是 bug，是设计行为。
- 必须为所有可能透明的元素显式声明
background-color - 避免用
rgba(0,0,0,0.1)模拟浅灰背景——高对比下它会塌缩成#000000 - 测试真机，模拟器无法触发真实高对比渲染链
高对比度优化的核心不是“让文字更醒目”，而是“不让系统接管时丢掉控制权”。最易被忽略的一点：按钮的 :focus-visible 样式必须在 prefers-contrast: high 下额外强化边框，否则键盘用户根本看不到焦点在哪。
