width=device-width 是强制起点，不写则 initial-scale=1.0 基本无效；它定义动态 CSS 像素宽度，与 initial-scale 共同决定布局视口宽度，且 viewport 必须置于 head 中静态声明。
width=device-width 不是可选项，是强制起点
不写 width=device-width，initial-scale=1.0 基本等于没写。iOS Safari 会 fallback 到约 980px 的桌面视口宽度，再整体缩小渲染，文字糊、按钮小、点击飘；部分安卓 WebView 则可能无视 initial-scale，直接横向滚动。
硬写具体数值（比如 width=375 或 width=414）更危险：折叠屏横屏时 device-width 变成 824px，你却锁死 375，内容被严重压缩；Chrome DevTools 模拟器里也会错乱。它不是物理像素，而是经 DPR 换算后的 CSS 像素宽度，只能由设备动态报告。
常见误判点：
-
width=320：看似兼容老 iPhone，实则在 Pixel 7（412px）上强制拉伸，字体发虚 -
width=1200：退化为平板桌面模式，小屏手机必须左右拖拽 - 完全不写
width：依赖浏览器默认行为，iOS 和 UC 浏览器表现不一致
initial-scale=1.0 的真实作用是“阻止意外缩放”
initial-scale=1.0 不是让页面“显示为 1:1”，而是关掉 iOS Safari 的自动放大逻辑：当页面里有小于 16px 的文本且未声明该参数时，它会偷偷放大整个视口来提升可读性——结果是布局错位、表单失焦、按钮变小。
立即学习“前端免费学习笔记（深入）”；
但它非常脆弱，一碰就失效：
- 页面里有个
width: 1200px的容器 → 浏览器宁可忽略initial-scale也要把它塞进屏幕 -
white-space: nowrap或浮动未清除 → 父容器被撑开，内容宽度 > 视口 → 强制缩放触发 - 漏了
width=device-width→initial-scale失去计算基准，多数浏览器直接无视
注意：initial-scale=1.0 在桌面 Chrome 中完全不生效，只对移动端浏览器有意义。
width 和 initial-scale 的乘法关系决定实际视口宽度
布局视口宽度 = width 值 ÷ initial-scale。这个公式比死记配置更有用，尤其在调试溢出或留白异常时：
-
width=device-width, initial-scale=1.0→ 视口宽度 ≈ 设备 CSS 宽度（如 iPhone 14 是 390px），推荐 -
width=320, initial-scale=0.5→ 视口宽度 = 640px，内容被缩小，适合做缩略预览 -
width=768, initial-scale=1.5→ 视口宽度 = 512px，强制窄视口，慎用
如果你发现页面横向滚动条藏不住，先算算这两个值的除法结果是否匹配你预期的视口宽度——别急着改 CSS，先看 meta 标签本身有没有被框架覆盖或重复写入。
user-scalable=no 和 maximum-scale=1.0 应该删掉
user-scalable=no 在 iOS 13+ 基本无效，Android 行为不一致；而 maximum-scale=1.0 会直接禁用系统级「更大字体」和辅助缩放，违反 WCAG 可访问性要求，苹果也明确不推荐。
真正需要的是可控缩放：
- 业务场景允许用户缩放（绝大多数情况）→ 只保留
width=device-width, initial-scale=1.0 - 自助终端等特殊设备 → 才考虑加
user-scalable=no，但需确认无障碍替代方案 - 绝对不要混用
maximum-scale=1.0和user-scalable=no，它们叠加后会让 initial-scale 更容易被绕过
viewport 标签必须放在 <head> 里，且不能靠 JS 动态插入；Vue/React SSR 模板中也要确保服务端已吐出——中间任何一次错误渲染，都可能让用户看到一秒的模糊缩放态。
