@media (min-width: 48em) 不恒等于768px，其实际像素值取决于html根元素的font-size；若根字号为16px则等于768px，若为20px则为960px，媒体查询中的em仅以html的font-size为基准，与继承无关。
移动端媒体查询里写 @media (min-width: 48em)，它真等于 768px 吗？不等于。这个值取决于当前 html 元素的 font-size，而浏览器默认是 16px —— 但这个“默认”在实际项目中极易被覆盖或忽略，导致断点漂移。
em 在媒体查询中到底以谁为基准？
媒体查询里的 em 单位，**只看根元素（html）的 font-size 值**，和任何父级、子级、CSS 继承都无关。它不是动态继承的 em，而是静态取根字号计算的。
- 如果没做任何重置，Chrome/Firefox/Edge 默认
html { font-size: 16px; }→ 那么48em = 768px - 如果你写了
html { font-size: 20px; }→48em就变成960px - 如果用 JS 动态改了
document.documentElement.style.fontSize→ 媒体查询会立刻按新值重算 - Safari 对
rem媒体查询有延迟 bug，但对em是稳定的，所以推荐用em而非rem
为什么你写的 48em 断点“没生效”？
常见现象：页面缩放到 125%，视口实际宽度只剩 614px，但 @media (max-width: 768px) 还是不触发 —— 因为 px 媒体查询根本不响应缩放；而你本意想用 em，却忘了检查根字号是否还是 16px。
- JS 框架（如 Vue CLI、Next.js 默认 CSS 重置）可能悄悄把
html的font-size改成100%或1rem，结果依赖 UA 默认值的行为就失效了 - 写了
html { font-size: 62.5%; }这类 hack，表面看是锁死 10px，实则破坏可访问性：用户调大系统字号时，断点不会提前响应 - 开发工具里看到 computed
font-size是 16px，不代表媒体查询就按这个算——得确认是html元素自身的font-size，不是继承来的
怎么验证当前 em 断点的实际像素值？
别靠脑算，直接查。打开 DevTools，在 Console 里执行：
立即学习“前端免费学习笔记（深入）”；
getComputedStyle(document.documentElement).fontSize
返回类似 "16px" 或 "20px"，再乘以你的 em 数即可。例如返回 "18px"，那 @media (min-width: 30em) 实际就是 540px。
- 不要用
window.getComputedStyle(document.body)—— body 的字号可能被改过，且媒体查询不认 body - 避免在 CSS 里写
html { font-size: clamp(16px, 1rem, 20px); }——rem在媒体查询里会出问题，clamp 本身也不参与媒体查询计算 - 上线前建议加一行防御性 CSS：
html { font-size: 16px; }，显式声明，不赌 UA 行为
真正容易被忽略的不是“1em 等于多少 px”，而是“谁在决定这个 1em”。媒体查询里的 em 只读 html 的 font-size，而且这个值一旦被 JS 或 CSS 意外修改，所有断点都会偏移——连 Safari 都没法救你。
