Container Queries 与盒模型正交，不改变 width/height/padding/border 计算逻辑；container-type 仅注册查询容器，@container 触发的样式变更才间接影响布局。
它没有改变传统盒模型。Container Queries 和盒模型（box model）是两套正交机制，一个管尺寸计算逻辑，一个管布局上下文生成——混淆二者是新手最容易掉进的坑。
container-type 不是盒模型属性，而是容器注册开关
很多人看到 container-type: inline-size 就下意识联想到 box-sizing 或 display，其实它完全不参与 width/height/padding/border 的计算流程。它的作用只有一个：告诉浏览器“请把这个元素当作一个可被查询的容器”。
- 没加
container-type，哪怕元素有明确 width、display: block、正常 BFC，@container规则也静默失效 - 加了
container-type: inline-size，但父元素是display: contents或position: absolute，该属性会被浏览器直接忽略（不报错，也不注册） -
container-type: size虽然监听宽高，但依然不影响盒模型；它只是让查询条件多了一个维度，不是让元素突然“变大”或“重排”
@container 查询的是容器的“内联尺寸”，不是 content-box 宽度
当你说“容器宽度”，CSS 实际查的是包含 padding 和 border 的 inline-size（在水平书写模式下 ≈ width + padding-left + padding-right + border-left-width + border-right-width），前提是 box-sizing 是默认值；如果用了 box-sizing: border-box，那 inline-size 就等于你写的 width 值。
- gap 不计入
inline-size，Flex/Grid 的 gap 是布局算法产出，不在容器尺寸测量范围内 - 滚动条宽度是否计入，取决于浏览器实现（Chrome 会，Safari 16.4 有时忽略），别依赖它做精确断点
- 不要用
%或em在@container条件里——只支持px、cqw、cqh等容器相对单位
真正影响盒模型感知的，是容器查询触发的样式变更
Container Queries 本身不改盒模型，但它常导致你写一堆 display: flex、grid-template-columns、font-size 这类会间接改变盒尺寸的声明。这时候容易误以为“是容器查询在改盒模型”，其实是你写的样式在改。
立即学习“前端免费学习笔记（深入）”；
- 比如
@container (min-width: 400px) { .card { display: grid; } }—— 改变的是格式化上下文类型，不是盒模型定义 - 又如
@container (min-width: 300px) { .title { font-size: clamp(1rem, 2.5cqw, 1.5rem); } }——2.5cqw是基于容器宽度的动态计算，但最终生效的仍是标准 font-size 盒模型行为 - 如果你在
@container里改了padding或border，那确实会影响子元素的可用空间，但这和媒体查询里改 padding 没本质区别
最常被忽略的一点：容器尺寸必须“稳定可测”。Flex 子项被 min-width: 0 压缩、Grid 列宽由 fr 动态分配、JS 插入内容后未触发 layout —— 这些都会让 inline-size 在某一帧为 0 或 NaN，导致查询条件迟迟不匹配。调试时务必打开 DevTools 的「Container query containers」面板，确认容器是否真的注册成功、尺寸是否在变化。
