viewport meta标签必须置于<head>最开头，且content中必须同时包含width=device-width和initial-scale=1，缺一不可，否则移动端将按980px默认视口渲染，导致文字过小、布局错乱、媒体查询失效。
必须写在 <head> 最开头，且至少包含 width=device-width 和 initial-scale=1 —— 缺一不可，否则移动端大概率按 980px 渲染，文字小、布局错、媒体查询不触发。
viewport meta 标签必须放哪儿才生效
浏览器是顺序解析 HTML 的，<meta name="viewport"> 必须紧贴 <head> 开始标签，不能被 SSR 注释、框架占位符、其他 <meta> 或 <link> 挤到后面。
常见失效场景：
- 写在
<body>里 —— 完全无效 - 动态插入（比如
document.head.appendChild()或innerHTML +=）—— iOS Safari 和 Chrome 都不认 - 多个 viewport 标签共存 —— 只有第一个生效，后面的被忽略
- 被服务端渲染时的注释或条件块包裹 —— 解析器跳过，等同于没写
content 属性里哪些值真正起作用
不是参数越多越保险，冗余或矛盾的组合反而导致行为异常。核心只靠三个参数协同：
立即学习“前端免费学习笔记（深入）”；
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
-
width=device-width：让 layout viewport 宽度 = 设备 CSS 像素宽度（如 iPhone 14 是 390px）。不写它，iOS 默认用 980px，字体直接缩成针尖大小 -
initial-scale=1：强制初始缩放为 1:1。注意：如果width写死成width=375，再配initial-scale=1，横屏时内容会被裁剪 -
user-scalable=no：现代浏览器已弱化支持 —— iOS 13.4+ 和 Chrome 90+ 会静默忽略仅此一项；必须搭配minimum-scale=1.0和maximum-scale=1.0才可能生效，但依然不推荐
反例：initial-scale=0 或 maximum-scale=0 是无效写法，浏览器会忽略或降级处理。
为什么写了 viewport 还是缩放/文字变大
两种高频但不同源的问题：
-
input 聚焦放大：iOS Safari 在聚焦小于 16px 的
<input>或<textarea>时，会强制放大整个视口 —— 这和viewport设置完全无关，是系统级行为。解法是确保font-size ≥ 16px，或给input加style="font-size: 16px;" -
双指仍可缩放：iOS Safari 主动绕过限制 —— 只要
document.documentElement.scrollHeight > window.innerHeight（即内容超出一屏），就会启用双指缩放以保障可访问性。这不是 bug，是 Apple 强制设计。加html, body { overflow: hidden; }能堵住，但会锁死所有滚动，轮播图、弹窗全失效
兜底拦截缩放只能靠 JS，但 passive 是关键
当 viewport 失效或需精细控制时，唯一可靠方式是监听手势源头：
- 监听
document.documentElement（不是body），避免 iframe 或子容器干扰 - 双指缩放：监听
touchstart，判断e.touches.length > 1，然后e.preventDefault() - 双击放大：监听
touchend，缓存时间戳，两次间隔 ≤ 300ms 就e.preventDefault() - 必须传
{ passive: false }—— 现代浏览器默认开启 passive event listener，{ passive: true }下e.preventDefault()会被静默忽略
真正难的不是写几行 JS，而是理解：viewport 是声明式配置，它只管“初始渲染”，而用户交互产生的缩放是运行时行为 —— 两者不在同一层，混用容易互相覆盖或失效。
