viewport 必须硬编码在 <head> 最前面且仅写一次，content 值只能是 width=device-width, initial-scale=1.0，缺一不可；禁止添加缩放限制参数，否则损害可访问性；CSS 溢出仍是常见真凶，需配合流式布局修复。
viewport 必须硬编码在 最前面
浏览器解析 HTML 时，<meta name="viewport"> 是最早读取的元信息之一。一旦 layout viewport 按默认 980px 初始化完成，后续任何 JS 操作都无法重置它。
常见错误包括：
- 用
document.head.appendChild()动态插入 —— iOS Safari 和多数安卓 WebView 直接忽略 - 放在
<body>里或<head>靠后位置 —— 渲染已开始，标签失效 - SSR 模板漏传，客户端 JS 补不上 —— 页面首次渲染就错，补救无效
- Vue/React 中被
<client-only>或服务端条件逻辑包裹 —— 实际 HTML 不含该标签
正确做法：紧贴 <meta charset> 后、<head> 内最靠前处，只写一次。
content 值只能是 width=device-width, initial-scale=1.0
这是唯一被所有现代移动端浏览器认可的最小有效组合。缺一不可，多一个参数都可能破坏行为。
立即学习“前端免费学习笔记（深入）”；
为什么必须配对：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 只写
width=device-width：iOS Safari 仍可能以 980px 渲染再缩放，文字模糊、touch 坐标偏移 - 只写
initial-scale=1.0：某些安卓 WebView 忽略设备宽度，导致横向滚动或内容被压缩 - 写死
width=375或width=1200：折叠屏横屏、iPad、Chrome DevTools 模拟器下直接崩
device-width 是设备报告的 CSS 逻辑像素宽度（如 iPhone 15 是 393px），不是物理像素，也不受 DPR 影响 —— 它由浏览器内核决定，硬编码数值毫无意义。
别加 user-scalable=no、maximum-scale=1 等限制参数
这些参数看似“防误触”，实则带来三类问题：
- iOS 13+ 已基本无视
user-scalable=no，但会触发输入框强制放大 bug -
maximum-scale=1.0禁用系统级「更大字体」和辅助缩放，违反 WCAG 可访问性要求 -
user-scalable=no, maximum-scale=1.0, minimum-scale=1.0连用 = 锁死所有缩放能力，老年用户和视障用户无法使用
合理替代方案：touch-action: manipulation 控制手势区域，或用 CSS 限定特定容器可缩放。Kiosk 场景除外，但需 native 层配合接管缩放。
写了 viewport 还出问题？真凶大概率在 CSS
<meta name="viewport"> 只是开关，不解决布局溢出。它能防止浏览器主动缩放，但拦不住你写的代码撑破视口。
典型溢出原因：
-
width: 100vw+padding或border→ 实际宽度 > 100%，触发横向滚动 - 某个
<div>写了固定width: 375px→ 在 Pixel 7（逻辑宽 412px）或 iPad（834px）上直接溢出 -
<img>没设max-width: 100%且没配height: auto→ 原始尺寸撑开父容器
全局兜底建议：img, video, table { max-width: 100%; height: auto; }。viewport 设置再准，也救不了破坏流式布局的代码。
