width=device-width是动态适配设备CSS像素宽度，而width=375是固定值，仅在375px设备上正常，其他设备易出错；二者必须与initial-scale=1成对使用，且仅首个meta标签生效。
content 属性里 width=device-width 和 width=375 的区别
写 width=device-width 是让浏览器按设备当前 CSS 像素宽度（比如 iPhone 15 Pro 是 393px，Pixel 8 是 ~412px）来设定视口；而 width=375 是硬编码，只在恰好 375px 宽的设备上“看起来正常”，其他设备要么横向滚动，要么内容被拉伸或留白。
常见错误是开发时用 width=375 模拟 iPhone SE 调试，上线却没删——结果在 iPad 或折叠屏上直接溢出。这不是 bug，是配置和设备能力不匹配。
-
width=device-width是动态值，媒体查询、rem计算、vh高度都依赖它生效 -
width=375在横屏时必然失效（比如 iPhone 14 Pro 横屏是 852px，但视口仍卡在 375） - 某些 Android WebView 对固定 width 支持差，甚至忽略 initial-scale
initial-scale=1 必须和 width=device-width 成对出现
单独写 initial-scale=1 没用：Android Chrome 会 fallback 到默认 980px 视口，文字小得看不清；iOS Safari 可能延迟应用缩放，导致首屏渲染错乱后再抖动重排。
反过来，只写 width=device-width 不加 initial-scale=1，旧版 UC 浏览器或部分 WebView 也会退回到桌面模式渲染逻辑。
立即学习“前端免费学习笔记（深入）”；
- 二者必须同时出现在
content中，顺序无关，但建议写成width=device-width, initial-scale=1 - 不要写
initial-scale=1.0带小数点——虽然合法，但无必要，且某些老框架解析时多此一举 - 避免用 JS 动态设置，比如
document.querySelector('meta[name="viewport"]').setAttribute('content', ...)，iOS Safari 不认
user-scalable=no 是可访问性雷区，别加
显式写 user-scalable=no 或 user-scalable=0 会导致 iOS Safari 彻底禁用双指缩放，哪怕用户开了「更大字体」系统设置，页面文字也无法放大——这直接违反 WCAG 2.1 标准。
更麻烦的是：user-scalable=no 在 iOS 16+ 已部分被忽略，行为不稳定；而 maximum-scale=1 单独使用效果类似，但同样不可靠。
- 如需允许缩放（推荐），直接省略
user-scalable——它的默认值就是yes - 真要限制范围（比如 Kiosk 场景），用
minimum-scale=0.5, maximum-scale=2.0，并实机测试视力障碍用户路径 - 别信
user-scalable=0，Safari 不识别，会降级为yes，造成预期外缩放
多个 viewport meta 标签会被忽略，检查最终 HTML 源码
浏览器只读取第一个 <meta name="viewport">，后续同名标签全部丢弃。CMS、微前端、广告 SDK 都可能悄悄注入第二个，导致你写的那行完全失效。
现象往往是：本地测试正常，上线后突然不能缩放、页面横向滚动、字体变小——不是代码错了，是被覆盖了。
- 打开 DevTools → Elements 面板，确认该标签是
<head>下第一个非注释节点 - 执行
document.querySelector('meta[name="viewport"]')看content值是否为你写的原始字符串 - 服务端渲染时检查模板继承链，避免 layout 和 page 层各自输出一份
- 禁止用 JS 动态插入，它不触发重排，也不被 Safari 认可
<head> 最前面：<meta name="viewport" content="width=device-width, initial-scale=1">。其余参数全是干扰项，除非有明确兼容旧 Android WebView 的需求，否则别加。
