cqw单位必须配合container-type声明的容器查询使用，单独使用会因找不到查询上下文而退化为0；需在容器上设置container-type: inline-size并确保其宽度稳定，推荐结合clamp()实现安全响应式字号。
cqw单位必须配合容器查询（@container）使用，单独写font-size: 2cqw不会生效——它只在容器查询作用域内被计算。
为什么直接用cqw会失效
浏览器看到2cqw时，会向上查找最近的、声明了container-type: inline-size（或size）的祖先元素。如果没找到，这个单位就退化为0，字体/间距直接塌缩。这不是bug，是设计机制：cqw不是全局相对单位，而是“查询上下文绑定”的动态单位。
常见错误现象：
- 卡片文字突然变极小或消失
- 开发者工具里看到计算值是
0px，但代码明明写了3cqw - 同一段CSS在父容器加了
container-type后立刻生效
必须做的两件事：
- 给卡片最外层容器加上
container-type: inline-size（推荐加在.card自身上） - 确保该容器有明确宽度（不能是
width: fit-content或未设宽且子元素浮动/绝对定位导致宽度坍缩）
clamp() + cqw 是最实用的字号缩放组合
设计师要的“随卡片宽度线性变化但有上下限”，clamp(1rem, 5cqw, 1.5rem)就是标准解法。它比纯cqw更可控，避免过小或过大。
参数差异关键点：
-
1rem是下限：当卡片窄到200px以下时，字号不再缩小，防止可读性崩溃 -
5cqw是弹性中项：每100px容器宽 ≈ 5px字号增量，平滑过渡 -
1.5rem是上限：卡片再宽也不超过24px（假设1rem=16px），防止单张卡片视觉霸权
示例写法：
.card {
container-type: inline-size;
}
.card-title {
font-size: clamp(1rem, 5cqw, 1.5rem);
}
注意：clamp()里的cqw值不依赖视口，只认.card的实际渲染宽度——哪怕它被嵌在侧边栏一个260px宽的div里，计算也完全独立。
哪些场景下cqw会“算不准”
cqw基于容器的**最终布局宽度**，但这个宽度可能受多种因素干扰：
- 父容器用了
flex且未设flex-basis，导致卡片宽度在Flex布局中动态分配，cqw取值滞后于渲染完成 - 容器本身有
padding或border，而cqw计算的是content-box宽度（不含padding/border），若误以为是outerWidth会偏差 - 卡片内部有
position: absolute子元素撑开高度，但不影响cqw——它只看内联轴（通常是宽度）尺寸 - 微前端场景中，主应用未透出
container-type，子应用组件无法触发容器查询上下文
调试建议：在开发者工具中选中卡片容器，看Computed面板里是否显示container-type: inline-size，以及width值是否稳定、符合预期。
和vw混用时的陷阱
你可以在同一个@container规则里同时用cqw和vw，但语义完全不同：
-
margin-left: 2cqw→ 相对于卡片自身宽度的2% -
margin-left: 2vw→ 相对于整个浏览器窗口宽度的2%，和卡片无关
典型误用：
- 想让标题缩放跟随卡片，却写了
font-size: clamp(1rem, 3vw, 1.5rem)→ 结果首页大屏下标题爆炸，侧边栏里却过小 - 用
calc(100% - 2vw)做内边距 →%相对于父容器，vw相对于视口，混合单位计算易失控
真正需要跨层级协调时（比如卡片内图标大小既要随卡片缩放，又要对齐全局图标系统），优先用cqw做主体缩放，再用em或rem做微调。
最常被忽略的一点：容器查询不是“开了就自动生效”，它依赖容器尺寸的**稳定测量时机**。如果卡片宽度在JS操作后才确定（比如异步加载内容导致重排），cqw值可能延迟一帧更新——这时别硬等，用ResizeObserver兜底反而更可控。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
