container queries 依赖容器尺寸变化而非布尔状态，需确保内容区容器宽度随侧边栏展开/收起真实改变，并显式声明 container-type: inline-size；断点应基于“视口宽 − 侧边栏宽 − 留白”计算，优先用 min-width，兼容性需用 data-sidebar 属性兜底。
Container Queries 依赖容器尺寸，不是侧边栏状态本身
直接监听侧边栏“展开/收起”这种布尔状态，container-query 做不到——它只响应容器的 width、height 或 inline-size 等可测量尺寸变化。所以关键在于：让侧边栏的展开动作真实改变内容区域的容器尺寸，并给这个容器显式声明 container-type: inline-size。
常见错误是把 container 声明在 body 或固定宽度的 wrapper 上，结果侧边栏切换时容器宽度没变，查询自然不触发。
- 确保内容区（比如主面板）被一个独立的、宽度随侧边栏变化的元素包裹，例如
<main class="content-container"></main> - 给该元素设
container-type: inline-size，且不要设固定width（否则尺寸锁定，无法响应） - 侧边栏用
position: fixed或flex布局时，主内容区需用margin-left或flex-grow动态占位，才能让其容器宽度真正变化
用 min-width/max-width 匹配不同侧边栏宽度
假设侧边栏收缩时宽 64px，展开时宽 240px，那么主内容区容器的可用宽度会差约 176px。你不需要写 JS 判断状态，只需按容器实际宽度写断点：
.content-container {
container-type: inline-size;
}
@container (min-width: 900px) {
.article-title {
font-size: 1.5rem;
}
}
@container (min-width: 1100px) {
.article-meta {
display: flex;
}
}
这些断点数值来自设计稿中“侧边栏展开后内容区最小可用宽度”，不是随意写的。别用 max-width 反向推导，容易和视口查询混淆；优先用 min-width 表达“空间足够时才增强布局”。
- 断点值应基于真实布局计算：视口宽 − 侧边栏宽 − 其他固定留白
- 如果侧边栏动画过渡时间较长（如 300ms），容器尺寸变化会有延迟，
@container会等尺寸稳定后才匹配，无需额外防抖 - 避免在同一个容器上混用
width和inline-size查询，行为未完全标准化
兼容性兜底：当 container-query 不生效时
目前 Safari 16.4+、Chrome 105+、Firefox 110+ 支持，但旧版或某些 WebView 仍不支持。不能只靠 @container 控制关键布局。
- 用
data-sidebar="expanded"这类属性配合 CSS 属性选择器做基础状态样式：[data-sidebar="expanded"] .content-container - 将
@container规则放在属性选择器规则之后，形成渐进增强：先保功能，再优体验 - 服务端渲染或 SSR 场景下，首次 HTML 中需包含正确
data-属性，否则 JS 注入前样式错乱
不要在 flex item 或绝对定位子元素上直接设 container-type
Flex 容器的子项默认不继承 container-type，且若该子项本身是 position: absolute，它的尺寸脱离文档流，@container 无法获取有效尺寸，查询永远不匹配。
- container 必须作用于一个有明确渲染尺寸、参与布局的块级元素
- 如果用 Grid 布局，确保目标容器是 grid item 且
grid-area分配了实际空间 - 调试时用 Chrome DevTools 的 “Layout” 面板勾选 “Show container queries”，能直观看到哪些元素被识别为 container 及当前匹配的断点
最易忽略的是容器是否真的“被测量”：即使写了 container-type，若父容器 display: contents 或自身 visibility: hidden，它也不会成为有效 container。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
