container queries在旧版浏览器中不报错而是静默忽略，chrome 110+、firefox 113+、safari 16.4+才原生支持，safari 16.4需加-webkit-前缀，@supports检测必须用(container-type: inline-size)。
container queries 在旧版浏览器根本不会报错，而是直接忽略
这是最常被误解的一点：旧版浏览器（如 Chrome 109 及更早、Firefox 112 之前、Safari 16.3 及更早）对 @container 语法完全不识别，但**不会抛出 CSS 解析错误**，也不会在 DevTools 控制台显示任何提示。它只是静默跳过整条 @container 规则——就像那行代码不存在一样。
所以你看到“没生效”，不是脚本报错，是浏览器压根没执行。这也导致很多开发者反复检查拼写、缩进、括号，却漏掉了最关键的兼容性前提。
- Chrome 110+、Firefox 113+、Safari 16.4+ 才开始原生支持
@container - Safari 16.4 需要加
-webkit-前缀（@-webkit-container），且仅限部分语法 - 所有 Edge 旧版本（≤112）和大部分 Android WebView（尤其系统级）仍无支持
用 container-query-polyfill 时为什么 JS 报错或样式错乱
引入 container-query-polyfill 后出现 ResizeObserver is not defined 或容器尺寸始终为 0，通常是因为 polyfill 运行时机或容器状态不对。
- 必须确保 polyfill 在 DOM 加载完成后再执行，否则
document.querySelector(".card")返回 null - polyfill 依赖
ResizeObserver，IE 和部分旧安卓 WebView 不支持；需提前检测：if (typeof ResizeObserver !== "function") { /* 加载 ResizeObserver polyfill */ } - 如果容器本身没有渲染出实际尺寸（比如
display: none、visibility: hidden、或父级height: 0），polyfill 读到的contentRect.width就是 0，所有断点逻辑失效 - 不要在同一个容器上既写原生
@container又手动用 JS 切类名（如cq-sm），会导致样式冲突或重复计算
@supports 检测写法必须严格匹配原生语法
用 @supports 做渐进增强时，检测项必须和浏览器实际支持的特性一致，写错一个字母就降级失败。
- ✅ 正确：
@supports (container-type: inline-size)—— 这是唯一被广泛实现的检测方式 - ❌ 错误：
@supports (@container)、@supports (container-query: true)、@supports (container: inline-size)—— 全部无效，浏览器不识别 - 检测必须放在
@container规则外部，不能嵌套在@media内部 - 降级样式应写在
@supports块内，而不是外面；否则旧浏览器会应用降级样式，新浏览器又叠加原生规则，造成双重效果
真机测试时容器尺寸“卡住不动”的真实原因
在折叠屏或动态调整容器宽度的场景下，polyfill 感知不到尺寸变化，不是脚本 bug，而是容器未触发重排或 ResizeObserver 未监听到更新。
- 容器若使用
flex或grid布局，且未设min-width: 0或overflow: hidden，其内容撑开后可能不触发 resize 回调 - 某些安卓 WebView 对
ResizeObserver的节流策略极严，连续快速缩放可能只上报最后一次尺寸 - 别依赖
window.innerWidth或screen.width推算容器宽——必须用entry.contentRect.width，它是唯一反映渲染后真实尺寸的值 - 如果容器是通过 JS 动态插入的（如 React 组件 mount），记得在插入后立即调用
observer.observe(el)，而不是只在页面初始化时执行一次
真正难的不是加 polyfill，是让每个容器在任意浏览器里都「稳定可测」：有尺寸、能重排、不坍缩、不被父级遮蔽。这需要 layout、contain、BFC 三者配合，缺一不可。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
