100vw导致横向滚动条因计算包含滚动条宽度，而width:100%基于父容器内容区；iOS Safari中vh不响应地址栏变化需JS动态同步；vmin/vmax需搭配clamp()防字体过大过小；meta viewport缺失或错误将使vw/vh基准失准。
为什么直接用 100vw 会多出横向滚动条
因为 100vw 算的是整个视口宽度，包括垂直滚动条占位（通常 16px），而 width: 100% 是相对于父容器内容区计算的。在 iOS Safari 或部分 Android 浏览器里，这会导致容器实际宽度超出视口，触发意外的横向滚动。
常见错误现象：全宽导航栏或 banner 图右侧出现空白滚动条，手指一划就“滑出去”；调试时发现元素 computed width 比 document.documentElement.clientWidth 大 16px。
- 做内容区域、卡片、文字容器时，优先用
width: 100%或flex: 1 - 只有遮罩层、全屏背景图、Canvas 画布等需要严格撑满物理视口时，才用
width: 100vw - 若必须用
vw做宽度控制，可加overflow-x: hidden在 body 上临时规避，但治标不治本
vh 在 iOS Safari 里“页面跳动”怎么 fix
iOS Safari 的 vh 单位不会响应地址栏收起/展开——用户滚动时地址栏隐藏，视口高度变大，但 CSS 中的 100vh 还是旧值，导致元素突然“上移”，视觉上像页面跳了一下。
解决方案不是放弃 vh，而是用 JS 动态同步：
立即学习“前端免费学习笔记（深入）”；
document.documentElement.style.setProperty('--vh', `${window.innerHeight * 0.01}px`);然后在 CSS 中写：height: calc(var(--vh, 1vh) * 100);
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 必须监听
resize和orientationchange，iOS 横竖屏切换也会触发视口重算 - 不要只靠
window.innerHeight初始化——首次加载时可能还没渲染完，建议加个setTimeout延迟 1 帧再取值 - 如果项目用 Vue/React，把这个逻辑封装成 hook 或 composable，避免重复写
用 vmin / vmax 控制字体大小时的典型误用
很多人写 font-size: 5vw，结果横屏时字体爆炸（比如 iPhone 横屏宽度 ≈ 812px → 5vw = 40.6px），而竖屏才 19px，阅读体验断层。
vmin 和 vmax 的价值在于“取短边”或“取长边”，不是替代 vw 的万能方案：
-
font-size: 4vmin表示“始终是视口短边的 4%”，竖屏按宽度算，横屏按高度算，更稳定 - 单独用
vmin仍可能过小（如小屏手机竖屏时320px × 568px→320 × 0.04 = 12.8px），务必搭配clamp() - 推荐写法：
font-size: clamp(14px, 4vmin, 22px)，既防太小也防太大 - IE 完全不支持
vmin/vmax，如需兼容，必须 fallback 到媒体查询 +rem
视口单位和 meta viewport 的配合关系
vw/vh 的基准是“布局视口”（layout viewport）宽度/高度，而这个值直接受 <meta name="viewport"> 影响。没设或设错，100vw 就不是你想要的“设备屏幕宽度”。
典型配置：<meta name="viewport" content="width=device-width, initial-scale=1.0">
- 缺
width=device-width：浏览器用默认 980px 布局视口 →100vw = 980px，哪怕你手机只有 375px 宽 - 只写
initial-scale=1.0不写width=device-width：某些 Android 浏览器仍可能用缩放后宽度当基准 -
maximum-scale和user-scalable=no会影响vh动态更新时机，尤其在双击缩放后，iOS 可能卡住不重算
真正要稳定的视口单位排版，meta 标签是前提，不是可选项。
