100vw会把滚动条宽度算进去导致body实际变宽，这是抖动的直接原因：因100vw基于含滚动条的视口总宽计算，而移动端（如iOS Safari）documentElement.clientWidth包含约15px滚动条占位，使body宽度超视口，触发横向滚动与松手回弹抖动。
100vw 会把滚动条宽度算进去，导致 body 实际变宽，这是抖动的直接原因
为什么 100vw 在移动端会引发左右抖动
当你写 width: 100vw 给 body 或全屏容器时，浏览器按 document.documentElement.clientWidth 计算 —— 这个值在桌面端通常不含滚动条，但在移动端（尤其是 iOS Safari）会包含滚动条占位宽度（约 15px）。结果就是：即使内容没超宽，body 宽度也变成 视口宽度 + 滚动条宽度，触发横向滚动能力，手势松手后回弹抖动。
- 真机调试时，在 Safari 开发者工具里检查
body的 computed width，常看到类似390px（而 iPhone 14 Pro 视口是 390px，说明多出了滚动条空间） -
100vw不等于100%：前者锚定视口原始尺寸，后者锚定父容器（通常是html），而html的宽度默认受body影响，形成隐式循环 - 哪怕只多出
1px，iOS WebKit 就会启用横向滚动逻辑，视觉上表现为“一松手就晃一下”
如何验证是不是 vw 引起的超宽
不用猜，用开发者工具快速定位：
- 在 Elements 面板选中
body，看右侧 Box Model 显示的Width值是否 > 当前设备视口宽度（如 iPhone SE 是 375px） - 临时加
html { overflow-x: hidden; }，如果抖动消失，基本锁定是横向溢出问题 - 给
body加outline: 1px solid red，再滑动页面，红色边框若超出屏幕边缘，说明有元素偷偷撑宽了
替代 100vw 的安全写法
不要删掉 vw，而是换一种更稳的参照方式：
立即学习“前端免费学习笔记（深入）”；
- 用
width: 100%替代width: 100vw，前提是确保html和body没被其他样式干扰（比如margin或未重置的padding） - 需要精确控制宽度时，改用
width: calc(100vw - 17px)（17px 是滚动条典型宽度），但注意不同系统/浏览器滚动条宽度不一致，仅作临时调试用 - 对全屏容器，优先用
width: 100dvw（动态视口宽度），它在 Chrome 108+ 和 Safari 16.4+ 中会自动排除滚动条占位，但需检查兼容性表，旧版 iOS 仍 fallback 到100vw
容易被忽略的连带问题
抖动很少单独存在，常和以下行为耦合：
-
position: absolute元素设置了right: 0但父容器没设overflow: hidden，它可能向右溢出 1px -
input[type="number"]在 iOS 上自带内边距，未重置时会撑宽父容器 - 图片未设
max-width: 100%，原始尺寸略大于容器，叠加100vw后雪上加霜 - 使用
vmin或vmax时误判了当前视口“最小边”，在横屏 iPad 上100vmin可能取的是高度，导致宽度失控
真正稳定的布局，不是靠一个单位兜底，而是先用 html { overflow-x: hidden } 挡住抖动表象，再逐层排查谁在悄悄加宽 —— 大多数时候，问题不在 vw，而在它被用错的地方。
