width: 100% 相对于父容器内容宽度计算，依赖包含块的 content box 宽度，易受 padding/border 和 flex 布局影响；width: 100vw 相对于视口宽度计算，含滚动条宽度，可能导致横向滚动条，适用全屏场景但需谨慎处理。
width: 100% 是相对于父容器内容宽度计算的
它依赖的是「包含块」（containing block）的 width，通常是父元素的 content box 宽度。如果父元素没设宽、或宽是 auto，那 100% 就可能失效（比如在 display: flex 的子项里，100% 有时不按预期撑开）。
常见错误现象：
- 父容器有
padding或border，但你按写的width: 800px去算50%，结果发现子元素溢出——因为实际 content width 是800px - 左右 padding - 左右 border - 嵌套多层
%宽度时，每层都基于上一层“渲染后宽度”计算，容易累积误差
使用场景：栅格布局、卡片列表、表单控件组这类需要跟随父容器缩放的结构；配合 box-sizing: border-box 能避免 padding/border 导致的超宽问题。
width: 100vw 是相对于整个浏览器窗口宽度计算的
100vw 永远等于 window.innerWidth，包括垂直滚动条占位（通常约 15px）。这意味着：当页面内容变长、触发垂直滚动条后，100vw 实际比可视区域宽，容易导致意外的横向滚动条。
立即学习“前端免费学习笔记（深入）”；
常见错误现象：
- 给
<header>或全宽轮播容器设width: 100vw，结果页面右边多出滚动条 - 父容器设置了
max-width: 1200px和overflow: hidden，子元素却用100vw，视觉上明显溢出容器边界
性能与兼容性影响：现代浏览器支持良好，但 IE 不支持；vw 值会随窗口 resize 实时重算，频繁触发 layout，若用于大量元素可能轻微影响渲染性能。
什么时候该选 100% 而不是 100vw
多数流式布局中，100% 更安全、更符合上下文预期。尤其当元素处于有明确宽度约束的容器内时——比如一个 max-width: 1140px 的 .container 里放横幅，用 width: 100% 才能真正对齐内容区，而不是硬顶到窗口右边缘。
判断依据：
- 是否需要严格对齐父容器的左右边界？→ 选
100% - 是否要突破父容器限制、覆盖整个屏幕（如模态框遮罩、全屏背景图）？→ 才考虑
100vw - 父容器是否可能因内容变化而动态缩放？→
100%自动响应，100vw无感
如何补救 100vw 引发的横向滚动问题
如果你必须用 100vw（比如设计稿强制要求“视口级宽度”），又不想被滚动条干扰，最直接的修复是减去滚动条宽度：
width: calc(100vw - 15px);
但更健壮的做法是用 CSS 自定义属性动态获取：
:root {
--scrollbar-width: 0;
}
@media (hover: none) and (pointer: coarse) {
/* 移动端通常无滚动条，可跳过 */
:root { --scrollbar-width: 0; }
}
@media (hover: hover) and (pointer: fine) {
/* 桌面端检测并设置 */
:root {
--scrollbar-width: calc(100vw - 100%);
}
}
.full-width {
width: calc(100vw - var(--scrollbar-width));
}注意：calc(100vw - 100%) 在桌面端能准确拿到滚动条宽度，但需确保父级没有干扰它的包含块逻辑（比如 html 或 body 上不要乱设 overflow）。
复杂点在于：这个差值不是固定 15px，macOS 隐藏滚动条、Windows 细 scrollbar、甚至 zoom 缩放都会改变它。真要 100% 稳定，得用 JS 读取 document.documentElement.clientWidth 和 window.innerWidth 的差值再注入 CSS 变量——但大多数项目，加个 calc(100vw - 17px) 已足够。
