vw 是视口宽度的1%，不依赖父元素或字体大小，与%、em、rem有本质区别；需配合 clamp()、断点及兼容处理，避免小屏过小、大屏溢出等问题。
vw 单位不是“响应式布局的银弹”，它只代表视口宽度的 1%，用错地方反而会让页面在小屏上文字缩到看不清、大屏上撑爆容器。
vw 是什么，和 %、em、rem 有什么本质区别
vw 是 CSS 中的相对长度单位，1vw = 视口（window.innerWidth）宽度的 1%。它不依赖父元素宽度（不像 %），也不依赖字体大小（不像 em 或 rem），而是直接锚定整个浏览器窗口宽度。
-
%：相对于父容器的宽度，嵌套深了容易失控 -
rem：相对于根元素（html）的font-size，适合全局缩放控制 -
vw：只认window.innerWidth，哪怕父容器只有 200px 宽，50vw仍是屏幕一半
这意味着：width: 100vw 可能导致水平滚动条——因为没算垂直滚动条宽度（尤其在 Windows 上），真实可用宽度其实是 window.inner。
Width - scrollbarWidth
用 vw 做全屏背景或标题字号时的典型写法
最稳妥的场景是「视觉层」适配，比如 banner 高度铺满视口、大标题随屏幕线性缩放。但必须配合断点或限制条件，否则 iPhone SE 上 4vw 字体可能只剩 12px，而 iPad Pro 上变成 36px。
立即学习“前端免费学习笔记（深入）”；
- 全宽横幅：用
width: 100vw+margin-left: -50vw+left: 50%居中，避免滚动条干扰 - 动态字号：优先用
clamp()包裹，例如font-size: clamp(16px, 4.5vw, 32px)，既防过小也防过大 - 慎用
max-width: 100vw：它不能阻止内容溢出，真正要限制的是内部子元素的max-width
header {
height: 100vh;
width: 100vw;
margin-left: calc(-50vw + 50%);
left: 50%;
}
h1 {
font-size: clamp(1.125rem, 4.5vw, 2rem);
}vw 在移动端 Safari 和 Chrome 中的常见兼容陷阱
iOS Safari 的视口行为和 Android Chrome 不一致：Safari 在地址栏收起/展开时会触发 resize，但 vw 值不会实时重算（尤其 iOS 15+），导致横屏切换后布局错位。
- 不要单独依赖
vw控制关键布局尺寸（如导航栏高度、按钮尺寸） - 避免在
@media (orientation: landscape)中仅靠vw调整，应叠加min-height或aspect-ratio - 使用
document.documentElement.clientWidth替代window.innerWidth获取更稳定的视口宽度（排除滚动条）
另外，vw 在 iframe 内不继承父页面视口，而是按 iframe 自身宽度计算——这点常被忽略。
什么时候该放弃 vw，改用 rem + 媒体查询
当你要保证最小可读性、固定行数截断、或需要和设计稿像素对齐时，vw 就不合适了。比如卡片宽度要始终显示 3 列，每列 320px，那用 320px 或 20rem（配合根字号 JS 动态设置）比 31.25vw 更可控。
- 文字类内容（正文、列表项）优先用
rem+@media分段调整 - 动画路径、SVG viewBox、Canvas 绘图区域别用
vw，它们依赖设备像素比，vw无法反映物理分辨率 - 如果项目已用 PostCSS 插件（如
postcss-pxtorem），混入vw会导致单位转换混乱
真正难的不是怎么写 vw，而是判断哪些地方“不该”写——它只解决一个维度的问题：宽度比例映射。其他所有约束（最小字号、最大宽度、设备像素、滚动条、iframe 上下文），都得靠额外手段补足。
