使用容器查询提升组件复用性的实战案例

最近接手维护一个老项目，打开 CSS 文件的那一刻我真的有点崩溃——.card--sidebar、.card--modal、.card--compact、.card--horizontal，光一个卡片组件就有七八个修饰类。更离谱的是，每个修饰类背后都对应着一套媒体查询的断点，而 JS 里还藏着一堆计算容器宽度的逻辑，就为了判断"这个卡片现在到底被塞在哪个位置"。

这大概是前端组件化开发里最拧巴的一件事：我们费尽心思把组件封装好，结果它一换个位置就水土不服，还得靠外部传类名、传参数来"告诉"它该怎么展示。说实话，这根本就不叫封装。

容器查询的出现，真的让我有种"终于等到你"的感觉。它的思路特别简单——组件不用关心视口多宽，也不用关心自己被谁调用，它只需要感知"我现在有多大的空间可用"。就这么一个视角的转变，解决了无数历史遗留问题。

我拿项目里的产品卡片做了个实验。原来这个卡片在主内容区是横向两列，到侧边栏就得变成单列堆叠，全靠在父组件上挂不同的修饰类。重构之后，我只做了一件事：给包裹卡片的容器加上 container-type: inline-size，然后在组件内部写了三个容器查询断点——350px 以下单列堆叠，350px 到 550px 之间紧凑横向，550px 以上宽松两列。

效果怎么说呢，就是丝滑。同一个 .product-card，零修饰类，零 JS，放在主内容区自动展开成两列，塞进侧边栏自动缩成单列，丢进模态框又能变成紧凑模式。三种容器，三种形态，组件自己全搞定了。

更让我惊喜的是侧边栏导航的重构。原来那个导航的"展开/折叠/响应式收缩"三态切换，靠的是一套复杂的媒体查询加上 JS 监听侧边栏宽度。换成容器查询之后，导航只管自己容器的宽度，容器够 200px 就显示图标加文字，不够就只留图标。配合一个简单的 CSS 类切换侧边栏宽度，三态切换完全在 CSS 层面闭环了。

踩过坑之后有几个心得特别想分享：一是写 @container 之前一定要检查祖先链上有没有声明 container-type，否则查询会静默失效，控制台还不报错，我当时找了半天；二是嵌套容器容易查错层，最好用 container-name 显式指定目标；三是断点值最好用 CSS 变量暴露出来，这样使用方可以按自己的设计系统统一调整，组件库的灵活性一下子就上去了。

如果你也在维护那种"组件到处贴补丁"的老项目，真心建议从最内层、最常复用的组件开始改。花一个下午把卡片、导航、表单这些叶子组件换成容器查询，你会发现很多曾经需要 JS 和修饰类才能解决的布局问题，在 CSS 层面就彻底闭环了。这种"组件终于有了自我意识"的感觉，真的太爽了。