CSS cqi 和 cqb 单位分别跟随哪个容器轴

CSS 的 cqi 和 cqb 都是容器查询长度单位，但它们看的不是固定的视口宽高：cqi 等于合格查询容器 inline-size 的 1%，cqb 等于其 block-size 的 1%。在常见的横向书写模式下，inline 轴通常接近水平方向、block 轴通常接近垂直方向；一旦使用竖排或改变 writing-mode，这两个单位仍然跟随逻辑轴。

cqi 和 cqb 先看逻辑轴，不要先看 width 和 height

可以把查询容器想成一个有两条逻辑轴的参照框。inline-size 描述内容沿书写方向展开的尺寸，block-size 描述与它垂直的尺寸。因此，2cqi 表示参照容器 inline-size 的 2%，2cqb 表示 block-size 的 2%。它们的价值在于组件换到不同宽高比或不同书写模式的容器中时，比例关系仍按逻辑方向成立。

下面的例子用逻辑属性把这种关系写出来。代码中的注释只解释关键边界，避免把单位误读成视口单位。

.card {
  /* 让后代按卡片的内联尺寸参与容器查询计算 */
  container-type: inline-size;
  inline-size: min(100%, 42rem);
  padding: 2cqi 3cqi;
}

.card__title {
  /* cqi 随 inline-size 变化，cqb 随 block-size 变化 */
  font-size: clamp(1rem, 1rem + 1cqi, 2rem);
  margin-block-end: 1cqb;
}

建立查询容器后，后代单位才有明确参照

container-type: inline-size 表示这个元素可以作为后代尺寸查询的参照。若需要同时约束内联和块尺寸，可以使用 container-type: size，但也要评估尺寸包含关系和布局约束。container 简写适合同时给容器命名并声明类型，例如 container: article / inline-size。

这里要区分“单位写在谁身上”和“参照对象是谁”：单位通常写在后代标题、间距或组件元素上，实际百分比基准来自最近的合格查询容器，而不是该元素自身，也不是必然来自最外层 viewport。

writing-mode 改变的是轴的方向，不改变 cqi 与 cqb 的职责

在默认横排模式中，很多人会把 inline-size 近似当作宽度、block-size 近似当作高度，这只是便于入门的观察。对于 writing-mode: vertical-rl 等场景，文本流向变化后，inline 轴和 block 轴的物理方向也会变化；cqi 依然跟 inline-size，cqb 依然跟 block-size。使用 margin-inline、padding-block 这类逻辑属性，通常比把单位硬绑到 left、top、width、height 更不容易出错。

无合格容器时，先查回退再查数值

如果元素所在位置没有可用的查询容器，容器查询长度单位不会凭空得到一个普通父元素的尺寸。规范定义了按对应轴回退到 small viewport unit 的行为，所以实际效果可能与预期的卡片比例不同。排查时先确认祖先是否声明了合适的 container-type，再确认书写模式和容器边界，最后才调整数值。

如果设计目标明确是视口宽度或视口高度，应直接考虑 vw、vh 或相应的视口单位；如果目标是物理宽高而不是逻辑轴，也可以评估 cqw 与 cqh。不要为了让数值“看起来对”而给 cqi/cqb 加固定像素补偿。

相关问题

cqi 能不能直接替代 vw？

不能。cqi 以查询容器的 inline-size 为基准，vw 以视口宽度为基准；组件嵌套在窄容器时，两者结果可能明显不同。

cqb 为什么在横排卡片中看起来像高度比例？

因为默认横排模式的 block 轴通常接近垂直方向，但这是书写模式下的物理表现，不是 cqb 永远绑定 height。

只有 container-type: inline-size 时能写 cqb 吗？

可以写，但要先确认布局和浏览器实现对块轴参照的实际条件；若文章只需要沿 inline 轴缩放，优先只使用 cqi，避免让 cqb 承担没有明确参照的尺寸逻辑。