用 width: 100% 替代 100vw 可避免因滚动条导致的水平溢出，因其基于父元素内容区计算，天然匹配 clientWidth；而 100vw 基于含滚动条的视口总宽，易引发横向滚动。
直接用 width: 100% 替代 100vw，绝大多数场景下问题就消失了。这不是妥协，而是更准确的语义表达。
为什么 100vw 会多出水平滚动条
100vw 是按浏览器窗口“总宽度”计算的，包括垂直滚动条占位（Windows 常为 17px，macOS 隐藏时仍参与计算）。而用户实际能看见的内容区宽度是 document.documentElement.clientWidth，它已自动扣除滚动条。所以当页面有纵向滚动时：100vw > clientWidth → 元素右边缘超出可视区域 → 触发横向滚动。
- 哪怕只给一个
header设width: 100vw，也会导致整页右溢出 -
box-sizing: border-box对此无效——它不改变vw的基准定义 - 滚动条宽度不是固定值：系统设置、缩放比例、
overflow状态都会影响它
width: 100% 为什么更可靠
100% 是相对于父元素内容区（content box）计算的。只要父级是 html 或 body，且它们没额外 padding/margin，100% 就天然对齐 clientWidth，完全避开滚动条干扰。
- 适用于居中容器的全宽背景、通栏 banner、固定高度 header 等典型场景
- 不需要 JS 计算、不依赖 CSS 变量、无浏览器兼容性风险
- 如果父容器有
padding，用width: calc(100% - 2 * var(--pad))比硬减17px更安全
非用 100vw 不可时怎么处理
仅限必须严格锚定视口物理尺寸的场景（如 canvas 初始化、某些动画定位）。此时不能靠猜数字，要动态读取：
立即学习“前端免费学习笔记（深入）”；
- 在
requestAnimationFrame回调里读window.innerWidth - document.documentElement.clientWidth得到当前滚动条宽度 - CSS 中用
width: calc(100vw - var(--sb-w, 0px))，配合 JS 注入 CSS 变量 - 现代浏览器可用
100dvw（dynamic viewport width），它自动排除滚动条，但 Safari 当前不支持 -
scrollbar-gutter: stable both-edges能预留空间，但只解决“抖动”，不解决100vw本身过宽的问题
真正难的不是写一行 calc()，而是意识到：多数所谓“必须用 100vw”的需求，其实只是没想清楚“要对齐的是什么”。对齐视口物理像素？还是对齐用户可见内容区？后者才是大多数布局的真实目标。
