根本原因是100vw包含滚动条宽度（约17px），而Bootstrap的.container定制宽度（如1200px）未预留滚动条余量，叠加媒体查询断点未同步调整，导致100vw元素实际宽度超过可用内容区，触发横向溢出。
100vw 在 Bootstrap 页面里为什么会撑出横向滚动条
根本原因不是 100vw 本身错了，而是它和 Bootstrap 的 .container 宽度策略、滚动条占用空间、以及媒体查询断点三者叠加后“算不准”了。
比如你写了 width: 100vw 的元素在视口宽度为 1200px 的设备上渲染，但此时页面 Y 轴有滚动条（占约 16–17px），真实可用宽度其实是 ~1183px。而你的 .container 若被定制为固定 1200px（如 UI 稿要求），就会比实际视口宽——100vw 拿到的是“屏幕物理宽度”，.container 却按“无滚动条时的宽度”设计，二者错位直接触发 X 轴溢出。
- Bootstrap 默认媒体查询临界点（如
min-width: 1200px）是按“无滚动条宽度”设定的，但100vw不管这个 - 如果你用
100vw做全屏背景、横幅或覆盖层，它会严格铺满整个 viewport，包括被滚动条挤占的那部分；而.container内容却在更窄的空间里排版，视觉上就“左边对齐、右边多出一截” - DevTools 里看
body的 computed width，常会发现它 > viewport width —— 这就是100vw元素 + 容器错位共同导致的
.container 宽度定制后，100vw 和媒体查询怎么对不上
Bootstrap 的 .container 类本身是一组带断点的媒体查询规则，例如：
@media (min-width: 1200px) {
.container {
max-width: 1170px; /* 默认值 */
}
}当你把 max-width: 1170px 改成 1200px，但没同步调整 @media 的断点（比如仍用 min-width: 1200px），就等于让容器在“刚好够显示滚动条的临界宽度”下强行拉满，结果就是：滚动条一出现，100vw 元素就比 .container 多出十几像素，浏览器只能加横向滚动条来“兜住”这个差值。
立即学习“前端免费学习笔记（深入）”；
- 不要把
.container的max-width和媒体查询断点设成相同数值（如都用1200px） - 若必须用
1200px容器，建议把断点上调到1220px或下调容器为1180px，留出滚动条余量 - 临时验证：在 DevTools 中手动把
html的overflow-y设为scroll，看横向滚动是否立刻出现 —— 是的话，基本锁定是这个宽度冲突
用 100vw 做全宽组件时，怎么绕开 container 的干扰
最稳妥的方式不是硬调 100vw，而是让全宽元素脱离 .container 流式上下文，用结构隔离代替宽度硬算。
- 把全宽区块（如 banner、footer）写在
.container外层，和.container并列，而不是包在里面 - 如果必须嵌套（比如 CMS 动态插入），给该元素加
position: relative; width: 100%; left: 50%; right: 50%; margin-left: -50vw; margin-right: -50vw;—— 这能强制居中并拉满，且不依赖100vw的绝对值 - 或者改用
width: 100%; max-width: 100vw;双保险：既保持流式，又防止超宽 - 避免在
.container内部任何地方使用100vw，尤其别用在.row或.col上 —— 它们本就靠负边距和 padding 配合，再叠100vw就是火上浇油
为什么 overflow-x: hidden 治标不治本
给 body 加 overflow-x: hidden 确实能藏掉滚动条，但它只是“遮眼睛”，没解决内容真正溢出的问题。用户缩放页面、切到小屏、或打开开发者工具时，依然可能暴露错位，且会干扰 focus 等行为（比如 modal 打开时焦点跳转异常）。
-
overflow-x: hidden对position: fixed元素无效，这类元素仍可能凭空撑宽 - 如果页面有
transform、will-change或iframe，隐藏 X 轴滚动还可能引发渲染层错乱 - 真正要盯的是结构层级：谁用了
100vw、谁定制了.container、谁在 media query 断点上“卡得太紧”——这三者只要有一个没对齐，100vw就会变成溢出导火索
