移动端断点应基于内容坍塌点而非固定设备尺寸，用 Chrome DevTools 拖动窗口找出真实折行/塌陷像素值，优先使用 min-width 和 px 单位，控制在三个以内并命名语义化，且必须配合 viewport meta 标签生效。
移动端断点不该设成固定设备尺寸，而应设在你的内容真正开始“撑不开”或“挤不下”的像素位置。
断点值怎么定？拖着窗口找坍塌点
别抄 768px、1024px 这类历史数值——它们来自十年前的 iPad，现在连入门安卓机都远超这个宽度。真实项目里，断点必须从你自己的布局中长出来。
- 打开 Chrome DevTools，切到「Toggle device toolbar」，拖动窗口宽度
- 观察关键节点：导航文字何时折行、卡片何时从三列塌成两列、图片容器何时失去宽高比
- 记下这些像素值，比如
480px（按钮文字开始重叠）、768px（导航栏刚好能平铺不换行）、1024px（侧边栏有足够空间展开） - 把这些值直接转成
@media (min-width: 480px)，而不是反向套设计稿标称的“iPhone 14 Pro 宽度”
为什么只用 min-width，不用 max-width？
用 @media (max-width: 767px) 写小屏规则，等于给后续所有断点埋雷：每加一个新断点，就得提高选择器特异性或加 !important 才能覆盖旧样式。
- 移动优先的本质是「默认写小屏样式，再逐级增强」，不是「先写桌面再降级」
-
@media (min-width: 768px)只追加规则，不推翻已有逻辑，浏览器层叠也更可预测 - 唯一该用
max-width的场景是窄屏例外处理，比如手表横屏@media (max-width: 320px)，但极少需要
px 还是 em？断点单位选哪个更稳？
用 px。em 断点依赖 html 的 font-size，而 WebView、系统缩放、用户字体偏好都会让它漂移——你设了 48em，实际可能在 45px 就触发了。
立即学习“前端免费学习笔记（深入）”；
- 设计稿给的是像素？那就用
px，直来直去 - 全站已锁定
html { font-size: 16px }且无任何外部干扰？那 em 才算可控 - rem 适合控制元素尺寸，
px适合控制断点，分工明确比“语义统一”更重要
断点数量多少才够用？
三个以内为佳。太多断点不等于更精细，而是让维护成本指数上升。
- 真机测试验证过的常用组合：
480px（窄屏微调）、768px（平板竖屏起始）、1024px（大屏多栏起点） - 超过
1200px后，优先用max-width限制内容区宽度，而不是新增断点适配更大屏 - 命名别用
$breakpoint-ipad，改用$breakpoint-nav-collapse——名字要告诉你“它管什么”，而不是“它想骗谁”
最常被忽略的一点：断点再准，没加 <meta name="viewport" content="width=device-width, initial-scale=1.0">，所有媒体查询在真机上都是摆设。
