vw/vh 是响应式单位（视口宽高的1%），比固定px更适配多屏，但需配合viewport设置、媒体查询断点及rem/em用于正文，避免滥用导致小屏过小或大屏溢出。
用 vw 和 vh 替代固定像素值
直接改 px 值无法响应分辨率变化，浏览器不会自动缩放。真正起效的是视口单位：vw（视口宽度的 1%）和 vh（视口高度的 1%）。比如 font-size: 4vw 在 1920px 宽屏幕上是 76.8px，在 375px 宽手机上约 15px，天然适配。
常见错误是滥用 vw 导致小屏文字过小、大屏溢出。建议只对标题、卡片宽高、间距等非文本主体用，正文仍用 rem 或 em 配合根字体缩放。
- 避免给
body设font-size: 2vw—— 这会让所有rem计算失控 - 慎用
100vw：它包含滚动条宽度，可能触发横向滚动条；改用100%或100dvw（较新，兼容性差） -
vh在移动端 Safari 中有 bug：地址栏收放会触发视口高度跳变，导致元素突然缩放；可用min-height: 100dvh缓解（需检查支持情况）
配合 meta viewport 控制初始缩放
没有正确设置 viewport，再好的 CSS 也会失效。最简但关键的一行是：<meta name="viewport" content="width=device-width, initial-scale=1">。它告诉浏览器：别按 980px 默认宽度渲染，按设备物理宽度来，并且不缩放。
容易踩的坑是加了 user-scalable=no 或 maximum-scale=1 —— 这会让用户无法双指缩放，对视力障碍者不友好，也违反 WCAG 基本要求。
立即学习“前端免费学习笔记（深入）”；
- 不要写
width=1920或任意固定数字，这会让手机强行拉伸渲染，模糊失真 - 如果页面必须禁用缩放（极少数后台系统），至少保留
minimum-scale=1，避免用户误操作后无法恢复 - 在 iOS 上，
initial-scale=1有时仍会因字体大小触发自动缩放，可加text-size-adjust: 100%到html或body
用 @media 查询做断点微调
vw/vh 是连续变化的，但设计稿通常是离散断点（如 768px、1024px、1440px）。这时候要用媒体查询兜底：在关键分辨率处修正字号、边距或布局结构。
例如大屏下图标可以更大更疏朗，小屏则紧凑排列并减小留白。纯靠 vw 很难做到这种“阶梯式”控制。
- 断点别照搬设计稿尺寸，优先看内容是否折行、是否拥挤 —— 用
max-width比min-width更直观（比如@media (max-width: 768px)处理手机） - 避免嵌套过多媒体查询，把共用样式抽到外面，只在断点内覆盖差异部分
- 不要用
device-width：它检测的是设备物理宽度，不是浏览器窗口，PC 窗口缩放时完全无效
JavaScript 动态调整要谨慎
用 JS 监听 window.resize 并手动改 style.fontSize 看似灵活，实则风险高：频繁触发重排、影响性能、与 CSS 动画冲突、SSR 不兼容。
除非必须根据 DPI（如 window.devicePixelRatio）或特定硬件特征（如折叠屏状态）调整，否则优先走 CSS 路径。
- 如果真要用 JS，别直接设内联样式，改
document.documentElement.style.fontSize，让所有rem自动响应 - 加防抖：resize 事件每秒触发几十次，用
setTimeout延迟执行，间隔至少 100ms - 注意 SSR 场景：服务端没有
window，首次渲染不能依赖 JS 计算，得靠 CSS fallback
分辨率不是唯一变量，DPR、用户缩放、字体偏好设置、甚至系统深色模式都会影响最终呈现。盯着一个参数调大小，很容易顾此失彼。
