企业官网建设流程全解析

大家好！欢迎来到今天的“React 响应式布局”特别讲座。我是你们的老朋友，那个发誓再也不熬夜写 CSS，结果最后还是为了那个“像素级完美”而熬秃了头的资深前端工程师。

今天我们不聊 Redux，不聊 TypeScript 的地狱，也不聊 Webpack 的构建速度。今天，我们要聊的是 CSS 里的一场“政变”，一场能够终结“媒体查询地狱”的革命——容器查询。

如果你是个老司机，你一定经历过这种痛：你在写一个<Card>组件，把它放在侧边栏，它长这样；放在主内容区，它长那样；放在移动端的底部导航栏，它又变成了一个奇怪的长条形。为了实现这个效果，你不得不给父容器加一堆莫名其妙的min-width、max-width，甚至不得不把原本整洁的组件拆成三个不同的文件。

这太蠢了！这简直是反人类的设计！

今天，我们就来学习如何用 React 配合容器查询，让你的组件像变色龙一样，根据它所处的“环境”自动调整形态，而不是根据浏览器窗口的大小。

第一部分：我们要逃离的“视口诅咒”

在讲新特性之前，咱们得先回忆一下“旧社会”是怎么过来的。

以前，我们衡量组件大小的标尺只有一个：视口。也就是浏览器窗口的大小。

/* 旧时代的悲歌 */ .card { width: 300px; height: 200px; } @media (min-width: 600px) { .card { width: 100%; display: grid; } }

看懂了吗？这段代码的意思是：“当屏幕宽度大于 600px 时，我的卡片就变成网格布局。”

问题来了，这个.card组件它自己知道自己在哪吗？它不知道。它只是个可怜的打工仔，它只能听到老板（浏览器窗口）的命令。如果老板把桌子（视口）变小了，它就得变形。但如果你把.card放到一个 400px 宽的侧边栏里，它依然会傻乎乎地按照屏幕的宽度去布局，导致在侧边栏里显得非常拥挤或者非常空旷。

这就是“视口诅咒”。组件的响应式逻辑与组件本身是解耦的，这违背了组件化开发的初衷。

第二部分：容器查询——给组件安上“眼睛”

那么，怎么才能让组件“看见”周围的环境呢？

这就是容器查询登场的时候了。它的核心思想非常简单粗暴：不再看屏幕有多大，而是看“容器”有多大。

想象一下，你是一个人。以前你是根据“整个房间的面积”来决定自己怎么穿衣服（视口）。现在，容器查询让你根据“你站在哪个桌子上”来决定穿衣服。你在圆桌上穿礼服，在方桌上穿休闲装，在餐桌上穿睡衣（比喻）。

1. 启用容器

在 CSS 中，我们需要告诉某个元素：“嘿，我愿意被查询！”这需要设置container-type属性。

.container { /* 告诉浏览器，这个元素可以作为容器 */ container-type: inline-size; /* inline-size 是最常用的，表示根据元素的宽度来查询 */ }

2. 在容器内进行查询

一旦容器被启用了，我们就可以在容器内部使用@container语法了。

