移动端页面缩放失控主因是viewport meta标签未生效：必须置于head最前、唯一且含width=device-width与initial-scale=1.0绑定；禁用user-scalable=no违反无障碍标准；Retina屏需动态计算scale并配合CSS补偿。
移动端页面缩放失控，不是 viewport 写得不对，就是它根本没生效。 最简可用配置是 <meta name="viewport" content="width=device-width, initial-scale=1.0">，但光贴这行代码不等于万事大吉——位置错、被覆盖、内容溢出，都会让 initial-scale=1.0 形同虚设。
viewport meta 标签必须放在 最前面
浏览器解析到它就立即锁定视口行为，晚了可能已经按默认 980px 宽度渲染并缩放了一次。常见错误包括：
- 标签塞在
里，完全无效 - 被 CMS、框架（如 Next.js 的
next/head）或 JS 动态插入，iOS Safari 直接忽略 - 页面中存在多个
name="viewport"标签，只认第一个，后面全丢弃
用 Chrome DevTools 的「View page source」确认源码里是否真有且唯一、位置靠前。
initial-scale=1.0 单独写没用，必须配 width=device-width
这两个参数是绑定生效的：width=device-width 告诉浏览器“按设备逻辑宽度（如 iPhone 13 是 390px）来设视口”，initial-scale=1.0 才能据此算出 1:1 缩放。否则：
- 只写
initial-scale=1.0：浏览器仍用默认 980px 视口，再强行缩放到 1 倍，文字糊、按钮小 - 只写
width=1200这类固定值：小屏上强制拉伸，大屏上留白，响应式断点（如@media (max-width: 768px)）直接失效
别信“写了 initial-scale 就不会缩放”——如果页面里有个 min-width: 1200px 的容器，iOS Safari 会无视 initial-scale 强制缩小以显示全部内容。
user-scalable=no 是高危配置，慎用
它禁用双指缩放、长按放大，也破坏 iOS「更大字体」等系统级辅助功能，WCAG 无障碍标准明确反对。真实场景中：
- 电商/新闻类页面：必须保留缩放，用户要看清图片细节或小字说明
- 表单页/登录页：禁用后，输入框聚焦时键盘弹出导致布局挤压，用户无法手动调整视图
- 若真要防误操作（如游戏 HUD），优先用 CSS 控制交互区域，而非一刀切禁缩放
更稳妥的做法是设 minimum-scale=0.5, maximum-scale=2.0，既限制极端缩放，又保留基本可访问性。
DPR 高清屏适配需额外处理
Retina 屏（window.devicePixelRatio === 2）下，1 个 CSS 像素对应 2×2 物理像素，直接设 initial-scale=1.0 会导致文字/边框发虚。此时需动态计算：
const dpr = window.devicePixelRatio || 1;
const scale = 1 / dpr;
document.querySelector('meta[name="viewport"]').setAttribute(
'content',
`width=device-width, initial-scale=${scale}, maximum-scale=${scale}, user-scalable=no`
);
document.documentElement.setAttribute('data-dpr', dpr);
注意：这段 JS 必须在 中尽早执行（比如 inline script），否则页面已按默认规则渲染完毕，再改 viewport 也来不及重绘。同时，CSS 中要用 [data-dpr="2"] .border { transform: scale(0.5); } 等方式补偿缩放带来的尺寸偏差。
真正卡住人的从来不是怎么写那行 meta，而是写完之后没验证它是否真的控制了渲染起点——打开 DevTools 设备模拟器，看 Network → HTML 响应体里有没有它，再切到 Elements 面板确认它是否在 顶部，最后用 Toggle device toolbar 截图比对实际渲染宽度和设备逻辑宽度是否一致。
