去年做一套后台系统的时候，我把「详情卡片」这个组件从首页搬到了右侧抽屉里，问题立刻就来了：首页里它宽520px，标题用20px字号刚刚好；塞进340px宽的抽屉之后，那行标题直接换成了三行，把整张卡片撑得老高。当时的做法是给组件加修饰类，card--compact、card--wide，靠一个观察元素尺寸的脚本来切类名。这套东西维护了半年，类名越加越多，改一次样式要翻三处代码。后来我把整套逻辑推倒，换成了CSS自带的container-type加@container规则，再配合容器单位cqi控制字号，代码量从一百多行脚本降到十几行样式表。这篇就把容器查询和容器单位这套东西从头到尾捋一遍，包括我怎么用它实现字号跟着盒子走，以及加了container-type之后布局突然塌掉的那几个坑。适合已经会写Flex和Grid、但还没在实际项目里用过容器查询的人。
1. 从面板宽度失控说起：媒体查询管不到的是什么
先说清楚媒体查询的边界在哪。@media判断的是视口宽度，它回答的问题是「用户这块屏幕有多宽」。可组件真正在意的往往不是屏幕多宽，而是「我这个盒子被分到了多少空间」。这两件事在很多场景下会彻底脱钩。
最典型的就是同一屏里存在多个尺寸的同一组件。左侧列表窄，右侧详情宽，中间还可能浮着一个小弹窗，屏幕宽度只有一个，但三个卡片的可用宽度分别是300px、560px、860px。这时候你写@media (max-width: 768px)，三条卡片会同时切换样式，而其中只有一条该切。脚本方案能解决，代价是每个组件挂一个尺寸观察器，首次渲染要等一次回调，SSR场景下还会闪一下。
容器查询把这件事拉回了CSS层。你给组件的根元素声明「我是一个可以被查询的容器」，然后在组件内部的样式里写@container (min-width: 400px)，这个条件判断的就是这个容器自己的宽度。组件搬到哪儿，断点就跟到哪儿，跟视口没有关系。组件真正做到了自包含——外壳不需要知道里面发生了什么，里面也不需要知道外面被放进了什么布局。
关于「23年新增」这个说法，稍微啰嗦一句时间线，免得被网上一些文章带偏。尺寸容器查询和容器单位并不是2023年才出现的，Chrome 105和Safari 16在2022年秋天就已经支持了，2023年2月Firefox 110补齐之后，三家主流浏览器全部到位，这套特性才算真正进入「可以放心写进生产代码」的阶段。所以准确说，2023年是它落地成基线的一年，而不是诞生的一年。这个区别在实际选型时挺重要：如果你的项目还要兼容2022年之前的浏览器，降级方案仍然要写，后面第7节会讲。
适用范围我也划一下：任何「同一个组件会被放进不同宽度容器」的界面都值得用，卡片、列表项、导航、表单控件、富文本区块都算。如果你的页面布局本身很简单，一个组件在整页里只有一个位置，那媒体查询完全够用，没必要为了用新特性而引入一层间接。工具是解决问题的，不是用来证明自己跟得上潮流的。
2. container-type 三个取值：normal、inline-size、size 在布局上到底动了什么
2.1 声明容器和声明组件不是一回事
写容器查询的第一步不是写@container，而是先用container-type把某个元素标记成「查询容器」。语法很短：
.card { container-type: inline-size; }container-type有三个取值：normal、inline-size、size。normal是默认值，意思是「这个元素不是查询容器」，写它等于没写。另外两个才是真正干活的。
关键要理解的是：container-type不只是贴个标签，它同时会给元素加上一层CSS包含（containment）。inline-size对应的实际效果等价于contain: layout style inline-size，size对应contain: layout style size。这三个包含分别是干什么的，理解了它们，后面所有的坑就都能提前预判。
layout包含的意思是，这个元素内部的后代布局变化不会影响外部布局。style包含的意思是，元素内部影响计数器的样式变化不会泄漏到外面。最要紧的是尺寸包含：inline-size让元素在内联方向（横排文字时就是水平方向）上的尺寸不再取决于它的内容，size让两个方向的尺寸都不取决于内容。这一点直接决定了你的组件会不会突然塌成一条线。
2.2 inline-size 为什么是默认答案
我自己的经验是，九成场景用inline-size就对了。原因很朴素：绝大多数Web组件的宽度是由父级分配的，高度是由内容决定的。卡片放在网格里，宽度由网格列宽决定；高度取决于标题几行、正文多长、有没有附图。这种情况下你做宽度方向的断点判断就够了，高度方向本来就不该被约束。
inline-size只切断内联方向的尺寸依赖，块方向（纵向）保持正常，内容多高它就多高。这跟日常的组件形态完美契合。所以我的写法基本固定在：
.card { container-type: inline-size; container-name: card; }注意container-name是可选的，不加也能用，默认查询最近的容器祖先。但实际项目里我强烈建议都加上名字，理由在第3节讲嵌套的时候会说到。
2.3 size 取值下高度塌成 0 的原因
size这个取值当初让我困惑了很久。给一个卡片加上container-type: size，它高度立刻变成0，里面的内容全溢出了。这不是bug，是规范设计使然。
size包含把纵横两个方向的尺寸都从内容依赖里摘出来了。既然高度不再看内容，而你又没有从外部给它一个确定的高度，那auto高度算下来就是0。想用size，就必须自己给出明确的尺寸约束，比如height: 100%配合父级确定高度，或者aspect-ratio，或者grid里被拉伸。
那什么场景才需要size？我只遇到过两种：第一种是画布类组件，比如一个图表容器，你要按它的宽高比来调内部元素的比例，这时候高宽都得知道；第二种是全屏看板布局，每个格子被显式规定了尺寸。除了这两种，老老实实inline-size。
2.4 container 简写与书写顺序
container-type和container-name可以用简写合并：
.card { container: card / inline-size; }斜杠前面是名字，后面是类型。这个顺序很容易写反，而且写反了不会报错——浏览器会把inline-size当名字，把card当类型（不合法，最后回退），结果就是容器声明悄悄失效，@container规则一条都不生效。我因为这个坑排查过半小时，后来养成习惯：项目里干脆不用简写，两行分开写，肉眼一眼就能确认哪个是名字哪个是类型。
还有一个细节，container-name是可以一次给多个名字的，用空格分隔：container-name: card wide;。这在你希望同一个容器能被不同的查询规则命中的时候有用。比如组件内部有一套按card命名的精细断点，同时外层布局框架也想按wide来查它。不过我用得不多，多名字容易让规则来源变模糊。
3. @container 的匹配逻辑：最近祖先、命名容器、嵌套截胡
3.1 查询的是祖先，不是自己
这是容器查询最反直觉的一点，也是新手第一个卡住的地方。@container规则查询的对象是符合条件的最近祖先容器，不包括元素自己。
举个例子，下面这段代码不会按你想的那样工作：
.card { container-type: inline-size; } @container (min-width: 400px) { .card { padding: 32px; } }.card自己虽然是容器，但@container里的.card规则去找的是它的祖先容器，.card自己被跳过了。如果没有别的祖先容器，这条规则永远不生效。
正确的心智模型是：容器类型声明在父元素上，查询规则作用在子元素上。样式写在组件内部，靠组件的根节点当容器：
.card { container-type: inline-size; } @container (min-width: 400px) { .card__title { font-size: 24px; } .card__body { padding: 24px 32px; } }.card__title的最近祖先容器是.card，所以查的就是.card的宽度。想改.card自己的样式怎么办？在.card外面再套一层容器，或者干脆把需要响应式变化的属性下沉给子元素，用子元素的padding、margin、字号去实现视觉上的变化。我现在基本走第二条路，包一层壳的做法会让DOM变深。
3.2 嵌套容器时为什么规则不生效
嵌套容器是容器查询最容易「查错对象」的地方。假设有这样的结构：外面是页面布局块.layout，里面是卡片.card，卡片里有个按钮.btn。如果.layout和.card都声明了container-type，那.btn的@container规则命中的是.card，而不是.layout，因为.card更近。这个行为本身是对的，但你如果本来是照着.layout的宽度在写样式，就会发现断点全乱了。
更麻烦的是那种「中间层无意中成了容器」的情况。比如某个通用组件内部给根节点加了container-type，你把它嵌进自己的布局里，结果你自己的@container规则全部转向去查这个中间层容器。因为它是最近的那个。
解决办法就是命名容器。给容器起名字，查询时指定名字，浏览器会向上找第一个「名字匹配」的容器，跳过中间那些不匹配的：
.layout { container: page / inline-size; } .card { container: card / inline-size; } @container page (min-width: 900px) { .card__title { font-size: 28px; } }这样即便.card离.card__title更近，因为规则指定了page这个名字，查询目标依然是.layout。我在项目里给每类容器固定一个名字，并且约定容器名加前缀（page、aside、card、modal），实测下来能避免八成以上的「规则莫名不生效」。
3.3 断点写区间还是写单向
@container支持的条件写法跟@media基本一致，(min-width: 400px)、(max-width: 799px)、(width >= 400px)、(400px <= width <= 800px)都能用，还支持and、or、not组合。
我建议只写单向断点，从小到大层层叠加。也就是先写基础样式（最窄的情况），然后@container (min-width: 400px)补一点，再@container (min-width: 640px)再补一点。原因是容器查询的规则顺序和媒体查询一样受层叠规则约束，写区间容易在边界上出现两边都不命中或者两边都命中的情况，调试起来烦。
另外提一句@container style()，就是按自定义属性的值来做判断的样式查询。这个方向很吸引人，但目前各家浏览器的落地进度不一致，覆盖率远不如尺寸查询，我在生产里还没敢用。比较新的滚动状态查询也还在逐步推广。稳妥起见，尺寸查询和容器单位这两样先吃透，已经能覆盖绝大多数需求了。
4. 容器单位 cqw、cqi、cqh：换算、方向与回退规则
4.1 六个单位各自代表什么
容器单位一共六个，全是相对量：
| 单位 | 参照物 | 典型用途 |
|---|---|---|
cqw | 查询容器宽度的1% | 水平方向的尺寸 |
cqh | 查询容器高度的1% | 需要按高度缩放的场景 |
cqi | 容器内联方向的1% | 横排文字下等同cqw，推荐 |
cqb | 容器块方向的1% | 横排文字下等同cqh |
cqmin | cqi和cqb中较小的那个 | 保证两边都不溢出 |
cqmax | cqi和cqb中较大的那个 | 实现「铺满」效果 |
cqi和cqw在横排文字（writing-mode: horizontal-tb）下数值完全一样。那我为什么推荐cqi？因为如果你的组件要做多语言、要考虑竖排书写模式，cqi会跟着书写方向自动调整，而cqw永远盯着物理宽度。这是个几乎零成本的前瞻性选择。
4.2 一个换算实例
单位换算没什么玄机，就是百分比。假设容器宽度是600px：
1cqw= 600 ÷ 100 = 6px3cqi= 18px0.5cqi= 3px
写font-size: 3cqi，意思是字号取容器宽度的3%。容器300px时字号9px，容器900px时字号27px。看得出来，纯容器单位的问题是范围太宽，小容器下字太小，大容器下字太大。所以实际使用时必须配clamp()兜住上下限，具体算法在第5节展开。
4.3 没有容器祖先时会怎样
这点很多人不知道：容器单位如果找不到可用的容器祖先，会退化成小视口单位。1cqi退化成1svi，1cqw退化成1svw，以此类推。这是规范里明确规定的回退行为，不是浏览器的随意实现。
这个特性其实挺有用，意味着你可以放心地把cqi写进基础样式，在没有容器的时候它退化成视口单位，页面不会崩。但也意味着一个隐患：你以为自己在按容器算，实际上在按视口算，而这两者数值差很多，视觉上会突然对不上。调试的时候如果发现字号跟预期完全不符，第一件事就是确认容器声明到底有没有生效。
4.4 在容器元素自身上用 cqw 的陷阱
还有一个我非常想提醒的细节：容器单位在容器元素自身的样式上使用时，引用的是更上层的容器，不是自己。
.card { container-type: inline-size; padding: 2cqi; /* 这里的 2cqi 参照的是 .card 的祖先容器，不是 .card 自己 */ }因为元素不能自己参照自己。这个规则和@container不能查自身是一致的。如果.card外层没有别的容器，那这个2cqi就又退化成视口单位了。我第一次遇到时以为是浏览器bug，实际上规范一直这么定。
实践上的结论很明确：容器单位只用在后代元素上，不要用在容器根元素自身。根元素的padding、圆角这些，用固定值或者百分比就够了。
5. 字号随盒子呼吸：从分档跳变到线性缩放的两套做法
5.1 分档方案：简单可靠，够用一大半场景
最直白的做法，是用@container给字号设几档，容器跨过断点就跳一档：
.card__title { font-size: 15px; } @container card (min-width: 400px) { .card__title { font-size: 18px; } } @container card (min-width: 640px) { .card__title { font-size: 22px; } }好处是可预测，设计师给的稿子是什么字号就是什么字号，不会出现「这个宽度下刚好卡在两个档之间显得别扭」的问题。而且字号是整像素，渲染清晰，在低分辨率屏上不会糊。
坏处也明显：容器从399px变成401px时，字号会有一个2px的突跳，如果这个卡片在动画里被拉伸，你能肉眼看到文字「咯噔」一下。这种情况在抽屉滑出、折叠面板展开这类带动画的场景里特别扎眼。
5.2 线性方案：参数怎么算出来
真正让字号「随容器变化而变化」的，是把clamp()和cqi组合起来。很多人写font-size: clamp(14px, 3cqi, 22px)就完事了，但中间那个系数是拍脑袋的，结果要么太陡要么太平。其实这是个简单的一次函数，可以精确算出来。
设容器宽度为x（px），目标字号为y（px），你想要的是线性关系 y = a·x + b。给出两个锚点就能解出a和b。假设设计要求：容器宽320px时标题14px，容器宽640px时标题22px。
- 斜率 a = (22 − 14) ÷ (640 − 320) = 8 ÷ 320 = 0.025
- 截距 b = 14 − 0.025 × 320 = 14 − 8 = 6
0.025换算成容器单位就是2.5cqi，于是：
.card__title { font-size: clamp(14px, 2.5cqi + 6px, 22px); }clamp()的中间项本身就支持算式，不用再套一层calc()。验证一下几个关键宽度：
| 容器宽度 | 2.5% × 宽度 + 6px | 实际字号（clamp后） |
|---|---|---|
| 280px | 13px | 14px（触底） |
| 360px | 15px | 15px |
| 480px | 18px | 18px |
| 640px | 22px | 22px |
| 800px | 26px | 22px（封顶） |
可以看到，在320到640之间是平滑过渡，超出范围被clamp夹住。上下限的作用不只是防止字太大太小，更重要的是隔绝极端值——在300px以下的窄容器里，2.5%只有7.5px，人眼根本看不清，必须兜到14px。
这套算法换成滚动公告、大标题、数据看板上的数字都一样适用，把两个锚点换掉重算就行。我通常会在注释里写清楚「锚点 320→14，640→22」，方便后面接手的人调整时不用重推一遍。
5.3 行高、间距要跟着一起改
字号变了，行高如果写死像素，行距比例就会失衡。我的规则是：字号用容器单位，行高一律写无单位数值。
.card__title { font-size: clamp(14px, 2.5cqi + 6px, 22px); line-height: 1.35; margin-bottom: clamp(6px, 1cqi, 14px); }line-height: 1.35会始终跟随字号按比例计算，不需要跟着写响应式。间距项我一般是给一个更小的系数，因为间距随容器放大得太快，会让卡片显得空心。经验值是间距的系数取字号系数的三分之一到二分之一。
内边距的处理要更保守一点。我的做法是给内边距设一个比较窄的浮动区间，比如padding: clamp(12px, 2cqi, 28px)，别让它涨得太夸张。卡片宽度从300涨到900，内边距从6px涨到18px已经是三倍了，再大就喧宾夺主。
5.4 别把所有尺寸都换成 cqi
我见过一种写法，把边框、圆角、图标尺寸、阴影偏移全部换成cqi，美其名曰「完全流式」。实际效果很差：边框在小容器下细到看不见（1cqi在300px容器上只有3px，还行；但0.1cqi就是0.3px，渲染成亚像素灰线），圆角在超大容器上变成夸张的椭圆。
我的原则是：只有和内容尺度直接绑定的属性用容器单位，主要是字号、行高基准、大块留白。边框、圆角、图标这类「物理尺寸」属性保持固定值或者加个很小的clamp。因为它们表达的是「这个界面元素的物理质感」，不应该随容器放大缩小——一张卡片放到大屏上，它的描边不会变成5px粗。
6. 加了 container-type 之后布局崩了：五类副作用与排查顺序
container-type不是个纯声明性的属性，它会改布局。这一点文档里往往一笔带过，但真踩上会很难受。下面这几类我都实际遇到过。
6.1 行内块、浮动、弹性子项的宽度塌陷
inline-size包含让元素在内联方向的尺寸不再取决于内容。这句话对块级元素没什么影响，因为块级元素宽度本来就是撑满父级的。但对下面几种情况下是灾难：
display: inline-block的元素，宽度auto时本来靠内容撑开，现在内容不参与计算，宽度直接是0float: left的元素，同样塌成0- Flex容器里的子项，
flex-basis: auto时本来参考内容宽度，现在内容宽度不参与，会被压到最小 - Grid里的自动列宽，
auto列本来按内容算，现在算不出来
我遇到的具体情形是给一个浮动卡片加了container-type: inline-size，卡片直接消失。排查了半天才反应过来是尺寸包含在作祟。
解决办法：给容器一个明确的宽度来源。Flex子项加flex: 1 1 auto或flex-basis: 320px，Grid子项用固定轨道宽度，浮动和行内块就别用了，改用Grid或者width: min(100%, 360px)这类写法。核心思路是——被声明成容器的元素，必须能从外部拿到宽度，不能指望内容给它宽度。
6.2 变成包含块：fixed 弹层会跑偏
这条我踩得最狠。加了container-type的元素会成为后代定位元素的包含块（containing block）。也就是说，它内部的position: fixed元素不再相对于视口定位，而是相对于这个容器定位。
在一个卡片里放一个「点击查看大图」的按钮，弹层用position: fixed铺满全屏，这个写法以前一直好用。一旦卡片被声明成容器，弹层就变成只能在卡片范围内定位，遮罩只盖住了卡片，整个交互就废了。
排查的时候很容易误判成层级问题或者z-index问题，因为视觉表现是「遮罩没盖住全屏」，而不是「元素位置算错了」。
规避方案有几个：一是把弹层用Portal的方式挂到body下面（React/Vue都有对应方案）；二是容器和弹层的DOM结构分离，弹层不要放在容器内部；三是改用<dialog>元素配showModal()，从顶层渲染，不受包含块影响。我现在项目里统一走第三条，语义清晰，也不用维护Portal逻辑。
6.3 尺寸包含导致的高度归零
size类型的高度塌陷前面说过了，这里补一个不那么明显的情况：inline-size虽然不影响块方向尺寸计算，但如果容器内部有height: 100%的子元素，它的百分比高度是相对容器的已确定高度算的。容器高度如果由内容撑开，这个百分比就是无效的（计算为auto），子元素撑不满。这类问题在改造老组件时经常出现。
6.4 与 sticky、overflow、外边距折叠的相互影响
contain: layout会建立一个新的布局边界，带来的连锁反应包括：
- 容器内部子元素的
margin不会穿透到容器外面，外边距折叠被切断 - 容器内部的
position: sticky元素的滚动参照可能变化，因为包含块变了 - 容器内的浮动元素不会溢出影响外部
这些行为多数是好事，能减少样式互相污染。但如果你是在改造一个老组件，原本依赖外边距折叠来实现间距的地方会突然多出一段空白，或者少一段。改造时最好把容器内部的间距全部改成gap或者明确的padding，别依赖折叠。
6.5 我自己的排查顺序
遇到「加了容器查询之后布局不对」，我按这个顺序查，基本三次以内定位：
- 先把
container-type那行注释掉，刷新。如果布局恢复正常，问题一定和包含有关，进入第2步；如果还是不正常，那是别的地方改错了。 - 给容器加一个
outline: 2px solid red，看它的实际盒子和预期差多少。塌陷的情况一眼就能看出来。 - 检查容器的宽度来源：父级给的是固定宽度、弹性分配、还是靠内容？如果是靠内容，基本可以确定是6.1那类问题。
- 检查容器内部有没有
position: fixed或100%高度的子元素，对应6.2和6.3。 - 最后才去检查
@container规则本身写对没有，容器名拼错没有。
顺序很重要，先把布局问题排掉再排规则问题。反过来做的话，你会花大量时间纠结为什么断点不生效，而实际上容器根本没有宽度。
7. 老浏览器怎么办：降级写法与 @supports 的包裹方式
7.1 双层断点：媒体查询打底，容器查询精修
最省事的降级思路是让两套断点共存。基础样式用视口单位或固定值，保证任何浏览器都能看；容器查询的规则写在后面，支持的环境里自动覆盖。
.card__title { font-size: clamp(15px, 2vw, 20px); } @container card (min-width: 400px) { .card__title { font-size: clamp(15px, 2.5cqi + 6px, 22px); } }不支持容器查询的浏览器会把@container整块忽略，用的是第一行的视口方案。这种降级是「渐进增强」，不会报错也不会白屏，只是精度差一点。我大部分项目都走这条路。
需要注意的是，容器单位本身就自带一层降级——没有容器祖先时退化成小视口单位。所以哪怕@container规则没生效，写在里面的cqi如果被单独使用（比如写在基础样式里），在老浏览器里还是会按视口算，视觉效果不会太离谱。
7.2 用 @supports 明确隔离
如果组件对布局精度要求高，希望完全不支持的环境走一套独立的样式，用@supports包裹：
@supports (container-type: inline-size) { .card { container: card / inline-size; } .card__title { font-size: clamp(14px, 2.5cqi + 6px, 22px); } } @supports not (container-type: inline-size) { .card__title { font-size: 18px; } }这种写法的好处是意图明确，代码审查的时候一眼能看出哪部分是增强、哪部分是兜底。代价是样式表会长一些，而且两套样式需要同步维护，改设计稿时容易漏。
我一般在组件库的基础组件上用这个方式，业务页面里用双层断点就够了。基础组件改动成本高，宁可多写几行；业务页面迭代快，少写一行是一行。
7.3 组件设计层面的一层保险
最后说个跟CSS没直接关系但我觉得更重要的东西：容器查询天然要求组件是自包含的。如果你的组件在外层依赖一堆上下文（父级选择器、全局变量、固定宽度假设），那容器查询加进去也是白搭，因为断点逻辑和外部依赖会互相打架。
改造老组件的时候，我通常先把根元素的宽度来源固定下来（要么撑满父级，要么显式给定），再把内部所有依赖外部上下文的样式清理干净，最后才加container-type。这个顺序反过来的话，你会陷入「加了容器之后样式全乱，但不知道是容器的问题还是组件本身耦合太深」的困境。踩过两次之后，我现在改任何组件都先做这步「解耦体检」，虽然多花十分钟，但省下的调试时间远不止十分钟。
整套东西用下来，最大的感受是它并没有让我少写多少CSS，而是让样式的「作用域」变得清晰了。以前写响应式，脑子里始终要挂着「这个页面现在多宽」，现在只需要想「我这个盒子现在多宽」。这种思维方式的切换，比具体省下的那几行代码值钱得多。
