移动端断点不能照搬桌面尺寸，因现代设备的视口缩放与物理像素脱钩；应基于内容溢出临界点，用 min-width 递增式增强，配合正确 viewport 设置（width=device-width），避免历史固定值和 max-width 覆盖。
移动端断点为什么不能照搬桌面尺寸
很多团队直接把 768px、1024px 这类“传统断点”复制到移动端项目里，结果在 iPhone SE 和 Pixel 7 上布局频繁错乱。根本原因不是像素值错了，而是这些数字背后没对应真实设备的视口行为和用户交互模式。
现代移动设备的 device-width 和 viewport 缩放逻辑，让物理像素和 CSS 像素早已脱钩。用固定数值硬切，等于拿尺子量一张会自动拉伸的照片。
- 优先使用
min-width+max-width组合，而不是只依赖min-width - 断点值应基于内容溢出临界点，而非设备型号列表（比如“导航栏文字开始换行”比“iPhone 14 Pro 尺寸”更可靠）
- 避免用
480px、768px这类历史遗留值——它们来自旧 iPad 的逻辑分辨率，现在连低端安卓机都远超这个宽度
怎么写真正“移动优先”的媒体查询
移动优先不是指“先写小屏样式”，而是把最小视口设为基线，用 @media (min-width: ...) 逐步增强，而不是靠 @media (max-width: ...) 不断覆盖。
错误写法：@media (max-width: 767px) { ... } —— 这会让所有后续规则都得加 !important 或更高特异性来覆盖，维护成本飙升。
立即学习“前端免费学习笔记（深入）”；
- 基础样式默认适配
320px宽度（iOS 最小安全宽度），不写任何@media - 增强时只用
@media (min-width: 480px)、@media (min-width: 640px)等递增断点 - 如果必须处理窄屏例外（如横屏手表），才用
@media (max-width: 320px)单独微调 - 慎用
em断点（如40em），它依赖根字体大小，而很多 App 内嵌 WebView 会重置font-size，导致断点失效
哪些断点值实际项目中验证过有效
没有万能断点，但有经过多端真机测试、内容承载稳定的常用区间。关键不在“精确匹配某款手机”，而在“跨设备保持同一组件的可用性边界”。
例如导航菜单：在 480px 下仍可单行显示全部文字；到了 640px 才开始加图标或折叠二级项；960px 是多数平板竖屏下网格列数从 1 切到 2 的合理位置。
-
480px：小屏手机横屏/大屏手机竖屏的文字与控件最小舒适宽度 -
640px：多数 Android 中高端机型竖屏可用宽度（含安全区） -
960px：iPad 竖屏、小尺寸安卓平板、折叠屏半开状态的常见分界 - 跳过
1200px及以上——那是桌面端的事，移动端 CSS 里不该出现
viewport meta 标签配错会让所有断点失效
再精准的断点，遇上错误的 <meta name="viewport" content="...">，也会被浏览器强制缩放或忽略媒体查询。这不是 CSS 问题，是渲染层拦截。
典型症状：max-width: 480px 规则完全不触发，控制台里 window.innerWidth 显示 980 —— 这说明页面被当成桌面站渲染了。
- 必须包含
width=device-width，否则 iOS Safari 默认按980px渲染 - 禁止写
user-scalable=no，它会禁用双指缩放，违反 WCAG，并干扰部分安卓浏览器的视口计算 - 不要设
initial-scale=1.0同时又写maximum-scale=1.0，后者在 Chrome for Android 12+ 会导致断点响应延迟 - 如果用 Web App（PWA），建议额外加
viewport-fit=cover适配刘海屏，否则env(safe-area-inset-top)无法生效
断点本身不难，难的是让浏览器老老实实按你写的宽度去解析它。viewport 配不对，后面所有 media query 都是空中楼阁。
