SCSS无法根据容器宽度动态计算字体大小——其编译时运算输出固定值，无法获取运行时DOM尺寸；真正响应需@container+clamp()（用cqw单位）或JS+CSS变量方案。
SCSS 本身做不到“根据容器宽度动态计算”字体大小
SCSS 是编译时预处理器，所有数学运算都在构建阶段完成，输出的是固定 CSS 值。它根本拿不到运行时的容器尺寸，width、getBoundingClientRect() 这类 DOM 信息对 SCSS 来说完全不可见。所以任何试图用 @function responsive-font($container-width) 直接返回 font-size 的写法，最终生成的都是静态值，和容器实际宽度毫无关系。
常见错误包括：
- 在 SCSS 中写
font-size: $w * 0.02;并传入100vw→ 编译报错，vw不是数字，SCSS 无法参与运算 - 用
@media (min-width: #{$breakpoint})模拟容器响应 → 实际查的是视口，不是父容器，flex 子项缩放时完全不触发 - 把
calc(1rem + 0.5vw)塞进 SCSS 变量再插值 → 输出合法但仍是视口单位，和容器无关
@container + clamp() 是目前唯一纯 CSS 的容器级字体响应方案
真正能感知父容器宽度并驱动字体变化的，是 CSS 容器查询（@container），但它必须满足两个硬性前提：
- 父容器显式声明
container-type: inline-size;（缺了这行，整个@container规则静默失效） - 子元素字体使用
clamp()，而非直接写死或仅靠@container切换离散值
示例结构：
立即学习“前端免费学习笔记（深入）”；
.card {
container-type: inline-size;
}
<p>.card h2 {
font-size: clamp(1.125rem, 4cqw, 1.5rem);
}</p><p>@container (min-width: 320px) {
.card h2 {
font-size: clamp(1.25rem, 4.5cqw, 1.75rem);
}
}注意：cqw 是容器查询专属单位，1cqw = 父容器内容宽度的 1%，比 vw 更精准；inline-size 查的是 content box，不受 padding/border 干扰。
为什么不能只用 calc() 或 vw？
vw 响应的是视口宽度，不是容器。当 flex 容器分出 3 列，每列只占 300px 宽时，font-size: 4vw 仍按整个屏幕算（比如 1920px 屏下就是 76.8px），文字会撑爆卡片。
calc() 在 font-size 中受限明显：
- 不支持百分比参与运算（
calc(100% - 2px)在 font-size 里非法） - 无法读取父容器宽度作为计算基准（CSS 无
parent-width概念） - 即使写成
calc(var(--container-w) * 0.02)，变量值也必须由 JS 注入，已脱离 SCSS 范畴
如果真要 JS 驱动容器宽度 → 别碰 SCSS 计算逻辑
需要实时监听容器宽度并更新字体的场景（如可折叠侧边栏+主内容区自适应字号），必须放弃 SCSS 的“自动计算”幻想，改用：
- 给容器加
id="main-panel"或稳定 class - 用
ResizeObserver替代window.resize，避免重排抖动 - 读取
el.getBoundingClientRect().width，设为 CSS 变量：document.documentElement.style.setProperty('--container-w', w + 'px'); - CSS 中写：
font-size: calc(var(--container-w) * 0.015);（注意：需确保该容器有明确 width，且非display: contents）
这个路径里，SCSS 唯一该做的事是定义变量名、封装 calc() 表达式模板，而不是尝试“算出结果”。真正的动态性来自 JS 和运行时 CSS 变量，不是预处理器。
最容易被忽略的一点：容器查询的 min-width 是 content box 宽度，而 ResizeObserver 返回的 width 默认也是 content box —— 两者单位语义一致，但混用时若父容器有 box-sizing: border-box 且带 border，JS 读到的值就和 @container 认定的不一致，导致响应错位。
