@media中min-width与max-width混用会导致767.5px等非整数视口出现断点缝隙；断点须统一用px、按从小到大顺序书写；必须添加viewport meta标签；em/rem在媒体查询中无效。
直接说结论：@media 里用 min-width 和 max-width 不是“设个数值就完事”，边界衔接、顺序错乱、单位误用、视口缺失——这四点踩中任意一个，布局就会在某个缩放比例或设备上突然失效，而且很难复现。
为什么@media (min-width: 768px)和@media (max-width: 767px)并列会留白
看似无缝，实则在 767.5px（比如 iPad 缩放 110%）这种非整数视口宽度下，两个查询都不命中。浏览器不四舍五入，只做严格比较。min-width: 768px 要求 ≥ 768，max-width: 767px 要求 ≤ 767，中间的缝隙谁也不管。
- 永远别混用
min-width和max-width描述同一组断点逻辑 - 移动优先就只用
min-width逐级增强，基础样式写在@media外 - 桌面优先才考虑
max-width，且所有断点值必须从大到小排列（如991px→767px） - 断点值别硬抄 “iPad 是 768”，先看内容在哪撑不开/换行异常，再反推临界点
断点顺序写反了，样式会悄悄覆盖
CSS 是从上到下解析的，同优先级规则后声明者覆盖前声明者。如果你把 @media (min-width: 1024px) 写在 @media (min-width: 768px) 前面，那么在 1024px 设备上，两个都匹配，但后者定义的属性会覆盖前者没重写的部分——你改了个 padding，结果 font-size 还是旧的，调试时根本想不到是顺序问题。
- 正确顺序只能是从小到大：
@media (min-width: 320px)→@media (min-width: 768px)→@media (min-width: 1024px) - 别跳断点，比如从 320px 直接到 1024px，漏掉的区间会继承上一个
@media的全部规则 - 每个断点内只写「该尺寸下需要变更」的属性，别重复写基础层已设好的
color、font-size等
em/rem 单位在@media里基本等于废的
@media (min-width: 48em) 看起来很“响应式”，但绝大多数构建工具（Vite、Webpack、PostCSS）无法在 CSS 原生 @media 中展开变量或计算 em 值；CSS 本身也不支持 calc() 或自定义属性在媒体查询条件里生效。你写的 48em 就是字面量，不会随根字体变化而变。
立即学习“前端免费学习笔记（深入）”；
- 断点一律用
px，这是唯一被所有浏览器稳定解析的单位 -
rem和em留给元素内部样式，比如font-size或padding - 如果真要动态断点，得用 JavaScript 检测
window.innerWidth+matchMedia，而不是依赖 CSS 媒体查询
忘了 viewport meta 标签，所有断点都是空中楼阁
没有 <meta name="viewport" content="width=device-width, initial-scale=1.0">，移动端浏览器会以桌面视口（通常是 980px）渲染页面，@media (min-width: 768px) 在 iPhone 上根本不会触发——它看到的是 980px，不是 375px。
- 这个
<meta>必须放在<head>最前面，且不能被 JS 动态插入 -
user-scalable=yes可选，但width=device-width和initial-scale=1.0缺一不可 - 某些 WebView（如旧版 Electron、微信内置浏览器）对
viewport解析更严格，漏掉任意参数都可能导致断点失效
最隐蔽的坑不在代码里，而在缩放 110% 的 iPad、DPR=3 的安卓折叠屏、或者用户手动调了系统字体大小之后——这时候 px 断点依然有效，但内容挤压临界点已经偏移。所以别只测标准分辨率，缩放到 90%–125% 区间多拖几次窗口看看。
