viewport 应设 width=device-width 且 initial-scale=1，二者协同确保 1 CSS 像素≈1设备独立像素；硬设固定 width（如375）需同步 initial-scale=1，但易致横屏溢出；禁用缩放应避免 user-scalable=no，优先用 CSS 方案。
viewport meta 标签的 width 和 initial-scale 怎么配？
直接在 index.html 的 <head> 里加 <meta name="viewport" content="...">，就能控制手机端缩放。关键不是单独设 initial-scale，而是它和 width 必须协同——比如设 width=375 却没配 initial-scale=1，iOS Safari 可能仍按默认 980px 渲染，页面被“缩小”显示。
-
width=device-width是最常用且推荐的写法，表示视口宽度 = 设备逻辑像素宽（如 iPhone 14 是 390px），此时initial-scale=1才真正让 1 CSS 像素 ≈ 1 设备独立像素 - 如果硬要固定宽度（比如强制按 375px 渲染），得同时写
width=375, initial-scale=1，但会导致横屏时内容溢出，且安卓部分浏览器会忽略width数值而回退到device-width -
maximum-scale或user-scalable=no会禁用双指缩放，影响可访问性，多数场景不该加
为什么加了 viewport 还是缩放异常？
常见原因是其他地方覆盖或冲突。比如：
- 第三方 UI 库（如某些旧版 Bootstrap）自带 viewport 标签，重复插入导致行为不可控
- Webpack/Vite 构建时通过插件自动注入 viewport，和你手写的叠加，优先级可能出问题
- iOS Safari 在 URL 含锚点（
#section）时偶发重置缩放，需配合window.scrollTo(0, 0)强制修正 - 页面有固定
font-size或transform: scale()的容器，视觉上像缩放，实则与 viewport 无关
initial-scale=1 在不同设备上的实际表现差异
initial-scale=1 并不等于“1:1 显示”，它只表示初始缩放比例为 1，最终渲染尺寸还取决于设备像素比（DPR）。例如：
- iPhone 13（DPR=3）：1px CSS 宽度实际占 3 物理像素，文字清晰；但若误设
initial-scale=0.5，内容会变大且模糊 - 部分安卓中低端机（DPR=1.5 或 2）：
initial-scale=1下字体可能偏小，需配合text-size-adjust: 100%防止系统自动放大文本 - Chrome Android 某些版本对
initial-scale解析较松，若width缺失，可能无视initial-scale
要不要用 JavaScript 动态设置 initial-scale？
不要。动态写 <meta> 标签（比如用 document.querySelector('meta[name=viewport]').setAttribute(...)）在 iOS 上基本无效——Safari 只在首屏解析阶段读取 viewport，后续修改不触发重排。
立即学习“前端免费学习笔记（深入）”；
- 真有响应式缩放需求（如阅读模式切换），应改用 CSS
transform: scale()+transform-origin控制局部区域 - 检测 DPR 后调整根元素
font-size（即 rem 方案），比动 viewport 更稳定 - 想禁止缩放？用
user-scalable=no不可靠，且 WCAG 不合规；更稳妥的是监听touchmove并preventDefault，但仅限明确交互场景
width=device-width，配上 initial-scale=1。其余参数加得越多，越容易在某个机型或系统版本上翻车。 
