断点失效主因是视口宽度≠设备物理宽度，须配；推荐移动优先用min-width；媒体查询禁用em/rem断点；js检测宽应以css类名为唯一事实源。
断点值写死在 CSS 里，为什么手机上没生效？
因为浏览器实际渲染宽度 ≠ 设备物理宽度，更不等于你直觉里的“手机是 375px”。max-width: 375px 在某些安卓机或缩放后的 iOS Safari 里根本不会触发——它匹配的是视口（viewport）宽度，而这个值受 <meta name="viewport"> 控制。没配 viewport，或者配了 user-scalable=yes 但用户双指放大过，断点就失效。
- 必须加
<meta name="viewport" content="width=device-width, initial-scale=1">，缺一不可 - 避免用设备像素比（dpr）反推视口宽度，比如把 iPhone 14 Pro Max 的 430px 当成断点依据
- 优先用主流框架的断点基准（如 Bootstrap 的
sm: 576px、md: 768px），它们经过多端实测
CSS 媒体查询里该用 min-width 还是 max-width？
取决于你采用的是移动优先还是桌面优先策略，不是“哪个更好”，而是“混用会出事”。min-width 是移动优先默认路径，所有规则从窄屏开始叠加；max-width 是桌面优先，容易漏掉中间尺寸，尤其在平板横竖屏切换时。
- 推荐统一用
@media (min-width: 768px)，配合从body { font-size: 14px }开始逐步增大 - 别在一个项目里同时写
(min-width: 768px)和(max-width: 1023px)，维护时极易覆盖错位 - 用
and组合条件时注意括号：错误写法@media (min-width: 768px) and (orientation: landscape)缺少外层括号，部分旧版 Safari 不认
用 rem 或 em 设置断点，真能响应式吗？
不能。@media 查询只支持绝对单位（px、em、rem 都行），但这里的 em 和 rem 是相对于根字体大小计算的，而根字体大小本身可能被 JS 动态修改，或受用户系统字号设置影响——导致断点触发时机飘移。
- CSS 媒体查询中的
em单位，是相对于浏览器默认字号（通常 16px），不是当前页面的html字体大小 -
rem在媒体查询中和px行为一致，但可读性差，别人一眼看不出对应多少物理宽度 - 直接写
px最稳妥，现代浏览器对像素单位的断点解析非常稳定
JavaScript 检测屏幕宽度，为什么和 CSS 断点不一致？
JS 读的是 window.innerWidth，CSS 媒体查询匹配的是布局视口（layout viewport）宽度，二者在 iOS Safari 中常差出几十像素——因为地址栏收起/展开会改变 innerWidth，但不影响 CSS 断点触发。
立即学习“前端免费学习笔记（深入）”；
- 不要用
window.matchMedia("(min-width: 768px)").matches来驱动 DOM 渲染逻辑，它和真实样式生效时机可能不同步 - 需要 JS 响应尺寸变化时，优先监听
resize并节流，而不是依赖媒体查询结果 - 若必须同步，用
window.getComputedStyle(document.body, "(min-width: 768px)").content不现实，实际应以 CSS 类名（如.is-desktop）为唯一事实源，JS 只读取 class 状态
断点不是数值游戏，是视口、缩放、UA、甚至用户手势共同作用的结果。最常被忽略的，是没在真机上横竖屏反复切三次以上验证。
