em断点在可访问性与缩放场景下必须使用，因其基于html字体大小动态计算，能随用户字号/缩放实时响应；而px断点固定不变，缩放时失效，违反wcag 1.4.4。
em 断点不是“推荐用”，而是“在可访问性与缩放场景下必须用”——前提是你的项目真正在意用户调整浏览器字号或系统缩放。
px 媒体查询在缩放时完全失效
当你按 Ctrl + 或 Cmd + 放大页面，@media (max-width: 768px) 不会重新计算：它始终按初始 100% 缩放下的 CSS 像素匹配。实测缩放到 150%，一个 512px 宽的视口仍被判定为 “> 768px”，移动端样式压根不触发。
这不是 bug，是规范行为——CSS 像素（px）在媒体查询中定义为设备无关的固定单位，不读取渲染时的缩放比例。
- 所有主流浏览器（Chrome/Firefox/Edge/Safari）表现一致
- 问题在阅读模式、Windows 高对比度设置、iOS 系统字体放大下同样存在
- 如果你的用户群体含视力障碍者、老年用户或教育类站点，
px断点等于主动放弃这部分人
em 断点如何动态响应字号变化
@media (min-width: 48em) 的实际宽度 = 当前 html 元素的计算字号 × 48。若用户把浏览器默认字号设为 20px，那断点就是 960px；设为 12px，就变成 576px。
这看似“不稳定”，但正是可访问性的核心逻辑：用户调大字号，布局理应更早切到单列、增大间距、避免文字溢出容器。
- 必须确保
html { font-size: 16px; }显式声明（不依赖 UA 默认，也不写62.5%这类 hack） - 绝对不要用 JS 动态改
document.documentElement.style.fontSize，否则断点会不可预测漂移 -
em在 Safari 中比rem更可靠——Safari 对rem媒体查询有已知延迟，有时断点偏移超 100px
为什么不能直接用 rem？Safari 的兼容性坑
Safari 在 resize 流程中读取根字体大小的时机晚于媒体查询匹配阶段，导致 @media (min-width: 48rem) 在缩放时触发异常：可能本该在 600px 触发，却等到 720px 才生效。
em 没这个问题，因为它直接基于当前计算后的 font-size，不经过根元素继承链，在 Safari 中表现稳定。
- 即使你全局用
rem写样式，媒体查询断点也建议统一用em，两者互不冲突 - 别被“rem 更语义化”误导——媒体查询不是样式规则，不需要继承上下文
- 验证方法：Safari 开发者工具 → Responsive Design Mode → 拖动宽度 + 切换缩放，观察断点切换是否平滑
真正决定断点是否有效的，从来不是单位本身，而是 <meta name="viewport" content="width=device-width, initial-scale=1.0"> 是否存在，以及是否采用移动优先的 min-width 单向断点体系。单位只是让这套体系在缩放和字号变化时不失效的关键一环。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
