容器查询（@container）基于父容器尺寸触发样式响应，但不改变盒模型计算逻辑；其生效需父容器显式声明container-type（如inline-size），且尺寸判断受自身box-sizing影响。
容器查询（@container）本身不改变盒模型计算逻辑，它只是让 CSS 能基于**父容器的尺寸**（而非视口）触发样式响应；真正影响尺寸计算的，仍是元素自身的 box-sizing、width、padding、border 等属性。
容器查询生效的前提：父容器必须是「容器查询上下文」
只有显式声明了 container-type（如 inline-size 或 size）的祖先元素，才能成为容器查询的参考对象。它不自动继承，也不依赖 display 类型（哪怕 display: block 也不够）。
-
container-type: inline-size最常用，表示按内联方向（通常是宽度）建立查询上下文 -
container-name可选，用于精确匹配特定容器（避免嵌套时误触发） - 没有
container-type的父级，即使有width或max-width，也不会被@container捕获
盒模型尺寸在容器查询中仍按标准规则计算
容器查询里的媒体条件（如 @container (min-width: 300px)）检查的是该容器的 可用内联尺寸（即 content area 宽度，不含 margin，但含 padding 和 border —— 这取决于容器自身的 box-sizing）。
- 如果容器设了
box-sizing: border-box，那么min-width: 300px指的是「内容 + padding + border」总宽 ≥ 300px - 如果容器是默认
box-sizing: content-box，则min-width: 300px仅要求内容区宽度 ≥ 300px，padding 和 border 会额外撑大实际占位 - 子元素内部的盒模型计算（比如
.card { width: 100%; padding: 1rem; }）依然遵循自身box-sizing，与容器查询无关
容易踩的坑：padding/border 会干扰容器尺寸判断
当你把一个带 padding 或 border 的元素设为容器时，它的「查询可用宽度」受 box-sizing 直接影响，而开发者常忽略这点，导致断点触发时机出错。
立即学习“前端免费学习笔记（深入）”；
- 典型错误：
div { width: 300px; padding: 20px; container-type: inline-size; }，默认content-box下，内容宽仅 260px，@container (min-width: 300px)永远不会匹配 - 正确做法：加
box-sizing: border-box，或改用@container (min-width: 260px)（但语义变弱） -
margin不参与容器尺寸计算 —— 它不影响@container条件判断，只影响布局位置
最易被忽略的是：容器查询的尺寸基准是「容器的内容盒（content box）」，但它是否包含 padding/border，完全由容器自己的 box-sizing 决定，不是固定规则。写断点前，务必确认容器元素当前的盒模型类型。
