多数情况下优先用%，vw只在全屏响应式场景（如轮播图横幅、背景图容器）中才真正必要；%相对最近有明确宽度的父容器，vw始终相对于视口，易因父容器约束导致横向滚动或布局错乱。
容器宽度用%还是vw？看父容器是否存在滚动或缩放
直接说结论：多数情况下优先用%，vw只在全屏响应式场景（比如轮播图横幅、背景图容器）中才真正必要。因为vw基于视口宽度计算，一旦父容器有overflow: hidden或设置了max-width，它就和视觉实际宽度脱节了——你设width: 100vw，结果容器被限制在1200px宽，那100vw可能比内容区还宽，触发横向滚动。
常见错误现象：100vw导致页面意外出现水平滚动条；50%在嵌套浮动/绝对定位容器里失效，看起来“没占满”。
-
%是相对于**最近的、有明确宽度的父容器**计算的，适合常规流式布局（如三栏、卡片网格） -
vw是相对于**整个视口宽度**，不认父容器约束，适合全屏覆盖类元素（如模态框遮罩层、全宽导航） - 如果父容器用了
max-width: 1200px，子元素用width: 100%会随父容器缩放，但width: 100vw始终撑满屏幕——这常被误以为“更响应”，实则破坏布局上下文
百分比换算时，为什么子元素padding和border会让宽度“超纲”？
因为width: 50%默认只控制content box宽度，而padding和border额外加在它外面。结果就是：一个width: 50% + padding: 10px的盒子，实际占位远超50%。
使用场景：栅格系统、卡片列表、表单字段组——只要涉及内边距或边框，就必须处理盒模型。
立即学习“前端免费学习笔记（深入）”；
- 统一加
box-sizing: border-box到全局重置或容器上，这是最省心的解法 - 不用
border-box时，得手动把padding和border从百分比里扣掉，比如width: calc(50% - 20px)（假设左右padding共20px），但维护成本高 - 注意
margin不影响width计算，但它会影响兄弟元素间距，别和padding混淆
固定像素转百分比，分母到底该用谁？
不是“随便找个父容器宽度除一下”，而是必须用**该元素渲染时实际依赖的那个父容器的宽度**。这个值往往不是你写的width，而是浏览器最终计算出的渲染宽度。
常见错误现象：父容器写了width: 800px，子元素按400 / 800 = 50%写，结果父容器实际宽度是768px（因padding或border占用），子元素就溢出了。
- 用开发者工具选中父容器，看“Computed”面板里的
width值（例如768px），这才是真实分母 - 如果父容器宽度本身是百分比（比如
width: 90%），那子元素的百分比是相对于那个90%后的结果，不是原始视口 - 避免嵌套多层百分比换算——每多一层，精度误差和理解成本都翻倍；宁可加一层
max-width控制上限，再用%做弹性
移动端用vw做字体或间距，为什么有时文字小得看不见？
因为1vw = 视口宽度的1%，当用户双指放大页面（非缩放viewport，而是系统级缩放），vw单位不会跟着变大，文字就相对变小。iOS Safari对vw在缩放下的行为尤其不稳定。
使用场景：仅限于不需要用户缩放的全屏展示页（如数据大屏、营销落地页）。普通内容页慎用。
-
font-size: 4vw在iPhone上可能只有10px，阅读困难；换成clamp(16px, 4vw, 24px)能兜底，但得测试不同设备 - 用
rem配合根字体动态调整（如根据screen.width改document.documentElement.style.fontSize）比纯vw更可控 -
vw做margin/padding容易让行高、字间距失衡，尤其是中文段落，建议只用于外层容器宽度
流式布局真正的难点不在换算公式，而在你得时刻清楚每个百分比背后那个“父容器”的渲染宽度到底是多少——它可能被flex挤过，被grid切过，甚至被transform影响过。盯着Computed值看，比背公式管用。
