viewport meta 标签必须置于 <head> 内且越靠前越好，动态插入或放于 <body> 中无效；仅允许一个，重复时以首个为准；initial-scale=1.0 需配合 width=device-width 使用，否则可能被忽略；禁用 user-scalable=no 以保障可访问性；始终用 width=device-width 而非固定值。
viewport meta 标签写在哪才生效
必须放在 <head> 里，且越靠前越好——浏览器解析到它就立即应用缩放规则，晚了可能已触发默认缩放或重排。如果被 JS 动态插入、或塞在 <body> 里，viewport 完全无效。
常见错误现象：width=device-width 写了但页面还是宽出屏幕，大概率是标签位置错了，或者被其他同名 meta 覆盖（比如 CMS 自动生成了第二个 viewport）。
- 只允许一个
viewportmeta，重复声明时以第一个为准 - 不要用 JS 修改
content属性来“动态适配”，iOS Safari 会忽略运行时变更 - Next.js / Vue CLI 等框架通常通过
next/head或vue-meta注入，确认 SSR 渲染后源码里确实存在该标签
initial-scale=1.0 为什么有时没用
不是写了就一定锁定为 1:1 缩放。iOS Safari 在页面内容宽度超过视口时，会强制缩小以显示全部内容，此时 initial-scale=1.0 被无视——本质是浏览器优先保证“可读性”而非“声明”。
根本原因在于：你设了 initial-scale=1.0，但没控制页面内容本身不溢出。比如一个固定宽 1200px 的 div，在 iPhone 上无论如何 initial-scale 都救不了。
立即学习“前端免费学习笔记（深入）”；
- 必须配合
width=device-width使用，单独写initial-scale没意义 - 检查是否有未重置的
min-width、white-space: nowrap或浮动元素撑开父容器 - 用 Chrome DevTools 的「Toggle device toolbar」+ 「Capture screenshot」看真实渲染宽度，别只信 CSS 声明
user-scalable=no 是个危险配置
加了它，用户双指缩放、长按放大、甚至部分辅助功能（如 iOS 的「更大字体」设置）都会失效。苹果官方明确不推荐，WCAG 也视为可访问性违规。
真实使用场景极少：只有 Kiosk 模式下的专用设备、或嵌入 WebView 且业务强控交互的 App 内页。普通网站加这个，等于主动放弃残障用户和部分老年用户。
- Android Chrome 已逐步弱化对
user-scalable=no的支持，某些版本直接忽略 - 如果是为了防止误触缩放，优先用
touch-action: manipulation代替 - 测试时务必关掉「缩放辅助」开关（iOS 设置 → 辅助功能 → 显示与文字大小 → 更大字体），看是否真影响阅读
viewport 内容宽度值怎么选：device-width 还是 375
一律用 width=device-width，别硬写具体数值（比如 width=375）。后者在折叠屏、平板横屏、Chrome 模拟器不同 DPR 下会彻底错乱。
device-width 是逻辑像素宽度（CSS pixels），由系统根据设备物理分辨率 + 缩放比例实时计算，这才是响应式的基础。写死数值相当于把响应式退化成静态切图。
- 例外情况：仅限于微信内嵌 WebView 的某些旧版本（iOS 12 以下），需用
width=375+ JS 动态修正，但现在基本不用考虑 - 注意：Safari 在「放大文本」开启时，
device-width会变小（比如从 375 变成 320），这是正常行为，说明你的布局得用相对单位（rem/vw）而非固定 px - 用
window.innerWidth打印实际值验证，比猜更可靠
最常被忽略的点：viewport 只管初始渲染，后续所有缩放行为都由用户和系统接管。你没法用它“锁死”尺寸，能做的只是给浏览器一个靠谱的起点。
