标准 viewport content 必须包含 width=device-width、initial-scale=1、user-scalable=yes 三项；禁用 maximum-scale/minimum-scale 以保障可访问性；配合 rem/em、max-width:100%、响应式布局才能真正适配多端。

viewport 的 content 值必须写全，缺一不可

移动端页面不缩放、文字不模糊、布局不溢出，核心就靠 这一行。只写 width=device-width 是常见错误——它会让 iOS Safari 默认按 100% 缩放，但无视用户双指缩放意愿；只写 initial-scale=1 则在某些安卓浏览器里可能忽略设备宽度计算，导致横向滚动。

标准写法必须包含三项基础参数：

• width=device-width：让视口宽度匹配设备物理像素宽度（经 dpr 换算后）
• initial-scale=1：页面加载时以 1:1 比例渲染，不放大也不缩小
• user-scalable=no 或 user-scalable=yes：显式声明是否允许手动缩放（多数业务需保留缩放）

推荐默认配置：

禁止使用 maximum-scale 和 minimum-scale

这两个参数看似能“锁死”缩放，实则破坏可访问性，且在 iOS 13+ 中已被 Safari 部分忽略。更严重的是，当用户开启系统「更大字体」或「辅助缩放」时，maximum-scale=1 会直接禁用这些系统级适配能力，导致文字被截断、按钮点不到。

立即学习“前端免费学习笔记（深入）”；

真实场景中，以下写法应立即删除：

除非你明确服务于 kiosk 设备（如自助终端），否则不要加 maximum-scale 或 minimum-scale。WCAG 2.1 和 iOS/Android 官方指南均要求保留用户缩放控制权。

响应式布局下，width=device-width 不等于「完美适配」

这个值只是起点，不是终点。它告诉浏览器“按设备宽度来设视口”，但实际渲染效果还取决于 CSS 单位选择、字体单位、图片尺寸策略：

• 用 rem 或 em 替代固定 px 字体大小，否则 initial-scale=1 下小屏字体会过小
• 图片必须加 max-width: 100%; height: auto;，否则超出视口宽度引发横向滚动
• 避免写死容器宽度如 width: 375px，应改用 width: 100vw 或媒体查询 + flex 布局

一个典型反例：

.header { width: 375px; margin: 0 auto; }

调试 viewport 问题，优先检查控制台报错和设备模拟器行为差异

Chrome DevTools 的「Toggle device toolbar」仅模拟 viewport 尺寸，不模拟真实 dpr 和缩放逻辑。真机测试时常见现象包括：

• iOS 微信内嵌 WebView 忽略 user-scalable=yes，强制禁用缩放（这是微信限制，非代码问题）
• 部分国产安卓浏览器（如 QQ 浏览器旧版）把 initial-scale=1 解析为「缩放到内容刚好填满屏幕」，导致字体异常放大
• 控制台出现 [Intervention] Unable to preventDefault inside passive event listener，往往是因为监听了 touchstart 却没加 { passive: false }，间接影响 touch 缩放响应

验证是否生效：打开 Chrome DevTools → 「Application」→ 「Manifest」→ 查看「Viewport settings」解析结果；真机测试务必覆盖 iOS Safari、微信、Chrome Android 三端。

viewport 配置本身很简单，难的是它和 CSS 渲染、JS 事件、第三方 SDK 的耦合。很多「适配失败」其实不是 content 写错了，而是后续样式没跟上缩放后的计算逻辑。