移动端页面缩放、文字小、布局错乱大概率是 viewport meta 标签设置不当：必须置于 最前面，内容推荐 width=device-width, initial-scale=1，避免冗余参数或错误组合。
移动端页面不缩放、文字太小、布局错乱？大概率是 name="viewport" 设置不对，而不是 CSS 或 JS 的问题。
viewport meta 标签写在哪才生效
必须放在 里，且越靠前越好——最好紧贴 开始标签。浏览器解析 HTML 是从上到下，如果它先渲染了一部分页面再读到 viewport，那初始缩放已经错了，后续补救成本高。
- ✅ 正确位置：
- ❌ 错误位置：放在
里、或在/<script></script>之后才写 - ⚠️ 注意：多个 viewport meta 标签会以第一个为准，后面的被忽略（Chrome、Safari 均如此）
content 属性常见值组合与实际效果
content 不是“越全越好”，不同组合直接影响 iOS Safari、Android Chrome 对页面的初始渲染逻辑。关键参数只有三个： width、initial-scale、user-scalable，其他如 minimum-scale 多数场景反而是干扰项。
-
width=device-width：让视口宽度等于设备物理像素宽度除以 devicePixelRatio（即“CSS 像素宽度”），这是响应式布局的基础。不写它，iOS 默认按 980px 渲染，文字小得没法读 -
initial-scale=1：强制初始缩放为 1:1。但注意：如果同时设了width=375（比如硬编码 iPhone SE 宽度），再配initial-scale=1，会导致横屏时内容被截断 -
user-scalable=no：禁用双指缩放。现在基本不建议加——不仅影响可访问性（WCAG 不合规），iOS 15+ 在某些情况下会直接忽略它
为什么加了 viewport 还是缩放异常
常见原因不是 meta 写错了，而是被其他逻辑覆盖或触发了平台特殊行为：
- iOS Safari 在页面加载完成前，可能根据
内容宽度临时调整视口（尤其含大图或未设 max-width 的 div），导致 initial-scale 生效延迟 - 某些 UI 框架（如早期版本的 Ionic、Framework7）会在 JS 中动态重写 viewport meta，和你写的冲突
- WebView 场景（如微信内置浏览器、Flutter Webview）可能忽略
user-scalable，但对width和initial-scale更敏感 - 错误示例：
content="width=320, initial-scale=1.5"—— 这会让 320px 宽的内容强行放大 1.5 倍，在 iPhone 14 Pro 上实际渲染宽度变成 480px，溢出屏幕
适配高 DPR 设备的隐含前提
name="viewport" 本身不处理像素比（DPR），但它决定了 CSS 像素如何映射到物理像素。真正起作用的是：viewport 设置 + CSS device-pixel-ratio 媒体查询 + 图片 srcset 配合。
- 没有
width=device-width，@media (-webkit-min-device-pixel-ratio: 2)可能匹配失败（因为视口宽度不是设备逻辑宽度） - 如果你用
rem基于document.documentElement.clientWidth动态设置根字号，这个 clientWidth 就依赖 viewport 的 width 解析结果 - 真机调试时，用 Safari 的「开发 → [设备名] → [页面]」查看实际 viewport width 和 scale 值，比模拟器更可靠
viewport 不是“写上就完事”的开关，它是浏览器渲染管线里最早介入的尺寸契约——一旦定错，后面所有 CSS 布局、JS 测量、图片加载都跟着偏移。最稳妥的做法，就是只用 width=device-width, initial-scale=1，其余参数除非有明确业务理由，否则别碰。
