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 等几乎所有接受 <length></length> 的地方。
-
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。
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 给容器加明确尺寸约束：至少设置
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 引擎解析的
真正卡住人的从来不是语法，而是忘记容器必须「主动声明」、尺寸必须「真实存在」、单位必须「在正确上下文中使用」——这三步缺一不可。
