必须带width=device-width，否则移动端默认按980px渲染导致文字过小、布局错乱；标准写法是<meta name="viewport" content="width=device-width, initial-scale=1.0">，其中width=device-width匹配设备CSS像素宽度，initial-scale=1.0禁用初始缩放，user-scalable=no因违反WCAG可访问性规范而不推荐。
viewport meta 标签写法必须带 width=device-width
不加这句，移动端页面默认按 980px 渲染，文字小、缩放混乱，根本没法用。其他参数都是锦上添花，这一项是底线。
标准写法就这一行：
<meta name="viewport" content="width=device-width, initial-scale=1.0">
-
width=device-width：让页面宽度严格匹配设备屏幕物理宽度（不是分辨率，是 CSS 像素宽度） -
initial-scale=1.0：禁止初始缩放，避免 iOS Safari 自动放大文本 - 别写
user-scalable=no—— 屏幕阅读器、视力障碍用户会因此无法缩放，WCAG 不合规
哪些场景要加 maximum-scale 或 minimum-scale
绝大多数业务页面不需要设缩放限制。强行锁死会破坏可访问性，还可能触发 iOS 10+ 的 viewport 行为异常。
只有两类例外：
立即学习“前端免费学习笔记（深入）”；
- WebGL 或 Canvas 全屏游戏类应用，依赖固定像素尺寸，可加
maximum-scale=1.0, minimum-scale=1.0 - 内部管理系统（如 kiosk 模式投屏），明确禁止用户交互缩放，且已做无障碍替代方案
注意：maximum-scale=1.0 在 iOS 10+ 上会导致双击缩放失效，同时 input 聚焦时页面不自动缩放适配——这是 Safari 的已知 bug，不是你代码写错了。
响应式断点和 viewport 没有直接关系
很多人以为改了 content 里的 width 值就能切断点，其实完全无关。viewport 只管“画布怎么铺开”，CSS 媒体查询才管“在多宽的画布上用哪套样式”。
常见误解：
- 写成
width=375—— 这会让所有安卓机都按 375px 渲染，横屏变滚动条，iPhone SE 和 Pixel 5 显示效果天差地别 - 动态写
width=screen.width—— JavaScript 注入的 meta 标签无效，viewport 必须在 HTML 解析早期生效
真正该做的，是用 @media (min-width: 768px) 这类媒体查询控制布局，而不是折腾 viewport 的 width 值。
调试时怎么看 viewport 是否生效
别只看页面“看起来正常”，得验证底层行为：
- Chrome DevTools → 切到手机模拟模式 → 右键检查 → 查看
<head>里meta[name="viewport"]是否存在且内容没被 JS 覆盖 - iOS Safari → 设置 → 辅助功能 → 缩放开启 → 手动放大页面 → 如果页面拒绝缩放，说明
user-scalable=no或maximum-scale=1.0生效了（通常不该这样） - 真机测试时，重点看
input获焦是否触发自动缩放 —— 正常应缩放到合适字号，如果没反应，大概率是maximum-scale=1.0搞的鬼
viewport 是个极简但极敏感的开关，改一个参数可能让整个响应式逻辑失效，尤其是混合使用 rem/vw 和 media query 时，错配会导致字体忽大忽小、按钮错位——这种问题往往查半天才发现是 meta 写错了。
