cqw单位需配合clamp()实现流体排版，单独使用会因无container-type祖先而退化为0px；必须为最近祖先显式设置container-type:inline-size且确保其content-box宽度有效。
cqw 单位本身不能直接实现流体排版，它只在容器查询上下文中提供“相对于容器宽度的百分比”能力，必须配合 clamp() 才能构成真正可控的流体字号。
为什么单独写 font-size: 2cqw 会失效
浏览器解析 2cqw 时，会沿祖先链向上查找第一个声明了 container-type: inline-size（或 size）的容器。找不到就退化为 0px——不是报错，而是静默归零。常见现象是文字突然消失或极小，开发者工具里看到计算值是 0px，但源码明明写了 3cqw。
- 必须给最外层容器（如
.card或#form-container）显式设置container-type: inline-size - 该容器不能是
width: fit-content、display: inline-block且无宽度约束，否则实际渲染宽度坍缩，cqw基于一个极小值计算 -
cqw只认 content-box 宽度，不包含 padding 和 border；若误把容器总宽度当基准，会导致预期偏差
clamp() + cqw 是唯一安全组合
设计师要的是“随卡片宽度线性变化但有上下限”，clamp(1rem, 5cqw, 1.5rem) 就是标准解法。它比纯 cqw 更可控，避免过小或过大。
-
1rem是下限：当容器宽 ≤ 200px（因 5cqw = 1rem → 容器宽 = 200px），字号不再缩小，保可读性 -
5cqw是弹性中项：每 100px 容器宽 ≈ 5px 字号增量，平滑过渡 -
1.5rem是上限：容器再宽也不超 24px（假设 1rem = 16px），防止单张卡片视觉霸权 - 注意：
clamp()里的cqw值只认该元素最近的container-type祖先的实际渲染宽度，哪怕它被嵌在 260px 宽的侧边栏里，计算也完全独立
哪些场景下 cqw 会“算不准”
cqw 基于容器最终布局宽度，但这个宽度可能受多种因素干扰：
- 父容器用 flex 布局且未设
flex-basis或min-width，导致卡片宽度动态分配，cqw取值可能滞后于渲染完成 - 容器内部有
position: absolute子元素——不影响cqw（它只看内联轴宽度），但若这些元素撑开高度后触发重排，可能间接影响宽度计算时机 - 服务端渲染（SSR）或静态生成时，
cqw在 HTML 初次输出阶段无法计算，必须依赖客户端渲染+容器查询激活，无服务端 fallback - 旧浏览器（Chrome width: 80% + 显式父容器宽度的组合方案
真正容易被忽略的点是：cqw 不是“响应式单位”，而是“容器查询绑定单位”——它不关心视口，也不自动监听 resize，只在容器尺寸稳定后的一次性计算。一旦容器宽度因 JS 修改或 CSS 动画变动，需要浏览器重新触发容器查询评估，这个过程不可控、不可预测。所以对强动态容器，优先考虑 rem/vmin + JS 监听，而非强依赖 cqw。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
