容器查询用于组件级响应式设计，适用于卡片等可复用组件在尺寸差异大的父容器中需动态调整内部结构的场景，不适用于页眉等视口强绑定区域；必须显式声明container-type: inline-size，推荐使用命名容器。
容器查询不是媒体查询的升级版，它解决的是完全不同的问题——别指望用 @container 替换整页 @media 断点，那样只会让布局失控。
什么时候该用 @container 而不是 @media
只在组件被复用到尺寸差异大的父容器中，且内部结构需随容器宽度动态调整时才值得引入。比如同一个 .card 组件既出现在 800px 宽主栏，又嵌在 320px 宽侧边栏里；这时 @media (min-width: 768px) 根本无法区分它实际可用空间，而 @container (min-width: 500px) 可以。
- 适用：卡片、图表、列表项等“可插拔”组件
- 不适用：页眉、页脚、全屏模态框等与视口强绑定的区域
- 典型误用：用
@container控制整个页面栅格列数（该用@media或grid-template-columns函数）
container-type: inline-size 必须显式声明
这是最常漏掉的一步——没有这句，@container 规则完全不会计算，浏览器静默忽略，连控制台警告都没有。旧项目迁移时尤其容易卡在这儿。
- 必须加在直接或间接包裹目标组件的祖先元素上，不一定是父元素
- 优先用
inline-size（只监控宽度），除非你真需要响应高度变化 - 避免用
size，它会触发更频繁的重排，且兼容性更差 - 如果容器宽度依赖内容（如
display: inline-block且无固定宽），可能触发容器查询循环，导致回退为无容器状态
@container 规则里的命名和范围写法
命名容器不是必须的，但强烈建议加上 container-name，否则多个同级容器可能互相干扰，调试时极难定位。
立即学习“前端免费学习笔记（深入）”；
- 声明：
.card-wrapper { container: product-card / inline-size; }（简写语法） - 使用：
@container product-card (max-width: 360px) { ... } - 支持范围语法：
@container product-card (300px ，比写两个断点更清晰 - 注意：括号内不能写
min-width: 300px这种带单位的属性名，只能是width或height
JS 动态插入 DOM 后容器不响应？调用 requestContainerUpdate()
后台系统常见场景：通过 JS 渲染新卡片到已有的容器中，但样式没变——因为浏览器没主动检测新挂载节点的容器状态。
- 必须手动触发：
newCardWrapperElement.requestContainerUpdate() - 仅对已声明
container-type的元素有效，对未声明的无效 - 不要在每次插入后都调用，只在确认容器尺寸可能变化时调用（比如插入后父容器重流）
- 旧浏览器兜底方案仍是
ResizeObserver+ CSS 变量，但现代项目中可忽略 IE 和 Safari
真正难的不是写对语法，而是判断「这个组件到底值不值得用容器查询」——很多所谓“响应式需求”，其实用 flex-wrap、minmax() 或 aspect-ratio 就能解，硬上 @container 反而增加维护成本。
