cqw单位必须配合container-type: inline-size声明的容器才能生效，且仅在chrome 110+、edge 110+、safari 16.4+中可用；它表示父容器宽度的1%，专用于组件内元素按容器等比缩放，非视口单位替代方案。
直接说结论：cqw 单位必须配合 container-type: inline-size 声明的容器才能生效，且只在支持 Container Queries 的浏览器中可用（Chrome 110+、Edge 110+、Safari 16.4+，Firefox 当前不支持）；它不是“替代 rem/vw 的新单位”，而是专用于容器内元素按父容器宽度做等比缩放的上下文敏感单位。
为什么 cqw 在移动端常“没反应”？
最常见原因是容器本身没被正确识别为查询上下文：
- 父元素缺失
container-type: inline-size（或简写container: / inline-size），cqw就是无效值，会被浏览器静默丢弃 - 父容器没有**确定的宽度**：比如父元素是
display: block且未设width、max-width，或处于未约束的 Flex/Grid 容器中（如flex: 1但父级无尺寸限制），浏览器无法计算“1% 容器宽度”是多少 - 在 Vue/React 中动态渲染时，
container属性晚于样式表加载（例如用ref+setAttribute后加），导致首次渲染时cqw未被解析
cqw 和 vw 的实际行为差异
cqw 是“容器宽度的 1%”，vw 是“视口宽度的 1%”，二者数值可能差几倍。例如一个卡片在折叠屏右侧内容区占 600px，而视口是 1200px：
-
font-size: 2cqw→ 实际是12px（600 × 2%） -
font-size: 2vw→ 实际是24px（1200 × 2%）
这意味着：cqw 能让文字、间距、边框粗细随卡片自身宽度线性缩放，而不是跟着整个屏幕“发胖”或“缩水”。典型适用场景包括：
- 卡片内标题字体大小随容器变窄自动减小（避免换行挤压）
- 图标尺寸用
width: 4cqw，确保始终占容器宽度 4%，不溢出 - 内边距用
padding: 1cqw 2cqw，保持视觉密度一致
@container 规则里不能直接用 cqw
cqw 只能在声明了容器上下文的后代选择器中作为长度值使用，不能出现在 @container 查询条件里。下面写法是错的：
@container (min-width: 320cqw) { ... }
正确写法只能是基于绝对值或标准媒体查询单位：
@container (min-width: 320px) {
.card-title { font-size: 2.5cqw; }
}
也就是说：@container 决定“什么时候应用样式”，cqw 决定“样式值怎么算”，两者分工明确，不可混用。
移动端折叠屏适配中容易忽略的兼容点
折叠屏设备（如 Galaxy Z Fold、Pixel Fold）常出现同一页面多个可变宽区域，这时要特别注意：
- 每个需要独立响应的区域（如侧边栏、主内容区、底部工具栏）都应单独设置
container-name，避免@container规则互相干扰 - 不要在
@container外层再套@media (max-width: 768px)—— 这会让容器查询退化为视口查询，失去局部响应意义 - 务必提供降级：对不支持
cqw的浏览器（如 Firefox），用@supports not (font-size: 1cqw)包裹规则，并 fallback 到rem或固定值
真正难的不是写对语法，而是判断“这个组件是否值得用容器查询驱动”——如果它只在单个固定布局中出现，@media 更轻量；如果它会被复用在侧边栏、弹窗、嵌入式卡片等多种容器里，cqw 才显出不可替代的价值。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
