真正安全的流体排版必须用clamp() + 显式fallback，因vw无边界易致小屏过小、大屏过大，且无视用户缩放；SCSS仅辅助统一写法，无法替代浏览器运行时计算。
直接用 vw 写字号大概率会翻车，真正安全的流体排版必须靠 clamp() + 显式 fallback，SCSS 只能帮你写得更稳、更统一，不能替代浏览器运行时计算。
为什么不能只用 font-size: 2.5vw
小屏下字太小（iPhone SE 的 2.5vw ≈ 9.4px），大屏下又太大（27寸显示器上可能超 40px），且完全无视用户缩放、辅助字体设置、滚动条宽度偏差。更关键的是：它没下限也没上限，不是“流体”，是“脱缰”。
常见错误现象：
- 设计师给 16px 字号，你写
font-size: 4.266vw，结果在横屏 iPad 上文字撑破卡片 - 用
calc(16px + 0.5vw)，但没约束，导致 320px 宽度时算出 17.6px，而 1920px 时飙到 25.6px - 误以为 SCSS 函数能动态响应 resize——其实编译完就是个死值，比如
@function fs($x) { @return $x * 1vw; }输出的仍是静态16vw，不是运行时逻辑
用 clamp() 写安全流体字号的硬性条件
clamp() 是唯一兼顾平滑变化与边界控制的原生方案，但写法有强约束：
立即学习“前端免费学习笔记（深入）”；
- 第一参数（最小值）必须是固定单位（
rem或px），不能是vmin，否则小屏仍可能过小 - 第二参数推荐用
vmin而非vw，避免横竖屏切换时字号突变（比如竖屏 375×812，vmin=375；横屏 812×375，vmin 还是 375） - 第三参数（最大值）建议用
rem，和最小值单位一致，避免单位混用导致计算混乱 - 必须手动写两行：先写降级值，再写
clamp()，顺序不能反，否则旧浏览器无法 fallback
正确写法示例：
font-size: 1.125rem; font-size: clamp(1.125rem, 4vmin, 2.25rem);
SCSS 能真正帮上忙的三件事
它不生成新能力，但能减少人为错误、提升一致性：
- 用变量统一基准：
$base-font: 1.125rem;、$max-font: 2.25rem;、$vmin-factor: 4;，后续改一处全链路生效 - 封装 mixin 避免重复：
@mixin fluid-type($min, $factor, $max) { font-size: $min; font-size: clamp($min, #{$factor}vmin, $max); }，调用时@include fluid-type(1.125rem, 4, 2.25rem); - 批量生成多层级标题：用
@each遍历 map，为h1到small一次性输出带 fallback 的声明，确保每条都含两行font-size
注意：SCSS 不会自动补 font-size: 1.125rem; 这行 fallback，漏写就等于放弃所有不支持 clamp() 的设备（如 iOS 12.1 及更早版本）。
别碰 @container + cqw 的 SCSS 封装幻想
想让字号响应父容器而非视口？必须用 @container + cqw，但 SCSS 对此完全无能为力：
-
cqw是运行时单位，和vw一样，SCSS 编译不出新行为 -
@container规则需在 HTML 元素上显式声明container-type: inline-size，这个声明必须写在真实 CSS 中，SCSS 只能复用 class，不能注入逻辑 - 目前没有可靠方式用 SCSS 自动生成容器查询断点或绑定 cqw 系数——这事得交给 JS 或手写 CSS
真正容易被忽略的点：流体排版不是“写了 clamp() 就万事大吉”，而是要搭配行高、字重、字间距的协同缩放，且真机测试时必须覆盖缩放 150%、横屏、深色模式三种组合场景——这些 SCSS 都管不了，只能靠人盯。
