100vw会让页面变宽出现水平滚动条，因为其按含滚动条的视口总宽度计算，导致内容区加滚动条宽度超过可视区域；可靠方案是用width:100%替代，并确保父容器无padding/margin。
100vw为什么会让页面变宽出现水平滚动条
因为 100vw 是按视口（viewport）**总宽度**计算的，包括滚动条占位 —— 浏览器把滚动条算进视口内，但滚动条本身又占据页面右侧空间，导致内容实际宽度超过可视区域，触发水平溢出。
常见现象：width: 100vw 的全屏 banner 或 header 在 Windows / 某些 macOS 设置下右侧多出滚动条，用户能左右拖动，但视觉上完全不需要。
- Windows 默认显示常驻滚动条，占约 17px；此时
100vw≈ 屏幕宽度，但内容区 + 滚动条 > 可视宽度 - macOS 默认隐藏滚动条，但 DOM 计算时仍按“存在滚动条”来算
vw值（Chrome/Firefox 行为一致） -
box-sizing: border-box不影响这个问题 —— 它只管 padding/border 是否计入 width，不改变vw的基准定义
用 calc(100vw - 17px) 可靠吗
不可靠。硬写 17px 是典型“修表面”的做法：滚动条宽度不是固定值，它随系统设置、浏览器缩放、甚至 overflow 状态动态变化。
比如用户开了“细滚动条”、用了高 DPI 缩放（125%）、或页面局部 overflow: overlay，这个差值就不是 17px。
立即学习“前端免费学习笔记（深入）”；
- 滚动条宽度无法通过 CSS 直接读取，
getComputedStyle查不到 - JS 可以间接计算：用
document.documentElement.clientWidth和window.innerWidth差值得到当前滚动条宽度，但必须在布局稳定后读（如requestAnimationFrame回调里） - 若用
calc(100vw - 17px)，在无滚动条的设备（如 iPad Safari）会人为缩窄，造成左右留白
真正安全的全宽方案：用 width: 100% 替代 100vw
只要容器本身没有 padding/margin 干扰，width: 100% 会严格贴合父容器内容区，天然避开滚动条侵占问题。
适用场景：全屏 banner、背景色块、模态框遮罩层等需要“撑满可视区宽度但不溢出”的地方。
- 父容器需是
html或body，且确保它们没设padding或margin（重置常用：body { margin: 0; }） - 若父容器有
padding，100%会包含它 —— 此时改用width: calc(100% - var(--pad))更可控 - 注意
position: fixed元素用100%时，参考的是 viewport，行为接近100vw，仍可能溢出；此时应显式设left: 0; right: 0;
需要精确视口尺寸时，优先用 JS 动态获取
CSS 的 vw/vh 是声明式、静态的，而真实可用视口宽高是运行时确定的。真要对齐“无滚动条的可视宽度”，就得换 JS。
例如实现一个自适应 canvas 尺寸、或做视口内居中裁剪布局：
function getUsableViewportWidth() {
return document.documentElement.clientWidth;
}
// clientWidth 不含滚动条，是真实可用宽度
// innerWidth 含滚动条，等于 100vw 的物理像素值-
clientWidth/clientHeight是最接近设计意图的指标：它代表元素内容区大小，对document.documentElement来说就是“去掉滚动条后的可视宽度” - 监听
resize时别直接用innerWidth做判断 —— 它在滚动条出现/消失瞬间会跳变，造成布局抖动 - 现代方案可结合
@container查询（需父容器设container-type: size），但目前对根容器支持有限，暂不替代 JS
滚动条带来的宽度偏差，本质是浏览器把“布局上下文”和“用户可见区域”混在了一起。想绕过它，就得放弃用 CSS 硬算，转而信任 clientWidth 这个更诚实的数字 —— 它不承诺“全屏”，但保证“不溢出”。
