直接用vw写响应式会出问题，因vw基于视口宽度计算，不响应zoom、DPR及iOS横屏vh异常；硬算如16/375*100vw=4.266vw难读易错，且@media中无法用vw()作断点，须用固定px断点解耦。
为什么直接用 vw 写响应式会出问题
因为设计稿通常基于固定宽度（比如 375px 或 750px），而 vw 是相对于视口宽度的百分比单位，100vw = 100% viewport width。直接把设计稿的 px 值除以基准宽度再乘以 100 写成 vw，看似合理，但会在缩放、横屏、iframe 嵌入等场景下失效——浏览器对 vw 的计算不考虑 zoom 级别，也不区分逻辑像素和物理像素，更不会自动适配 DPR 变化。
更实际的问题是：团队协作时，设计师给的是 16px 字体、24px 间距，前端硬算 16 / 375 * 100vw ≈ 4.266666vw，既难读又易错，且无法统一维护。
用 SCSS 自定义函数 vw() 统一转换
在 SCSS 中定义一个函数，把设计稿的像素值自动转为对应基准宽度下的 vw 值。关键不是“怎么写函数”，而是“选哪个基准宽度”和“要不要支持 fallback”。
-
$vw-base: 375是最常用基准（iPhone SE/6/7/8 屏宽），若设计稿是 750px，则设为750，但注意：此时vw()输出值会减半（因为 100vw 覆盖整个屏幕，750px 设计稿需用 50vw 表示 375px 元素） - 函数必须返回带单位的
vw值，不能只返回数字，否则编译报错：@function vw($px) { @return $px / $vw-base * 100vw; } - 务必加类型检查，避免传入
em、%等非px值导致编译中断：@if unit($px) != 'px' { @error 'vw() expects a value in px, got #{unit($px)}'; }
如何兼容 iOS Safari 横屏时 vh 计算错误
iOS Safari 横屏时，100vh 仍按竖屏高度计算，导致内容被截断。单纯用 SCSS 函数无法修复这个底层 bug，但可以结合 CSS 逻辑属性 + JS 补偿来绕过。
SCSS 层面能做的，是提供一个可切换的 vh() 函数，并默认 fallback 到 min-height: 100% 或 min-height: 100dvh（如果目标环境支持）：
@function vh($px) {
@if not (global-variable-exists(dvh-support) and $dvh-support == true) {
@return $px / $vh-base * 100vh;
} @else {
@return $px / $vh-base * 100dvh;
}
}
真正起作用的是后续在根元素上加的 JS 检测：document.documentElement.style.height = '100dvh'，并在 resize 时重置——SCSS 函数只是让样式层保持可读和可配置。
别忘了媒体查询里不能用 vw() 做断点
SCSS 函数在编译期运行，@media (max-width: #{vw(768)}) 这种写法会输出 @media (max-width: 204.8vw)，完全无效——vw 是相对单位，不能当绝对断点用。
断点必须用固定值（px、em 或 rem），推荐维持一套独立的断点变量：
$breakpoints: ( sm: 576px, md: 768px, lg: 992px, xl: 1200px );
然后用 md 调用 breakpoint-up(md)，和 vw() 完全解耦。混用两者是早期项目最常见的维护陷阱。
真正复杂的点不在函数怎么写，而在于你得明确：哪些地方必须用 vw（比如全屏 banner 高度、字体随屏宽无级缩放），哪些地方其实该用 clamp() + rem（比如正文行高、卡片圆角），以及什么时候该交给容器查询（@container）而不是视口单位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
