px媒体查询在缩放时不重新计算是规范行为，因CSS像素与缩放无关；em可响应缩放和系统字号变化，更适配可访问性；rem在Safari中存在兼容缺陷，触发滞后。
px媒体查询在缩放时“卡死”是规范行为，不是bug
当你按 Ctrl + 或 Cmd + 缩放页面时，@media (max-width: 768px) 不会重新计算——它始终按初始 100% 缩放下的 CSS 像素匹配。比如缩放到 150%，视口实际宽度变成 512px（768 ÷ 1.5），但断点仍固守 768px，导致移动端样式完全不触发。
这不是浏览器实现问题，而是 CSS 规范明确规定的：px 在媒体查询中指“CSS 像素”，与渲染缩放无关。媒体查询匹配发生在 layout 阶段之前，根本不读取当前缩放比例。
实测所有主流浏览器（Chrome、Firefox、Edge、Safari）表现一致；Safari 甚至更迟钝，有时缩放后断点延迟数秒才响应。
em媒体查询能响应缩放，但依赖根字号稳定性
@media (min-width: 48em) 的计算逻辑是：取 html 元素当前计算后的 font-size 值 × 48。用户把系统字号调成 20px，48em 就是 960px；调成 12px，就变成 576px——这正是可访问性设计需要的弹性。
立即学习“前端免费学习笔记（深入）”；
但前提是 html 的 font-size 不能被 JS 动态覆盖或被 CSS 强制重设。常见坑点包括：
- 写了
html { font-size: 62.5%; }—— 这等于锁死为 10px，失去对系统字号变化的响应能力 - JS 执行了
document.documentElement.style.fontSize = '18px'—— 覆盖了用户设置，断点漂移不可控 - 用了
rem做全局单位，却误以为它也能用于媒体查询 —— Safari 对rem媒体查询有严重兼容缺陷，触发点跳变明显
为什么em比rem更适配媒体查询
Safari 在缩放时，@media (min-width: 48rem) 的触发时机异常滞后，有时比 Chrome 晚 100px 以上才生效。根源在于 Safari 把缩放后根字体大小的更新延迟到了 repaint 阶段，而媒体查询匹配发生在更早的 resize 流程里。
em 不经过根元素继承链，直接读取 html 当前计算值，在 Safari 中表现稳定得多。验证方法很简单：打开 Safari 开发者工具 → “Responsive Design Mode” → 拖动宽度 + 切换缩放，观察断点切换是否平滑。
注意：em 和 rem 在样式规则中可以共存，媒体查询用 em、布局用 rem 完全不冲突。
真正决定断点是否“有效”的，是 viewport meta 和 min-width 单向体系
光换单位没用。如果 <meta name="viewport" content="width=device-width, initial-scale=1"> 缺失或写错，或者你混用 max-width 和 min-width 断点，em 同样会失效。
推荐做法是移动优先的单向 min-width 体系，配合显式声明 html { font-size: 16px; }（不依赖 UA 默认），再用 em 写断点。这样既保可访问性，又避开了 Safari 的 rem 兼容陷阱。
最容易被忽略的一点：媒体查询里的单位不是用来“对齐设计稿像素”的，而是用来响应用户真实操作（缩放、系统字体调整）的。一旦把它当成视觉对齐工具，就会掉进 px 卡死、rem 失效、em 漂移的三重坑里。
