100vw按layout viewport宽度计算，等于window.innerWidth（含滚动条占位），而100%基于clientWidth（扣除滚动条），二者差值导致横向溢出或错位，常见于全宽banner、fixed导航和flex容器。
vw 是按 layout viewport 宽度计算，不是 clientWidth
100vw 的值等于 window.innerWidth，也就是浏览器窗口内边框总宽度（含垂直滚动条占位），而不是去掉滚动条后的可视内容宽度 document.documentElement.clientWidth。这意味着：当页面因内容变长而触发垂直滚动条时，100vw 不会缩小，但 100% 会——因为后者基于父容器内容区，自动扣除滚动条空间。两者差值通常是 15–17px，直接导致元素横向溢出或相对错位。
错位最常出现在全宽 banner、fixed 导航和 flex 并排容器中
这些场景对水平尺寸敏感，且往往同时混用 100vw 和 100%：
- 全宽背景图用
width: 100vw; left: 50%; transform: translateX(-50%)→ 滚动条出现后整体右偏 -
position: fixed; width: 100vw; top: 0的导航栏 → 在 macOS 或 iOS 上悬停滚动条瞬间“跳动” - 三列
flex: 0 0 calc(33.333% - 20px)的卡片，外层width: 100vw→ 滚动条插入后总宽度超限，末列换行
别硬塞 calc(100vw - 17px)，滚动条宽度不固定
写死 17px 是常见误区，实际值取决于系统、浏览器、缩放、甚至是否启用「隐藏滚动条」模式：
- Windows Chrome 默认约 17px，但高 DPI 屏可能为 20px
- macOS Safari overlay 滚动条悬停前为 0px，hover 后突变为 ~15px
- iOS Safari 滚动条宽度不可读，且不触发
resize事件 -
document.documentElement.offsetWidth - document.documentElement.clientWidth只在滚动条已渲染时有效，初始加载时常为 0
真正可靠的解法只有两个方向
一是让滚动条不挤内容（推荐）：
立即学习“前端免费学习笔记（深入）”；
- CSS 加
overflow-gutter: stable（Chromium 120+、Safari 17.4+ 支持），强制滚动条始终预留空间，不触发重排 - fallback 方案：给
body设padding-right: env(scrollbar-width)（仅 Firefox 支持）或 JS 动态测宽 +padding-right补偿
二是彻底避开 vw 做全宽控制：
- 用
width: 100%替代100vw，并确保父级没overflow: hidden干扰继承 - 需要“撑满窗口”的视觉效果时，改用
margin-left: -100vw; width: 200vw;配合transform: translateZ(0)触发合成，再用clip-path裁切（慎用，影响可访问性）
滚动条不是 bug，是盒模型和视口定义的必然结果；错位之所以难调试，是因为它只在内容动态变化、跨设备、跨缩放时才暴露——上线前务必在真实滚动场景下验证，而非仅看静态设计稿。
