旧版浏览器直接忽略@container规则，因CSS解析器遇未知at-rule即跳过整条规则；无可靠CSS级polyfill，必须用JS模拟，如container-query-polyfill配合@supports按需加载。
旧版浏览器根本无法识别 @container 规则
不是“不生效”，而是直接被忽略——CSS 解析器遇到不认识的 at-rule 就跳过整条规则，连里面的 container-name 或 container-type 都不会解析。这意味着你写的 @container 块在 Chrome 105 之前、Firefox 119 之前、Safari 16.4 之前全部失效，且不会报错，调试时容易误以为是写法问题。
目前没有真正可靠的 CSS-level Polyfill：CSS 自身不具备运行时条件判断能力，也无法动态注入媒体查询式响应逻辑。所有所谓“polyfill”本质都是 JS 驱动的模拟方案，必须配合 DOM 监听和样式重写。
用 container-query-polyfill 是最轻量的可行方案
这是目前维护最活跃、兼容性最明确的实现（GitHub 上由 Google 工程师参与维护），它不替换原生语法，而是把 @container 规则提取出来，用 JS 监听容器尺寸变化，再手动插入匹配的 class 到元素上，再靠普通类选择器触发样式。
- 只支持
container-name，不支持container-type: inline-size以外的类型（即不支持normal或size） - 要求你显式给容器加
container-name属性（如style="container-name: sidebar;"），不能靠container简写属性 - 必须在
<link>或<style>后手动调用init()，否则不生效：import { init } from 'container-query-polyfill';<br>init(); - 性能开销集中在 resize 事件监听和 getBoundingClientRect 调用，建议对频繁变动的容器加节流（polyfill 内部已做 32ms 节流，但大量容器仍可能卡顿）
自己写简易 fallback 时别碰 ResizeObserver 兼容性陷阱
ResizeObserver 在 IE 完全不支持，Edge 16–18 有严重 bug（如嵌套容器尺寸返回 0），即使加了 resize-observer-polyfill，它也只模拟了基础行为，不保证与原生 API 100% 一致。很多团队踩坑在于：写了 polyfill 却没测 Edge 17 下的嵌套容器尺寸回调是否触发。
立即学习“前端免费学习笔记（深入）”；
- 不要依赖
ResizeObserver的contentRect中的inlineSize字段——旧 polyfill 返回的是width，而原生 API 在 container query 场景下应返回块级尺寸逻辑值 - 若需支持 IE11，只能退回到
scroll+offsetWidth轮询（每 200ms check 一次），但会增加 CPU 占用，且无法响应 CSS transform 缩放变化 - 务必在真实设备上测试容器宽度临界点：比如
@container (min-width: 300px)在 polyfill 下可能因四舍五入误差，在 299.6px 时就触发，导致闪动
生产环境必须搭配 @supports 条件加载
不能让 polyfill 和原生 @container 同时存在，否则样式会冲突（JS 插入的 class 可能覆盖原生规则，或反过来）。正确做法是用 @supports (container-type: inline-size) 包裹原生规则，再用 JS 检测失败时才加载 polyfill。
- HTML 中先写原生 CSS：
@supports (container-type: inline-size) {<br> .card { container-type: inline-size; }<br> @container (min-width: 400px) { .card__title { font-size: 1.2em; } }<br>} - JS 中检测并加载：
if (!CSS.supports('container-type', 'inline-size')) {<br> import('container-query-polyfill').then(({ init }) => init());<br>} - 注意 Webpack/Vite 的 dynamic import 会生成独立 chunk，要确保该 chunk 不被预加载（加
/* webpackMode: "lazy" */注释）
真正麻烦的不是 polyfill 本身，而是容器查询天然依赖 layout 测量——任何 JS 模拟都绕不开重排重绘，而现代框架（React/Vue）的异步渲染节奏又可能让测量时机错位。上线前至少要在低端 Android 设备上跑一遍 scroll + resize 混合压力测试。
