100vw在Grid容器中仍按含滚动条的window.innerWidth计算，导致元素超出clientWidth引发横向滚动；应改用width:100%或calc(100vw - scrollbar宽度)补偿，且overflow-x:hidden须作用于html而非body。
100vw 在 Grid 容器中仍按含滚动条宽度计算
Grid 布局本身不改变 vw 的语义——它依然基于 window.innerWidth，也就是包含垂直滚动条的整个视口宽度。哪怕你把 display: grid 加在 body 上，100vw 子项的宽度也不会自动“避开”滚动条占位。结果就是：当页面内容触发 Y 轴滚动条（比如 Windows 下约 17px），100vw 元素实际比可用内容区宽出那几像素，浏览器只能加 X 轴滚动条来兜住溢出。
Grid 的 track sizing 不会修正 100vw 的基准偏差
很多人以为 grid-template-columns: 1fr 或 100% 能“拉齐” 100vw，但其实不是：1fr 是按可用空间分配的，而 100vw 是硬编码到视口总宽的独立值。两者基准不同，无法对齐。常见错误包括：
- 给 Grid 直接设
width: 100vw，再让子项用grid-column: 1 / -1撑满 —— 子项宽度仍继承父级的“含滚动条”基准 - 在 Grid item 内部再嵌一层
width: 100vw的 div，形成双重溢出叠加 - 用
minmax(0, 1fr)试图约束，但100vw优先级更高，不会被收缩
为什么 overflow: hidden 放在 body 上也无效？
关键点在于：滚动条是 html 根元素产生的，不是 body。如果你只写 body { overflow: hidden }，html 仍然可以撑开并触发横向滚动。必须同时控制根节点：
-
html { overflow-x: hidden }才真正阻止 X 轴滚动条生成 -
body { margin: 0; width: 100% }防止 body 自身额外边距或宽度放大 - 若用 JS 动态插入 Grid 内容，记得在插入后检查
document.documentElement.clientWidth是否等于window.innerWidth，差值就是滚动条宽度，可用来做calc(100vw - var(--scrollbar-width))补偿
替代方案：用 100% + grid-template-columns 替代 100vw
绝大多数 Grid 全宽场景根本不需要 100vw。直接用语义更稳的组合：
- Grid 容器设
width: 100%，子项用grid-column: 1 / -1或width: 100% - 需要响应式断点时，配合媒体查询调整
grid-template-columns，而不是靠vw硬撑 - 真要全屏渲染（如 Canvas、背景图），改用
position: fixed; left: 0; right: 0;，它天然贴合 clientWidth，不依赖单位计算
最麻烦的不是写错 CSS，而是某些 UI 库或框架在 JS 层动态注入了 100vw 样式，DevTools 里看到的 computed width 是最终结果，得顺藤摸瓜查 JS 注入点，而不是只盯 CSS 文件。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
