viewport 设置必须加，否则移动端默认缩放会毁掉所有适配努力；正确写法为 。
viewport 设置必须加，否则移动端默认缩放会毁掉所有适配努力
很多开发者以为写了 rem 或 flex 就万事大吉，结果在 iOS Safari 或安卓 Chrome 里字体忽大忽小、布局错位——根本原因是没加或写错了 。不加这行，移动端浏览器会按桌面宽度（通常是 980px）渲染页面，再整体缩放显示，导致 1px 实际物理像素被拉伸，vh 计算失准，媒体查询失效。
正确写法只有一条核心：
-
width=device-width是关键，它让视口宽度 = 设备逻辑像素宽（比如 iPhone 14 的 390px），不是固定 980px -
initial-scale=1.0禁止初始缩放，避免双击放大等干扰 -
user-scalable=no在生产环境建议加上，防止用户误操作破坏布局（尤其表单页） - 不要写
minimum-scale或shrink-to-fit=yes（Safari 已废弃）
CSS 单位选 rem 还是 vw/vh？看场景别硬套
rem 和 vw 都能响应式，但行为完全不同：前者依赖根字体大小（html 的 font-size），后者直接基于视口尺寸。混用或误判会导致字体突然跳变、按钮在小屏上缩成点、大屏上撑满整屏。
推荐组合：
立即学习“前端免费学习笔记（深入）”；
- 字号、内边距、圆角等「视觉节奏类」属性，用
rem+ 动态设置html字体（例如 JS 根据document.documentElement.clientWidth计算） - 全宽容器、高度占满视口、横幅图等「结构性」尺寸，用
vw/vh，比如width: 100vw、height: 80vh - 绝对禁止用
px写字体大小或间距——iOS Safari 的「动态字体大小」设置会让px文字强制放大，破坏布局
媒体查询断点别按设备型号写，按内容撑不开时再切
写 @media (max-width: 768px) 适配 iPad、(max-width: 414px) 适配 iPhone X ——这种做法早该淘汰了。真实问题是：当容器宽度缩小到某个值，文字换行难看、卡片挤成一列太窄、导航栏图标重叠……这些才是断点依据。
实操建议：
- 从桌面端开始写 CSS，用
min-width递进（如@media (min-width: 768px)），符合渐进增强逻辑 - 断点数值用常见内容宽度反推：比如卡片宽度 320px 时刚好两列变一列，就设
640px（两列总宽 + 间隙） - 避免嵌套多层媒体查询，优先用
clamp()替代简单线性变化，例如：font-size: clamp(14px, 4vw, 18px); - 测试时用 Chrome DevTools 的「Device Toolbar」切换尺寸，但最终必须真机验证——某些安卓 WebView 对
clamp()支持滞后
iOS 和安卓的 input 表单样式差异大，得单独处理
同一个 ，在 iOS 上默认带圆角、阴影、浅灰背景；安卓原生浏览器可能无边框、光标粗细不一、focus 时放大整个页面——这些不是 bug，是系统级 UI 规范差异，靠 reset.css 基本无效。
关键控制点：
- 统一禁用系统默认外观：
appearance: none; -webkit-appearance: none;（后者专治 Safari） - 手动补圆角和边框：
border-radius: 6px; border: 1px solid #ddd; - 解决 iOS focus 放大问题：在
加，并确保 input 没有font-size （iOS 会强制放大） - 安卓软键盘顶起页面时，
vh会按原始视口计算，导致底部按钮被盖住——改用calc(100dvh - 60px)（dvh是动态视口单位，Chrome 105+ / Safari 16.4+ 支持）
实际跨平台样式一致性的难点不在代码量，而在每个平台对「标准」的理解偏差——比如 Safari 把 100vh 当作未弹出键盘时的高度，而部分安卓 WebView 直接忽略 scroll-behavior: smooth。这些细节没法靠一套通用方案兜底，必须按目标平台做最小化覆盖。
