css盒模型由content、padding、border、margin四层构成，width仅指内容区宽；默认content-box下总宽=width+padding×2+border×2，border-box可使width包含padding和border。
它没有改变传统盒模型计算逻辑。
CSS 容器查询（@container）和盒模型（box-sizing、width、padding 等）属于完全正交的两个机制：一个管「样式何时生效」，一个管「尺寸怎么算」。混淆常源于调试时发现「容器宽度没按预期变化」，误以为是盒模型被改了——其实是容器本身尺寸不可测，导致查询条件不匹配。
容器查询失效时，先查盒模型是否让宽度可计算
container-type: inline-size 要生效，父容器必须有稳定、可测量的 inline-size。而这个尺寸恰恰由盒模型决定：
- 如果容器
width是auto，又没受父级约束（比如在display: contents或position: absolute下），那它的 inline-size 就是 0 或未定义 → 查询静默失效 - 如果用了
box-sizing: border-box，且设了width: 300px; padding: 20px; border: 4px solid，那它的 inline-size 就是 300px（不含 margin），可被正确读取 - 如果用了
box-sizing: content-box，同样设置下 inline-size 是 348px（300 + 2×20 + 2×4），也稳定可测 —— 关键不在 box-sizing 值，而在 width 是否最终能算出确定像素值
真正影响容器查询的盒模型相关点
-
gap不参与 inline-size 计算，但padding和border会（无论box-sizing是什么） - Flex/Grid 子项若没设
min-width: 0，可能被压缩到 0，导致 inline-size 失效 -
display: contents的父元素不产生块格式化上下文，container-type被浏览器直接忽略（不是计算错，是压根不认）
@container 规则里单位依赖容器尺寸，但不修改盒模型
容器查询引入了新单位：cqw、cqi、cqh，它们基于容器当前的 inline-size 或 block-size 动态计算。例如：
.card-content {
padding: calc(1 * cqi); /* 相当于容器 inline-size 的 1% */
}
这和 em 或 rem 类似，是「使用单位」，不是「修改规则」。盒模型该怎样还是怎样：width 仍只控制 content 区域（content-box）或总宽（border-box），padding 和 border 仍按既定规则叠加。
最常卡住人的地方不是语法写错，而是容器本身尺寸飘忽不定——比如 JS 插入内容后没触发 layout，或者 Flex 子项被 flex-shrink 拉垮。这时候打开 DevTools 的「Container query containers」面板，一眼就能看到那个标灰的容器：它没注册成功，不是因为 CSS 写得不对，是因为它根本没拿到一个可测量的宽度。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
