硬编码px媒体查询损害可访问性，因其无视用户字体缩放偏好，导致200%缩放下布局错乱、文字裁切，违反WCAG 1.4.4；应改用em单位（如768px→48em），基于浏览器默认字号16px换算，并用整数em值+余量兜底确保兼容性。
硬编码像素值（如 768px）在媒体查询中会绕过用户设置的字体缩放偏好，导致部分视障用户或高倍缩放场景下布局错乱、文字被裁切甚至功能不可用——这不是 bug，是设计缺陷。
媒体查询里写 768px 为什么损害可访问性
浏览器的“字体大小缩放”（比如在设置里把默认字号调成 20px）只影响相对单位（em、rem、%），但对 px 完全免疫。当用户依赖放大文本阅读时，@media (min-width: 768px) 仍按物理像素触发，而此时视口实际能容纳的内容已远少于预期，侧边栏被挤出、按钮重叠、文字溢出容器就成常态。
更关键的是：WCAG 1.4.4（调整文本尺寸）明确要求界面在 200% 缩放下仍可操作。硬编码 px 的断点会让这个目标失效。
- 用户将浏览器默认字号设为 20px → 页面所有
1rem变成 20px，但@media (min-width: 768px)还是卡死在 768 物理像素 - 移动端 Safari 某些版本在「显示缩放」开启后，
px媒体查询会误判视口宽度，触发错误断点 - Windows 高对比度模式 + 缩放组合下，
px断点常早于内容实际换行点触发
怎么把 px 媒体查询安全换成 em
核心原则：用 em 替代 px 时，数值不是简单除以 16。必须基于当前根元素 font-size 计算——因为 1em = 当前元素的字体大小，而媒体查询里的 em 是相对于浏览器默认字号（通常是 16px）。
立即学习“前端免费学习笔记（深入）”；
所以 768px → 48em（768 ÷ 16 = 48），1024px → 64em，以此类推。
- 不要写
@media (min-width: 48em)后再动态改html { font-size: 20px }—— 这会让1em变成 20px，断点实际变成 960px，彻底失控 - 推荐统一用
rem媒体查询？不行。CSS 规范至今不支持@media (min-width: 48rem)，只有em被广泛实现 - 如果项目已用
html { font-size: 62.5% }（即 10px），那768px应转为76.8em，而非48em—— 务必确认基准
真实项目中容易漏掉的兼容细节
不是换了 em 就万事大吉。旧版 Safari（14.5 之前）、某些 Android WebView 会对 em 媒体查询做四舍五入或截断，比如 48.2em 可能被当成 48em 处理。
- 始终用整数
em值（48em而非48.125em），避免浮点误差 - 在关键断点（如
48em）上下各留 0.1em 余量：@media (min-width: 47.9em) and (max-width: 48.1em)做兜底检测 - 测试时打开系统「粗体文本」+「更大字体」+「显示缩放」三重组合，观察断点是否准时触发
- 别依赖 DevTools 的「设备模拟」——它不模拟系统级字体缩放，必须真机验证
真正麻烦的从来不是把 768px 换成 48em，而是整个团队是否理解：媒体查询的单位选择，本质是在决定「谁控制响应时机」——是开发者写的死数字，还是用户可调节的阅读环境。
