cqw和cqh必须配合container-type声明的容器上下文才生效;未设置container-type: inline-size或size时,浏览器静默忽略cqw/cqh,因其只响应被显式启用的containment context,而非普通父元素尺寸。

容器查询单位 cqw 和 cqh 不能直接用,必须配合 container-type 启用的容器上下文才生效——这是最常被忽略的前提。
为什么写了 cqw 却没效果?
因为 cqw 不是全局单位,它不认父元素的 width 或 height,只认被声明为容器(containment context)的祖先元素的 inline-size 或 block-size。没加 container-type,cqw 就是无效值,浏览器会静默忽略。
- 必须在父元素上设置
container-type: inline-size(宽度监听)或size(宽高都监听),cqw才能计算 -
container-type: normal(默认值)或未声明时,cqw完全不参与计算,哪怕写成font-size: 5cqw也会回退到浏览器默认字体大小 - 父元素若设置了
display: contents或visibility: hidden,可能破坏 containment,导致容器查询失效
cqw 和 % 的关键区别在哪?
% 是相对父元素的 layout size 计算,但很多 CSS 属性(如 font-size)根本不支持 %;而 cqw 是专为容器查询设计的逻辑单位,可安全用于 font-size、width、padding 等几乎所有接受 的地方。
-
font-size: 2em→ 相对自身font-size,嵌套易失控 -
font-size: 2rem→ 全局依赖html根字号,组件难隔离 -
font-size: 3cqw→ 只随该容器宽度变,且 1cqw = 容器宽度 × 1%,数值可预测 - 注意:
100cqw≡ 容器宽度,100%在font-size中非法,但在width中合法但语义不同(% 是相对父块,cqw 是相对容器)
如何让 cqw / cqh 在微前端或卡片组件中真正自适应?
核心是「容器命名 + 多级断点 + 避免尺寸坍缩」。微前端里常因样式隔离或高度未设死,导致容器尺寸为 0,cqw 算出来就是 0px。
- 给容器加明确尺寸约束:至少设置
width: 100%或min-width: 0,防止 flex/grid 下 shrink 到 0 - 使用
container-name区分上下文,避免嵌套容器互相干扰:container: card / inline-size - 搭配
@container写断点逻辑,而不是只靠cqw算数:@container card (min-width: 320px) { .title { font-size: 1.8cqw; } } @container card (min-width: 480px) { .title { font-size: 2.2cqw; } } -
cqh要慎用:除非容器有明确height或block-size(比如固定高弹窗、图表容器),否则容易因高度未触发 layout 而始终为 0
兼容性和 fallback 怎么处理?
目前(2026 年 4 月)Chrome 110+、Firefox 119+、Safari 17.4+ 原生支持,Edge 同 Chrome。不支持时 cqw 会被当作无效值丢弃,不会报错,但也不会降级。
- 不要依赖
cqw做关键布局,比如用width: 50cqw替代width: 50%—— 后者有广泛兼容性 - 可用
@supports (width: 1cqw)包裹增强样式,内部再写cqw逻辑 - 对字体大小这类非关键属性,可先写
font-size: 1rem,再覆盖font-size: 2.5cqw,不支持时自动回退 - 注意:PostCSS 插件目前无法 polyfill
cqw,它不是编译时单位,而是运行时由浏览器 layout 引擎解析的
真正卡住人的从来不是语法,而是忘记容器必须「主动声明」、尺寸必须「真实存在」、单位必须「在正确上下文中使用」——这三步缺一不可。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











