移动端优先不是强制规范，但它是当前最可靠的响应式实施路径，核心是默认样式适配320px最小视口，通过min-width断点递进扩展，避免max-width覆盖导致的样式冲突与维护难题。
移动端优先不是强制规范，但它是当前最可靠的响应式实施路径
移动端优先（Mobile-First）在 CSS 响应式设计中不是 W3C 强制要求，也没有浏览器会因你没写 @media (min-width: 768px) 就报错。但它已成为事实标准，原因很实际：从窄到宽的断点扩展比反向覆盖更可控。
如果你先写桌面样式再用 @media (max-width: 767px) 覆盖移动端，很快会遇到样式冲突、重复声明、!important 泛滥、调试时难以追踪来源等问题——尤其在多人协作或长期迭代项目中。
移动端优先的核心是「默认样式即最小视口可用」
这意味着：body、section、button 等基础元素的默认样式必须能在 320px 宽度下可读、可点、不溢出。所有非移动端专属的布局、字体、间距都基于这个前提设定。
- 基础字体用
rem或em，配合根元素动态缩放（如html { font-size: 16px; }→@media (min-width: 768px) { html { font-size: 18px; } }） - 容器宽度默认为
100%，不设固定width: 1200px；需要居中时用max-width+margin: 0 auto - 图片默认
max-width: 100%; height: auto;，避免横向滚动 - 交互元素（如
button、a）最小尺寸至少44px × 44px，满足触控精度
断点设置要匹配真实设备行为，而非像素数字本身
常见错误是机械套用“iPhone 6 是 375px”，结果在 Chrome DevTools 的 iPhone 12 模拟器里布局错乱——因为设备像素比（dpr）、viewport 缩放、用户缩放都会影响最终渲染宽度。
真正该关注的是内容承载能力：段落是否换行过碎？导航是否还能一屏展开？卡片是否挤压到无法识别？
- 推荐起始断点：
@media (min-width: 480px)（小屏 Android / 旧 iPhone） - 主流平板断点：
@media (min-width: 768px)（iPad portrait，注意不是所有 768px 设备都是平板） - 桌面断点慎用固定值，优先考虑
@media (min-width: 992px)或@media (min-width: 1200px)，并搭配container类做内容区约束 - 避免嵌套多层媒体查询，例如不要在
@media (min-width: 768px)内再写@media (max-width: 1023px)，改用单层递进
不走移动端优先时，哪些场景可以例外？
只有三类情况可谨慎跳过移动端优先逻辑：
- 纯后台管理系统（如内部 ERP），明确限定使用 Chrome 桌面端，且无任何移动访问需求
- 遗留系统改造，原桌面样式已高度耦合，强行重构成本远超收益
- 静态展示页（如活动落地页），目标设备明确为 iPad 横屏（1024×768），且不支持缩放
即便如此，也建议保留基础响应能力：加 viewport meta、禁用用户缩放（user-scalable=no 需谨慎）、确保表单控件在 Safari iOS 下可聚焦。
真正难的不是写多少 @media，而是判断哪些样式属于「内容本质」，哪些只是「呈现偏好」——前者必须随视口变化而调整，后者才值得用断点控制。
