应使用 max-width: 769px 替代 768px 断点以兼容 768.5px 等小数宽度，同时避免混用 em/rem、确保 min-width: 0 和 flex-wrap 正确应用，并在真机上测试非整数窗口宽度。
媒体查询断点没覆盖到 768.5px 这种小数宽度怎么办
浏览器真会拿小数像素搞事情，尤其是缩放后或某些平板设备，window.innerWidth 返回 768.5 这种值，而你的 @media (max-width: 768px) 就直接失效了。
别硬凑整数断点——CSS 媒体查询对小数宽度完全支持，关键是写法要对：
- 用
max-width: 768.5px没问题，但得确保没有其他更高优先级规则覆盖它 - 更稳妥的做法是改用
max-width: 769px，留出安全余量（毕竟768.5px仍 ≤769px） - 避免混用
em或rem断点做精确像素控制，换算误差会让小数问题更隐蔽
viewport meta 标签在 iOS Safari 里缩放后布局错乱
<meta name="viewport" content="width=device-width, initial-scale=1"> 是基础，但 iOS Safari 缩放时会偷偷重算 device-width，导致媒体查询“以为”屏幕变小了。
真实场景下必须加约束：
立即学习“前端免费学习笔记（深入）”；
- 补上
maximum-scale=1和user-scalable=no（仅限 WebApp 类场景，普通网页慎用） - 如果允许缩放，就别依赖
device-width做关键布局判断，改用min-width/max-width配合vh/vmin单位 - 检查是否启用了
text-size-adjust: 100%，iOS 字体缩放会触发重排，干扰响应式断点触发时机
flex-wrap 在窄屏下内容溢出却没换行
常见于卡片列表或标签组，明明写了 flex-wrap: wrap，但在某些 375px–414px 区间就是不折行，一查发现子元素设置了 min-width: 0 或 flex-shrink: 0。
根本原因是 flex 项的固有尺寸未被正确压缩：
- 给子元素加
min-width: 0是必要操作，尤其当它内部有长单词或 URL 时 - 避免对 flex 项设
width: 100%或固定px宽度，优先用flex: 1或flex: 0 1 auto - 测试时手动拖拽浏览器窗口到非整数宽度（比如 392.3px），观察是否仍有溢出——这比只测标准尺寸更暴露问题
vw 单位在 Android Chrome 里渲染偏移半像素
width: 50vw 在某些 Android 设备上会差 0.5px，左右 margin 不对称，border 看起来虚、模糊，甚至触发横向滚动条。
这不是 bug，是 subpixel 渲染和 DPR 对齐的副作用：
- 用
calc(50vw - 0.5px)强制对齐几乎没用，不同设备 DPR 不同 - 更可靠的是换用
flex或grid布局替代纯vw定宽，让浏览器自己做像素对齐 - 若必须用
vw，搭配transform: translateZ(0)或will-change: transform可触发硬件加速，减少模糊感
边缘情况从来不是“偶尔出现”，而是你没在真机上连着 devtools 把窗口拖到小数宽度多试几次。那些没报错、没警告、只是“看起来不太对”的瞬间，才是响应式收尾最该盯住的地方。