/* 当容器的宽度大于 400px 时，里面的 .card 变成两列 */ .container { container-type: inline-size; } .card { width: 100%; padding: 10px; background: #fff; border-radius: 8px; box-shadow: 0 4px 6px rgba(0,0,0,0.1); } @container (min-width: 400px) { .card { display: grid; grid-template-columns: 1fr 1fr; /* 变成两列 */ gap: 10px; } }

看到了吗？没有@media，没有屏幕宽度。只有@container。这个.card现在知道了自己的容器是 400px 宽还是 100px 宽，并据此改变形态。

第三部分：React 中的容器查询实战

光懂 CSS 还不够，咱们得用 React 把它玩起来。React 的核心哲学是“组件化”，而容器查询让组件真正做到了“自包含”。

场景：一个通用的“文章卡片”组件

假设我们有一个文章卡片组件，我们需要它能在不同场景下工作：

1. 侧边栏列表：卡片垂直排列，宽度受限。
2. 主内容网格：卡片水平排列，宽度充裕。
3. 移动端底部：卡片横向铺满。

我们来看看怎么用 React 实现。

步骤一：创建容器组件

在 React 中，我们需要一个父组件来充当“容器”。这个容器负责包裹内容，并传递上下文（虽然 CSS 已经处理了大部分，但我们需要在 DOM 结构上体现）。

// Container.jsx import React from 'react'; const Container = ({ children, name = 'default-container', ...props }) => { return ( <div className={name} {...props}> {children} </div> ); }; export default Container;

步骤二：编写 CSS（使用 styled-components 以便更清晰地演示）

这里我强烈推荐使用styled-components，因为它的 CSS-in-JS 特性能让我们更直观地看到@container的作用域。

// ArticleCard.jsx import React from 'react'; import styled from 'styled-components'; // 定义卡片的基础样式 const CardWrapper = styled.div` background-color: white; border-radius: 12px; padding: 20px; box-shadow: 0 2px 8px rgba(0,0,0,0.1); transition: transform 0.3s ease; /* 关键点：启用容器查询 */ container-type: inline-size; container-name: article-card; /* 默认样式：当容器很窄时，我们希望它是单列或者紧凑的 */ h3 { font-size: 1.2rem; margin-bottom: 0.5rem; } p { font-size: 0.9rem; color: #666; line-height: 1.5; } `; // 定义卡片内部元素的样式（或者直接在 CardWrapper 里写） const CardContent = styled.div` /* 当容器宽度大于 300px 时，图片和文字并排显示 */ @container article-card (min-width: 300px) { display: flex; gap: 15px; align-items: flex-start; img { width: 80px; height: 80px; border-radius: 8px; object-fit: cover; flex-shrink: 0; } .text-content { flex-grow: 1; } } `; // 当容器宽度大于 600px 时，卡片变大，文字变大 @container article-card (min-width: 600px) { padding: 30px; h3 { font-size: 1.5rem; } p { font-size: 1rem; } } const ArticleCard = ({ title, excerpt, image, author }) => { return ( <CardWrapper> <CardContent> <img src={image} alt={title} /> <div className="text-content"> <h3>{title}</h3> <p>{excerpt}</p> <small>{author}</small> </div> </CardContent> </CardWrapper> ); }; export default ArticleCard;

步骤三：在父组件中使用

现在，我们在不同的布局中使用这个组件，看看它的神奇之处。

// App.jsx import React from 'react'; import Container from './Container'; import ArticleCard from './ArticleCard'; const App = () => { return ( <div style={{ padding: '20px', fontFamily: 'sans-serif' }}> {/* 场景 1：侧边栏布局 */} <h2>侧边栏布局</h2> <Container name="sidebar-container" style={{ width: '300px', border: '1px dashed #ccc', padding: '10px', margin: '20px 0' }}> <ArticleCard title="React 14 发布了？" excerpt="关于最新的并发模式和 Server Components 的深度解析..." image="https://via.placeholder.com/150" author="张三" /> <ArticleCard title="CSS 容器查询太强了" excerpt="终于告别了媒体查询的痛苦，组件终于可以自适..." image="https://via.placeholder.com/150" author="李四" /> </Container> {/* 场景 2：主内容网格布局 */} <h2>主内容布局</h2> <Container name="main-content-container" style={{ width: '100%', border: '1px dashed #ccc', padding: '10px', margin: '20px 0' }}> <ArticleCard title="前端架构师之路" excerpt="从组件化到微前端，你需要了解的一切..." image="https://via.placeholder.com/150" author="王五" /> <ArticleCard title="WebAssembly 能取代 JS 吗？" excerpt="性能的极致追求，还是鸡肋的补充？" image="https://via.placeholder.com/150" author="赵六" /> <ArticleCard title="TypeScript 进阶指南" excerpt="泛型、映射类型、条件类型..." image="https://via.placeholder.com/150" author="孙七" /> </Container> {/* 场景 3：手机端模拟 */} <h2>手机端模拟</h2> <div style={{ width: '375px', border: '1px solid #333', margin: '20px auto', padding: '10px' }}> <Container name="mobile-container"> <ArticleCard title="移动端适配" excerpt="在手机上，卡片应该全宽显示，图片变小..." image="https://via.placeholder.com/150" author="测试员" /> </Container> </div> </div> ); }; export default App;

结果分析：

1. 在sidebar-container（300px）中，@container (min-width: 300px)条件触发，图片和文字并排显示。但因为是 300px，所以卡片看起来比较紧凑。
2. 在main-content-container（宽度由父级决定，假设是 800px）中，@container (min-width: 600px)条件触发，卡片变大，字体变大，图片保持 80px。
3. 在mobile-container（375px）中，只有min-width: 300px生效，卡片全宽，图片 80px。如果屏幕只有 200px，图片和文字会堆叠。

看懂了吗？ArticleCard组件自己根本不知道自己在哪，它只关心它的容器。它把自己交给 CSS，CSS 根据“容器大小”给它下命令。这才是真正的“自适应组件”。

第四部分：进阶玩法——Tailwind CSS 的加持

如果你是个 Tailwind CSS 的信徒，那你现在肯定在流口水。Tailwind 现在也原生支持容器查询了！

虽然 Tailwind 是基于 Utility Classes 的，但它引入了@container指令。这简直是为它量身定做的。

// 使用 Tailwind 的示例 import React from 'react'; const Card = ({ title, content }) => { return ( <div className="@container p-4 bg-white rounded shadow"> {/* 默认样式：全宽，单列 */} <div className="flex flex-col gap-2"> <h2 className="text-xl font-bold">{title}</h2> <p className="text-gray-600">{content}</p> </div> {/* 当容器宽度大于 300px 时：水平布局，图片和文字并排 */} <div className="@container @[300px]:flex-row @[300px]:items-start @[300px]:gap-4"> <div className="@container @[300px]:w-32"> {/* 图片 */} <img src="..." className="w-full h-auto rounded" /> </div> <div className="@container @[300px]:flex-1"> {/* 文字内容 */} <p>{content}</p> </div> </div> </div> ); };

Tailwind 的语法@[断点名]:属性非常直观。@container指定了当前容器，@[300px]:表示当容器宽度大于 300px 时生效。

第五部分：容器查询的“副作用”与坑

虽然容器查询很美好，但作为资深专家，我必须提醒你，它也有一些“坑”，或者说，一些需要注意的细节。

1. 容器必须有尺寸

这是最最重要的一点！容器查询是依赖容器自身的尺寸的。

如果你写了一个 React 组件MyComponent，它内部使用了container-type: inline-size。但是，它的父元素没有设置宽度，或者父元素使用了flex: 1但没有明确设置宽度（在旧浏览器或特定 flex 配置下），那么容器查询可能会失效，或者表现得非常奇怪。

解决方案：确保你的容器元素（父组件）有明确的宽度定义。

// 坏例子 <div> {/* 没有 width */} <MyComponent /> {/* 容器查询可能失效 */} </div> // 好例子 <div style={{ width: '100%' }}> {/* 确保有宽度 */} <MyComponent /> </div>

2. 性能考量

有人会问：“频繁查询容器尺寸不会影响性能吗？”

答案是：不会，通常不会。

现代浏览器对容器查询做了非常激进的优化。它们利用了类似“容器查询大小变化事件”的技术，只有在容器尺寸真正发生变化时才会触发重绘。相比于resize事件监听，它的开销要小得多。而且，容器查询的断点通常是整数，浏览器处理起来非常快。

3. 兼容性

好消息是，除了极老的浏览器（IE11 及以下，以及非常老的移动端浏览器），现代浏览器（Chrome, Firefox, Safari, Edge）都完美支持容器查询。

如果你需要支持非常老的浏览器，你需要使用 Polyfill。不过，Polyfill 通常需要包裹一层 JS 逻辑，并且需要给容器设置固定的高度才能模拟宽度变化，这会带来一些性能损耗。但好消息是，现在绝大多数项目都已经抛弃了 IE11，所以我们可以放心大胆地使用原生 API。

第六部分：容器查询的“灵魂”——布局逻辑

容器查询不仅仅是改变大小，它还改变了布局的逻辑。

举个例子，导航菜单。

在视口查询时代，我们处理导航菜单非常痛苦：

• 屏幕宽 -> 水平菜单。
• 屏幕窄 -> 垂直菜单。
• 屏幕再窄 -> 变成汉堡菜单。

而在容器查询时代，我们可以这样思考：

/* 定义一个导航栏容器 */ .nav-container { container-type: inline-size; background: #333; color: white; padding: 10px; } /* 默认：水平菜单 */ .nav-items { display: flex; gap: 20px; } /* 当导航栏宽度小于 200px 时（比如在手机顶部栏），菜单变成垂直的 */ @container (max-width: 200px) { .nav-items { flex-direction: column; gap: 5px; } /* 甚至可以隐藏文字，只留图标 */ .nav-text { display: none; } }

这样，无论你的导航栏是放在 Header 里（通常很宽），还是放在 Footer 里（通常很窄），或者是放在侧边栏里（宽度不定），它都能根据自身宽度自动调整布局。这种“内聚性”是以前媒体查询完全无法比拟的。

第七部分：React Hooks 的配合（可选）

虽然容器查询主要是 CSS 的能力，但在 React 中，我们可以结合 Hooks 来做一些更高级的交互。

比如，我们可以利用useLayoutEffect来检测容器尺寸的变化，从而做一些 DOM 操作或者状态更新。

import React, { useLayoutEffect, useState, useRef } from 'react'; const ResponsiveComponent = () => { const containerRef = useRef(null); const [isWide, setIsWide] = useState(false); useLayoutEffect(() => { const container = containerRef.current; if (!container) return; const observer = new ResizeObserver(entries => { for (let entry of entries) { // 当容器宽度大于 300px 时，设置状态 if (entry.contentRect.width > 300) { setIsWide(true); } else { setIsWide(false); } } }); observer.observe(container); return () => observer.disconnect(); }, []); return ( <div ref={containerRef} style={{ width: '100%', border: '1px solid red', padding: '10px' }}> <div style={{ background: isWide ? 'lightblue' : 'lightgreen', padding: '10px', transition: 'background 0.3s' }}> 容器宽度大于 300px 吗？ {isWide ? '是' : '否'} </div> </div> ); };

不过，通常情况下，我们不需要这么麻烦。直接写 CSS@container就能解决 99% 的问题。这个 Hook 示例只是为了展示 React 和 CSS 结合的更多可能性。

第八部分：总结——拥抱真正的组件化

好了，老铁们，今天的讲座接近尾声。

回顾一下我们今天聊了什么：

1. 痛点：媒体查询（视口查询）让组件失去了自包含性，导致组件在不同父级下表现不一致。
2. 解药：容器查询。它让组件能够感知父容器的大小，从而做出响应。
3. 实战：我们用 React 和 styled-components 实现了一个能够根据容器宽度自动切换布局的文章卡片。
4. 进阶：我们讨论了 Tailwind 的支持，以及需要注意的容器尺寸问题。

为什么这很重要？

因为 React 的核心思想是“组件化”。一个优秀的组件应该是一个黑盒，它有自己的样式、逻辑和接口。当你把一个组件放在 A 地和 B 地时，它应该自动适应，而不需要你在外面给它套一层div或者写一堆@media。

容器查询，就是给了组件一双“眼睛”，让它能看清周围的世界。它让 CSS 从“布局语言”进化为“组件环境感知语言”。

最后，我的建议是：

从今天开始，在你的下一个 React 项目中，尝试抛弃那些为了适配屏幕而写的@media查询。试着把布局逻辑封装在组件内部，利用container-type和@container。

不要让你的组件成为“巨婴”，它应该是一个能够独立思考、适应环境的“小大人”。

好了，今天的课就上到这里。下课！记得去把你的代码改一改，别等到你的组件在侧边栏里丑哭了你才想起来看这篇文章！

谢谢大家！