viewport标签是渲染模式切换器，它通过初始化layout viewport宽度（如iphone 13的390px）和缩放比例（1.0）来确保css媒体查询、rem基准、js尺寸获取及300ms点击延迟消除等正确生效。
viewport 标签不是样式开关，而是渲染模式切换器
它不控制字体大小或元素位置，而是直接干预浏览器的 layout viewport 初始化逻辑。没这个标签，iOS Safari 和 Android WebView 默认以 980px 宽度解析 HTML，所有后续 CSS 都在这个错误基线上计算——哪怕你写了 width: 100%，实际也是 100% × 980px，不是设备宽度。
一旦 layout viewport 错了，@media (max-width: 768px) 就永远不触发，1rem 的基准也跟着错位，JS 获取的 window.innerWidth 返回的是 980，不是 390 或 414。
- 浏览器只在首次解析
时读取<meta name="viewport">，之后动态插入无效 - 多个同名 meta 并存时，仅第一个生效，其余被丢弃
- 哪怕只多一个空格或注释挡在它前面，某些安卓 WebView 就会跳过识别
content="width=device-width, initial-scale=1.0" 是唯一可靠组合
加 maximum-scale=1.0 或 user-scalable=no 不是“更严格”，而是主动放弃 WCAG 2.1 合规性：iOS 系统级「更大字体」设置失效，输入框双击放大被禁，视障用户无法缩放阅读。
width=device-width 告诉浏览器用设备逻辑像素宽度（比如 iPhone 13 是 390px），initial-scale=1.0 强制按 1:1 渲染，二者缺一不可。单独写前者，老 iOS 可能 fallback 到 980；单独写后者，部分安卓 WebView 忽略 width 设置，文字仍小得看不清。
- 别用
width=375—— Pixel 7 是 412px，iPad mini 是 768px，硬写等于放弃响应式 -
target-densitydpi=device-dpi是 Android 2.3 遗留参数，现代浏览器已忽略 - 实测 2026 年主流机型（iOS 17+、Chrome 125+、Samsung Internet 24+）均稳定支持该最小组合
写了 viewport 还横向滚动？真凶在 CSS 流式破坏
viewport 只管“画布铺多宽”，不管“内容有没有撑破”。常见溢出源头不是 meta 写错，而是：
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
-
width: 100vw+padding或border→ 实际宽度 = 100vw + padding × 2 + border × 2 - 某个
<div> 写了 <code>width: 375px，在 412px 屏上直接溢出 -
<img>没设max-width: 100%且没配height: auto，原始尺寸大于容器 - 用了
transform: scale()或某些 UI 库内部重置了 layout viewport
全局兜底建议：img, video, table { max-width: 100%; height: auto; }，再检查所有 width 值是否都用了 %、rem 或 vw。
300ms 点击延迟消失的底层机制
这不是 JS 优化能解决的问题。移动浏览器默认启用双击缩放检测：touchend 后等待 300–350ms，判断是否为 double-tap。只有 width=device-width, initial-scale=1.0 被识别，浏览器才启用 ideal viewport，并关闭该延迟检测逻辑，click 事件立即派发。
验证很简单：删掉该 meta → 手机点按钮 → 明显卡顿；加回 → 延迟即刻消失。Chrome 自 2013 年起就依赖此机制，但前提是标签存在、位置正确、content 合法。
最容易被忽略的是：哪怕 content 值完全正确，只要它不在 最开头（比如被 SSR 注释或 <script></script> 挤到第二位），iOS Safari 就不会启用 ideal viewport，300ms 延迟照旧。
