100vw按window.innerWidth计算，包含滚动条宽度，加padding后必溢出；box-sizing:border-box仅防padding叠加溢出，不解决100vw本身比可用内容区宽的根本问题。
100vw 本身已包含滚动条宽度，再加 padding 就必然溢出
100vw 的计算基准是 window.innerWidth，它明确包含垂直滚动条的像素宽度（Windows 常为 17px，macOS 显示时约 15px）。当你给一个 width: 100vw 的容器再加 padding: 20px，浏览器按 box-sizing: content-box（默认）渲染：实际占用宽度 = 100vw + 40px。哪怕父容器是 html 或 body，这个总和也稳稳突破视口，触发横向滚动条。
- 用
$$('body')[0].scrollWidth - window.innerWidth在控制台运行，结果 > 1 就基本锁定是这类叠加溢出 - 开发者工具中检查该元素的「Computed」面板，确认
box-sizing确实是content-box，且最终width值明显大于window.innerWidth - 别只盯着子元素——父容器如
body自身若有margin: 8px（浏览器默认），也会让 100vw 元素额外 +16px
为什么 box-sizing: border-box 不能完全解决问题？
box-sizing: border-box 能把 padding 和 border 收进 width 计算，但它不改变 100vw 的源头问题：100vw 本身比可用内容区宽。假设滚动条占 17px，width: 100vw 实际就是「可视区宽 + 17px」，此时即使设了 box-sizing: border-box，padding 不再额外加宽，但整个容器仍比真实内容区宽 17px——依然会撑出横向滚动条。
- 验证方法：临时删掉所有
padding和border，如果横向滚动条还在，说明根源就是 100vw + 滚动条宽度 -
box-sizing: border-box是必要条件，但不是充分条件；它防的是「padding 加 width 叠加溢出」，不是「100vw 天然溢出」 - 全局加
* { box-sizing: border-box; }仍需配合单位选择，否则只是把问题从「明显溢出」变成「隐蔽错位」
真正安全的替代方案：用 100% + 动态补偿
对绝大多数布局场景（全屏 banner、页脚、导航栏），width: 100% 才是更鲁棒的选择，因为它基于父容器的内容区宽度计算，天然避开滚动条占位干扰。若必须依赖视口像素级精度（比如 Canvas 渲染、背景渐变锚点），就该用 JS 动态读取真实可用宽度：
const scrollbarWidth = window.innerWidth - document.documentElement.clientWidth;
document.documentElement.style.setProperty('--scrollbar-w', `${scrollbarWidth}px`);然后在 CSS 中写：width: calc(100vw - var(--scrollbar-w));。注意 calc() 在 transform 中的兼容性较弱，但用于 width 属性在现代浏览器中已稳定支持。
立即学习“前端免费学习笔记（深入）”；
-
100%在html/body上表现稳定，前提是它们没被意外设min-width或width - 避免在
body上直接写width: 100vw—— 它和垂直滚动条存在根本性冲突 - 移动端尤其要警惕：iOS Safari 在键盘弹出时
100vw不更新，但视口可视区域缩窄，right: 0类定位会直接“消失”
最容易被忽略的连锁反应点
横向滚动条常不是单点错误，而是多个默认行为叠加的结果：浏览器给 body 设了 margin: 8px，你用了 100vw，又忘了重置 box-sizing，再加上某个 ::before 伪元素没设 max-width: 100%，图片原始尺寸硬撑……每个单独看都像“应该没问题”，合起来却稳稳触发 scrollWidth > innerWidth。排查时别只盯一个元素，先运行 $$('body')[0].scrollWidth - window.innerWidth 确认是否为定位/盒模型问题，再用 DevTools 的 Elements 面板搜索 [style*="right"]、[style*="left"] 快速筛出可疑 fixed/absolute 元素。
