平板上vw基于980px计算是因为layout viewport初始化失败，典型原因包括漏写viewport meta、js动态插入过晚、安卓webview横屏fallback及第三方sdk覆盖；需验证clientwidth与innerwidth差异并强制重置meta或监听orientationchange触发resize。
因为部分平板（尤其是安卓厂商定制系统）的 layout viewport 宽度被浏览器错误设为 980px 或 1024px，而非设备真实 CSS 像素宽度，导致 1vw 实际等于 9.8px 或 10.24px，远超设计稿预期（如按 768px 设计时，1vw 应为 7.68px）。
为什么平板上 vw 会基于 980px 计算
这不是浏览器不支持 vw，而是 layout viewport 初始化失败。典型场景包括：
- 漏写或写错
<meta name="viewport" content="width=device-width, initial-scale=1.0">—— 尤其是误写成width=768或漏掉initial-scale=1.0 - 页面加载时 JS 动态插入了 viewport meta，但浏览器已在解析 CSS 阶段完成了 layout viewport 锁定
- 某些安卓 WebView（如旧版华为/小米浏览器）在横屏首次加载时仍沿用桌面 fallback 宽度（980px）
- 第三方 SDK（如统计、广告脚本）悄悄覆盖了 viewport meta
vw 在平板上偏大的典型表现
你看到的不是“字体变大”，而是所有 vw 单位元素整体膨胀，比如：
- 一个写成
width: 100vw的 banner，右侧明显溢出屏幕，滚动条意外出现 - 按钮高度设为
48vw，在 1024×600 平板上实际高达 491px（1024 × 48% ≈ 491），远超预期的 368px（768 × 48%） - 文字行高用
line-height: 6vw，结果在横屏下撑开整页，内容被截断 - DevTools 中
Computed面板显示width: 1024px，但window.innerWidth返回的是 768 —— 这说明 layout viewport 和 visual viewport 已脱节
如何快速验证并修复
别猜，先看真实值：
- 在平板上打开控制台，执行
console.log(document.documentElement.clientWidth, window.innerWidth)；若前者是 980 / 1024，后者是 768 / 800，就确认是 layout viewport 错位 - 检查 HTML 源码，确保 viewport meta 是首行标签之一，且未被 JS 覆盖；可加
console.log(document.querySelector('meta[name=viewport]').content)验证 - 临时加一行强制重置：
document.querySelector('meta[name=viewport]').setAttribute('content', 'width=device-width, initial-scale=1.0')，放在末尾或DOMContentLoaded回调里 - 对关键容器降级：用
@supports (width: 100vw) { ... }包裹 vw 样式，同时提供width: 100%fallback
最易被忽略的一点：部分平板在横竖屏切换后不会自动刷新 layout viewport，哪怕 meta 正确。必须监听 orientationchange 并手动触发一次 window.dispatchEvent(new Event('resize'))，否则 vw 值卡在旧尺寸上不动。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
