断点应基于设计稿容器实际宽度设定，而非设备型号；推荐用min-width按升序（如0→768px→1024px）渐进增强，避免max-width重叠与性能损耗，并确保viewport正确配置。
断点不是设备尺寸表，而是内容开始“撑不开”或“挤不下”的临界宽度——直接看设计稿容器宽度，用 min-width 从窄到宽递增写，别抄网上“标准值”。
断点该设在多少像素？看容器，不看手机型号
设计稿里主内容区宽度是 768px？那就用 @media (min-width: 768px)。导航栏在 1024px 宽度下刚好能横排三列？那就加 @media (min-width: 1024px)。真实项目里，断点失效往往是因为用了 iPhone SE、iPad Pro 这类具体设备的“典型值”，而用户实际用的是折叠屏展开态（>1200px）或高缩放比浏览器（视口宽度被压缩）。
- 320px：仅用于极简修正（比如小屏下隐藏非核心图标），别在这儿写整套布局
- 480px：适合调按钮间距、行高、字体大小，不是“手机起点”
- 768px：多数平板竖屏最小宽度，也是导航切换、卡片列数变化的常见坍塌点
- 1024px：iPad 横屏或小桌面起点，适合开启侧边栏、多栏网格
- 超 1200px 后慎加断点，优先用
max-width限制内容区宽度，而非适配更大屏
为什么必须用 min-width 而不是 max-width
max-width 是降级逻辑：默认按桌面渲染，再一层层覆盖小屏样式。结果是小屏设备要下载、解析全部 CSS，白耗带宽；后续断点容易因特异性冲突失效；改一处得同步检查所有 max-width 块。而 min-width 天然符合渐进增强——小屏只加载基础样式，大屏额外加载增强规则。
-
min-width断点必须严格升序排列，否则后写的可能被前写的同权重规则覆盖（CSS 层叠只认顺序，不认“逻辑先后”） - 别混用单位：
@media (min-width: 48em) and (max-width: 768px)是危险组合，em会随用户字号缩放偏移，px更可控 - 设计师给的是像素值？媒体查询就用
px，别为“语义正确”牺牲可预测性
断点写在哪？位置影响层叠和维护成本
媒体查询块如果写在 CSS 文件开头，容易被后面未包裹的同类选择器覆盖；如果每个组件都重复写一遍相同断点（比如每个卡片组件都写 @media (min-width: 768px)），后期改断点就得全局搜索替换。
立即学习“前端免费学习笔记（深入）”；
- 统一把媒体查询写在文件末尾，且按移动优先组织：先写基础样式，再集中写
min-width增强块 - 避免嵌套在组件内部，除非该组件有完全独立的响应逻辑（如一个只在桌面显示的仪表盘控件）
- 别用
@import或外链多个响应式 CSS 文件——增加 HTTP 请求，拖慢首屏
最易被忽略的一点：viewport 配置错误会让所有断点失效。确保 <meta name="viewport" content="width=device-width, initial-scale=1"> 存在且没被 JS 动态覆盖；真机测试时别只看 Chrome DevTools 的模拟尺寸，要连真机调试，观察缩放、横竖屏切换、折叠屏展开态下的实际触发点。
