根本原因是100vw基于含滚动条的window.innerwidth计算，而实际可视宽度是已扣除滚动条的clientwidth；当y轴滚动条出现时，100vw > clientwidth导致右溢出，触发横向滚动条。
100vw 在 iPhone 上触发横向滚动条，根本原因不是 Safari 渲染 bug，而是它把垂直滚动条宽度（约 15–17px）算进了计算基准——而用户真正能看见的内容宽度，早已被系统自动扣除了这部分。
为什么 100vw 比实际可视区域宽
iPhone 的 window.innerWidth 返回值包含滚动条占位（即使滚动条是隐藏的），但 document.documentElement.clientWidth 才是真实可用内容宽度。只要页面高度超过视口、Y 轴滚动条出现，100vw > clientWidth 就成立。哪怕只多出 1px，浏览器就会渲染横向滚动条。
- 常见高危写法：
.header { width: 100vw; }、.modal-overlay { width: 100vw; left: 0; } - Tailwind 的
w-screen就是width: 100vw，同理踩坑 - 这个偏差在 DPR=2/3 设备（如 iPhone）上更敏感，小数像素四舍五入可能放大误差
overflow-x: hidden 加在 body 上为什么没用
iOS Safari 的根滚动容器是 html 元素，不是 body。给 body 加 overflow-x: hidden 对根级横向溢出完全无效，还可能干扰弹性回弹行为。
- 必须写：
html { overflow-x: hidden; } - 但仅靠这句只是压制症状：JS 动态插入内容、缩放变化、第三方组件仍可能让溢出复发
- 同时别忘了重置
body { margin: 0; }—— 默认的margin: 8px会直接贡献 16px 溢出
什么情况下真该用 100vw？怎么安全用
绝大多数“需要铺满屏幕”的场景，其实要对齐的是父容器内容区，不是物理窗口总宽。只有极少数必须锚定物理视口的场景才考虑 100vw，比如 <canvas></canvas> 初始化、某些 CSS 动画定位。
- 优先用
width: 100%替代 —— 它基于clientWidth计算，天然避开滚动条干扰 - 非用不可时，用
calc(100vw - var(--scrollbar-width))+ JS 动态注入变量，而不是硬写-17px - 现代方案可试
100dvw（自动排除滚动条），但 Safari 当前不支持 - 注意：Safari 对
right: 0和transform叠加时，更容易错误计入滚动条宽度
真正难的不是写一行 calc()，而是意识到：多数所谓“必须用 100vw”的需求，其实只是没想清楚“要对齐的是什么”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
