1. 从CSS到styled-components：媒体查询的写法变化与核心语法

如果你用过 styled-components，第一次在里面写媒体查询时大概率会愣一下：平时在 CSS 文件里写 @media (max-width: 768px) 写习惯了，到了模板字符串里，总觉得哪里不对。确实，styled-components 作为 CSS-in-JS 的代表方案，虽然语法上和 CSS 高度兼容，但媒体查询的嵌套规则、选择器优先级和字符串插值方式都和我们熟悉的写法有微妙差异。这篇文章我直接结合项目经验，把 styled-components 中媒体查询的用法、断点管理、工具函数封装和常见的坑一次讲透。

先说核心语法。在 styled-components 中，你实际上是在 JavaScript 的模板字符串里书写 CSS，而这个模板字符串最终会被解析成真实的 CSS 样式规则。所以 @media 规则本身并不需要额外处理，直接写在里面就可以。但问题是，你得理解它和"普通 CSS 里的嵌套"之间的关系。

1.1 最基础的写法：直接把 @media 塞进模板字符串

假设你有一个按钮组件，希望在手机端做成全宽，在桌面端保持自适应宽度。传统 CSS 的写法是这样的：

.btn { padding: 12px 24px; font-size: 14px; } @media (max-width: 768px) { .btn { width: 100%; } }

换成 styled-components，最常见的写法是这样：

import styled from 'styled-components'; const Button = styled.button` padding: 12px 24px; font-size: 14px; @media (max-width: 768px) { width: 100%; } `;

就是这么简单。@media 查询直接嵌套在组件样式内部，作用域天然隔离在这个组件上，不会像传统 CSS 那样需要靠类名避免全局污染。这里唯一需要留意的点是：如果你在 styled-components 里想写"组件自身"的选择器，用的是&，代表当前组件根节点。而媒体查询内部的规则会默认作用在当前选择器下。

const Card = styled.div` background: #fff; @media (max-width: 768px) { padding: 16px; } `;

上面的 @media (max-width: 768px) 里的 padding 会被应用在 .Card 元素上，不需要额外写类名或者元素选择器。这一点和 Sass 的嵌套写法很像，熟悉预处理器的人几乎零成本上手。

1.2 模板字符串里的 @media 为什么不生效

我见过不少人写过这样的代码，然后发现媒体查询完全不生效：

const Button = styled.button` padding: 12px 24px; font-size: 14px; @media (max-width: 768px) { width: 100%; } `;

其实这段代码在 styled-components 里是能生效的，HTML 样式和上面的示例是一样的。真正的问题往往出在另一处：有人把媒体查询写成了这样：

const Button = styled.button` padding: 12px 24px; font-size: 14px; `; Button.extend` @media (max-width: 768px) { width: 100%; } `;

这种老式的 .extend 写法在较新版本中已经不推荐了，而且如果你在极端的嵌套场景下使用，继承关系和优先级会非常乱。正规做法是用 styled(Button) 这种方式派生新组件，或者直接把媒体查询写在组件定义内部，而不是分离在外部再扩展一份。

另外一个常见误区是有人试图在媒体查询里选择子元素时搞错了&的语义。比如：

const Nav = styled.nav` @media (max-width: 768px) { & ul { display: none; } } `;

这里的&代表 Nav 本身，& ul代表 Nav 内部的 ul，所以上述写法是正常的。如果写成：

const Nav = styled.nav` @media (max-width: 768px) { ul { display: none; } } `;

虽然从 CSS 解析来看编译结果都一样（最终都会被编译成 .Nav ul），但在语义表达上& ul更清晰。而且在 styled-components 内部，选择器只是字符串拼接，稍微不注意就会把嵌套层级搞错。

理解了这个基础之后，你其实已经能应付 80% 的日常需求了。但真正的问题在于，项目一旦上了规模，你不可能在每个组件里都写魔法值 768px、992px，那样不仅维护成本高，而且非常容易写错。下一节我直接讲我在工程里常用的断点管理模式。

2. 断点规划：先定四档位再动手写样式

媒体查询本身不复杂，复杂的是"一套响应式设计整体怎么组织"。我在多个 React 项目里总结出来的经验是：不管项目大小，动手前一定先把断点定下来。断点定得越早，后面写起来越顺。

2.1 移动优先还是桌面优先

这是响应式设计里一个绕不开的决策点。移动优先意味着基准样式是手机端，然后用min-width逐级增强：

/* 移动优先 */ .component { padding: 12px; } @media (min-width: 768px) { .component { padding: 24px; } }

桌面优先则相反，基准样式是桌面端，用max-width做降级：

/* 桌面优先 */ .component { padding: 24px; } @media (max-width: 767px) { .component { padding: 12px; } }

在 styled-components 里如何选择？我个人的建议是：如果没有特殊理由，优先选择移动优先（min-width）策略。原因有两个。第一，从 CSS 层叠的角度看，min-width 方式下后写的样式自然覆盖先写的样式，符合"从窄到宽、逐级增强"的直觉，心智负担小；第二，移动端流量占比已经非常高，把移动端作为基准样式会让首屏渲染的 CSS 更精简，不需要额外加载一堆降级样式后再覆盖。

当然，如果你维护的本来就是后台管理系统，用户在桌面端的比例极高，那桌面优先完全合理。不要盲目跟风，根据产品形态决定。

2.2 断点常量定义与 ThemeProvider 集成

断点定了之后，紧接着的问题就是"这些数字写在哪"。我见过最差的实践是每个组件里写死 768px、992px，某个设计稿一改，全局搜索替换，改到崩溃。更好的做法是集中管理断点，并通过 styled-components 的 ThemeProvider 注入到每个组件中。

定义一份断点表：

// theme/breakpoints.js const breakpoints = { xs: '0px', sm: '576px', md: '768px', lg: '992px', xl: '1200px', }; export default breakpoints;

然后在 theme 对象里挂上去：

// theme/index.js import breakpoints from './breakpoints'; const theme = { colors: { primary: '#2D6CDF', text: '#333333', }, breakpoints, }; export default theme;

在应用入口用 ThemeProvider 包裹：

import { ThemeProvider } from 'styled-components'; import theme from './theme'; function App() { return ( <ThemeProvider theme={theme}> <MainContent /> </ThemeProvider> ); }

接下来在组件里就可以这样用：

const Button = styled.button` width: 100%; @media (min-width: ${props => props.theme.breakpoints.md}) { width: auto; } `;

这样一来，断点数字就不会散落在项目各处了。要说的是，虽然width: 100%这种属性和后面width: auto在视觉上形成切换效果，但代码里已经埋入了主题变量，维护性比硬编码好太多。

如果你再懒一点，连每次写props => props.theme.breakpoints.md都嫌啰嗦，那可以直接解构：

const Button = styled.button` width: 100%; @media (min-width: ${({ theme }) => theme.breakpoints.md}) { width: auto; } `;

到这里，断点已经有了一套基础管理模式。但说实话，如果每个组件都要这样写一长串插值表达式，依旧不够优雅。接下来我会分享一个更推荐的方案——把媒体查询封装成工具函数。

3. 把媒体查询封装成工具函数，彻底告别样板代码

styled-components 的媒体查询写多了之后，你会发现每个断点其实就那几种写法：在 min-width 或 max-width 下覆盖若干属性。既然如此，完全可以把这些重复代码抽象成函数。这里我按由浅入深的方式，给你三档封装方案。

3.1 最小封装：一个函数生成完整的媒体查询块

最偷懒但也很实用的思路是：写一个工具函数，接收断点名，返回一个可以直接插入模板字符串的字符串片段。

// utils/media.js import { css } from 'styled-components'; const breakpoints = { sm: '576px', md: '768px', lg: '992px', xl: '1200px', }; export const media = { sm: (...args) => css`@media (min-width: ${breakpoints.sm}) { ${css(...args)} }`, md: (...args) => css`@media (min-width: ${breakpoints.md}) { ${css(...args)} }`, lg: (...args) => css`@media (min-width: ${breakpoints.lg}) { ${css(...args)} }`, xl: (...args) => css`@media (min-width: ${breakpoints.xl}) { ${css(...args)} }`, };

这里我把 styled-components 的 css helper 引了进来，它和普通模板字符串有什么不同？css helper 会返回一个 tagged template 的解析结果，而非纯字符串。它最大的好处是：支持在内部继续嵌套插值，并且嵌套的插值也能被正确解析成 CSS，不会出现字符串拼接导致的选择器丢失问题。

用法如下：

import styled from 'styled-components'; import { media } from '../utils/media'; const GridContainer = styled.div` display: grid; grid-template-columns: 1fr; gap: 16px; ${media.md` grid-template-columns: 1fr 1fr; `} ${media.lg` grid-template-columns: 1fr 1fr 1fr; `} `;

对比之前冗长的@media (min-width: ${props => props.theme.breakpoints.md})，现在代码简洁多了，而且每个断点表达得非常直观。这个方案适合中小型项目，也是我早期项目里用的方案。

3.2 进阶封装：把 theme 里的断点也接进来

上面的方案有个小问题：断点硬编码在 media.js 里，如果组件里同时用了 ThemeProvider 里的其他主题变量，就会出现断点来源不一致的情况。更进一步的做法是让 media 工具直接读取 theme 配置。

// utils/media.js import { css } from 'styled-components'; const media = { sm: (...args) => css` @media (min-width: ${({ theme }) => theme.breakpoints.sm}) { ${css(...args)} } `, md: (...args) => css` @media (min-width: ${({ theme }) => theme.breakpoints.md}) { ${css(...args)} } `, // ... }; export default media;

注意这里有一个细节：${({ theme }) => theme.breakpoints.sm}是作为插值函数被 styled-components 处理的，它会等到渲染时才读取主题对象。这意味着 media 工具是"响应式"的——如果你的应用在运行中切换主题（比如深浅色切换），断点值也能跟着切换。

这种封装方式的缺点是调用时代码略有一点噪音，因为它接受的是 rest 参数，内部再包一层 css。但实际用起来和上一版相似，组件内部写起来依然是干净的：

const Hero = styled.section` padding: 20px; ${media.lg` padding: 48px 64px; `} `;

3.3 高阶封装：支持复杂的 min + max 复合条件

真实业务里有时候要写(min-width: 768px) and (max-width: 991px)，这种"平板专属"或者"中档位专属"的媒体条件很常见。如果每个组件里都是手写@media (min-width: 768px) and (max-width: 991px)，那确实挺麻烦。

我后来在项目里用了更完整的封装，支持命名断点和区间范围：

// utils/media.js import { css } from 'styled-components'; const breakpoints = { sm: 576, md: 768, lg: 992, xl: 1200, }; export const from = { sm: (...args) => css`@media (min-width: ${breakpoints.sm}px) { ${css(...args)} }`, md: (...args) => css`@media (min-width: ${breakpoints.md}px) { ${css(...args)} }`, lg: (...args) => css`@media (min-width: ${breakpoints.lg}px) { ${css(...args)} }`, xl: (...args) => css`@media (min-width: ${breakpoints.xl}px) { ${css(...args)} }`, }; export const between = { smAndMd: (...args) => css`@media (min-width: ${breakpoints.sm}px) and (max-width: ${breakpoints.md - 1}px) { ${css(...args)} }`, mdAndLg: (...args) => css`@media (min-width: ${breakpoints.md}px) and (max-width: ${breakpoints.lg - 1}px) { ${css(...args)} }`, }; export const upTo = { sm: (...args) => css`@media (max-width: ${breakpoints.sm - 1}px) { ${css(...args)} }`, md: (...args) => css`@media (max-width: ${breakpoints.md - 1}px) { ${css(...args)} }`, lg: (...args) => css`@media (max-width: ${breakpoints.lg - 1}px) { ${css(...args)} }`, };

命名上我习惯把 min-width 语义称为 from（从某个宽度起），max-width 语义称为 upTo（直到某个宽度止），区间语义称为 between。这样在阅读组件代码的时候，意图非常清晰：

const Panel = styled.div` ${between.mdAndLg` display: flex; flex-direction: column; `} `;

这比看一长串@media (min-width: 768px) and (max-width: 991px)要轻松得多。封装之后的语义化能力在团队协作里尤其重要——新同事看两分钟就能明白这套写法，而不是去逐个断点猜数字。

3.4 为什么不建议用 CSS 变量来做断点

写到这里顺手提一个很多人纠结的问题：既然 styled-components 支持 CSS 变量（custom properties），为什么不用--breakpoint-md: 768px这种方案？

我的看法是，CSS 变量擅长的是"值的复用"，不擅长"查询条件的拼接"。虽然你在 @media 里确实可以写@media (min-width: var(--breakpoint-md))，现代浏览器也能解析，但这有几个现实问题。第一，CSS 变量的生效依赖于元素继承和运行时环境，如果变量挂在 :root 上还好，一旦被某个组件覆盖了局部变量，查询结果会随之变化，这种隐式耦合很难排查。第二，styled-components 的 theme 机制本身就是 React 层面的依赖注入，走 ThemeProvider 是最顺手的路径，完全没有必要再引入一套 CSS 变量体系来增加认知负担。

工具函数封装到这里，其实已经足够应付绝大多数项目了。接下来我用几个真实业务场景把写法串起来看，这样你会知道这些封装在真实组件里长什么样。

4. 真实业务场景拆解：导航栏、卡片栅格、表单的响应式写法

工具封装是手段，最终落在业务组件里。这里我挑三个最常见的场景，把代码和设计思路都过一遍。

4.1 导航栏：桌面横排，移动端折叠

导航栏是我认为最能体现响应式设计的场景。桌面端横向排列菜单项，移动端则收起一部分导航，只显示核心入口。用 styled-components 写导航的基本结构如下：

import styled from 'styled-components'; import { from } from '../utils/media'; const NavContainer = styled.nav` display: flex; flex-direction: column; padding: 16px; ${from.md` flex-direction: row; justify-content: space-between; align-items: center; padding: 16px 32px; `} ${from.lg` padding: 20px 48px; `} `; const NavLinks = styled.ul` display: none; list-style: none; margin: 0; padding: 0; ${from.md` display: flex; gap: 24px; `} `;

关键设计思路是什么？移动端基准样式里我把 flex-direction 设为 column，菜单列表display: none——在这里你可能需要配合一个汉堡按钮或者菜单开关来切换显隐。等屏幕到 md 断点（即 768px），再切换为 row 布局，并让菜单显示出来。

这个写法的好处是，媒体查询只负责"切换布局表现"，而"汉堡菜单开关的状态"完全交给 React 侧的 useState 管理，两者各司其职。如果你在 styled-components 里看到有人把 display 切换的 class 也写进媒体查询，那种做法通常是把状态管理和样式耦合在一起了，不是很好的信号。

4.2 响应式卡片栅格：从单列到多列

卡片列表是后台系统、电商前台里最高频的组件之一。用 Grid 布局配合媒体查询，代码非常简洁：

import styled from 'styled-components'; import { from } from '../utils/media'; const CardGrid = styled.div` display: grid; grid-template-columns: 1fr; gap: 16px; ${from.sm` grid-template-columns: repeat(2, 1fr); `} ${from.md` grid-template-columns: repeat(3, 1fr); gap: 24px; `} ${from.lg` grid-template-columns: repeat(4, 1fr); gap: 32px; `} `;

这段代码的逻辑是：默认单列，576px 起两列，768px 起三列，992px 起四列。配合上面的移动优先策略，每一级断点只是覆盖 grid-template-columns 和 gap，不会影响其他属性。

有一个细节值得注意：repeat(4, 1fr)在容器宽度到达 1200px 之后，卡片会拉得特别宽。如果你希望卡片有最大宽度限制，可以在卡片内部设置 max-width，或者干脆用repeat(auto-fit, minmax(240px, 1fr))这种自动填充写法。后者不需要在媒体查询里反复改列数，适合卡片宽度相对固定的场景。两种方案各有优劣，栅格列数固定时用前者视觉更整齐，自动填充时更灵活。

4.3 表单按钮：移动端全宽，桌面端自适应

表单里有一个很经典的响应式需求：提交按钮在手机上要容易点击，通常全宽；在桌面端不需要那么夸张，自适应内容宽度即可。

import styled from 'styled-components'; import { from, upTo } from '../utils/media'; const SubmitButton = styled.button` width: 100%; padding: 14px 24px; font-size: 16px; border: none; border-radius: 6px; background-color: ${({ theme }) => theme.colors.primary}; color: #fff; cursor: pointer; ${from.md` width: auto; min-width: 160px; `} ${upTo.sm` font-size: 18px; padding: 16px; `} `;

上面这个例子同时用到了 from 和 upTo 两种工具。移动端基准里按钮是全宽；到 md 断点以上，宽度回到 auto；而 upTo.sm 则额外处理小屏下字体的可读性。这种写法把"窄屏下的增强"也纳入到媒体查询里，逻辑上更加完整。

这里顺便提到一个经验：移动端点按区域不要小于 44px 乘 44px。如果你用 padding 撑大了按钮，又在小屏里缩小了 padding，注意别让可点击区域缩得太小。这是很多设计师容易忽略、前端实现时也容易妥协的点，但对用户操作体验影响很大。

4.4 侧边栏布局的响应式设计

除了上面几个组件级别的例子，页面布局层面也常用媒体查询。比如改造成本最低的"顶部导航 + 内容区"结构，在桌面上希望侧边栏固定，在移动端则把侧边栏隐藏或推入抽屉。

const Layout = styled.div` display: flex; flex-direction: column; ${from.lg` flex-direction: row; `} `; const Sidebar = styled.aside` display: none; ${from.lg` display: block; width: 240px; flex-shrink: 0; `} `; const Main = styled.main` flex: 1; min-width: 0; padding: 16px; ${from.md` padding: 24px; `} `;

min-width: 0这个小细节值得说一句。它是为了配合 flex 弹性布局，避免内容宽度超出容器时被撑破。很多布局 bug 就是因为忘了这一行而出现的。在 styled-components 里写的时候，照样要记得这些基础 CSS 陷阱，不能因为是 CSS-in-JS 就觉得万事大吉。

5. 媒体查询在生产环境里最容易踩的四个坑

工具用得再熟练，真到了大项目里还是会遇到各种诡异问题。这一节我把我踩过的、以及帮别人排查过的典型问题集中写一下，希望能帮你避开。

5.1 优先级冲突：为什么我写的样式被其他规则覆盖

styled-components 在编译后会为每个组件生成一个带哈希的类名，正常情况下不同组件的样式不会互相干扰。但有一种情况很容易出问题：组件继承。看下面的代码：

const BaseButton = styled.button` padding: 12px 24px; background: #f0f0f0; `; const PrimaryButton = styled(BaseButton)` background: ${({ theme }) => theme.colors.primary}; @media (min-width: 768px) { padding: 16px 32px; } `;

这里 PrimaryButton 继承自 BaseButton。由于 styled-components 在生成样式时，继承组件的样式规则会放在前面，派生组件的规则会放在后面，所以正常情况下背景覆盖没问题。但如果你的 BaseButton 里也写了一堆媒体查询，派生组件里又在同样的媒体查询条件下覆盖属性，并且 BaseButton 的选择器特异性更高（比如用到了&::before之类的伪元素），那就可能发生覆盖异常。

排查这种问题时，不要在浏览器里对着 devtools 猜。打开 Elements 面板找到元素，看看它实际带上的类名，然后去检查 styled-components 注入到<head>里的 style 标签，对比规则顺序和优先级。通常 90% 的优先级问题都能从这里看到原因。

5.2&的歧义：嵌套选择器里写媒体查询

&在 styled-components 里代表父选择器，但它在不同位置的展开结果完全不同。举个例子：

const Dropdown = styled.div` .menu { display: none; } @media (max-width: 768px) { .menu { display: block; } } `;

这个写法没有问题：.menu会编译成.Dropdown .menu。但如果我写成：

const Dropdown = styled.div` .menu { display: none; @media (max-width: 768px) { display: block; } } `;

结果也一样，但问题来了：如果你在.menu的媒体查询里要引用 Dropdown 的相邻兄弟节点，&就不够用了。比如有的人会写：

const Dropdown = styled.div` .menu { @media (max-width: 768px) { & + .icon { transform: rotate(180deg); } } } `;

这里的&指向的是.menu而不是.Dropdown。这是一个非常隐蔽的坑：&永远指"当前这条规则的最外层选择器"。如果嵌套越深，&的语义越容易混淆。我的建议是，如果媒体查询里涉及到多个层级的选择器关系，干脆展开写在组件根层的媒体查询里，不要继续嵌套到子元素规则里面。层级越浅越安全，读起来也越容易。

5.3 团队协作中断点变量命名混乱

断点命名混乱的问题，在大项目里比技术问题更致命。有人用 sm/md/lg，有人用 phone/tablet/desktop，还有人用 xs/s/l/xl，混在一起后代码 review 都不得安宁。我建议团队里约定一套命名词典，并且把这个约束落到代码里，而不只是口头约定。

推荐的做法是：在阅读性上下点功夫。xs、sm、md 这些缩写对新人不太友好，尤其是他们要结合设计稿的响应式规则时。你可以用fromMobile、fromTablet、fromDesktop这种语义化命名。虽然代码长一点，但任何人读起来都不需要查表。

也可以把断点命名直接映射成数字档位，让设计师和开发共用一份协议。比如设计稿里写"breakpoint A/B/C"，代码里就定义：

const breakpoints = { A: 360, B: 768, C: 1200, };

定一次，团队所有人照此执行，比什么都强。

5.4 打包体积和渲染性能：在 styled-components 里写媒体查询会变慢吗

这是很多团队在技术选型时反复纠结的问题。直接说结论：styled-components 的运行时开销与样式定义数量正相关，与媒体查询的写法关系不大。也就是说，你把媒体查询写在组件内部和写在全局 CSS 文件里，对性能的影响差异可以忽略不计。

真正需要留意的是不要在组件渲染热路径里动态生成样式。比如下面这种写法：

const Badge = styled.div` @media ${(props) => `(min-width: ${props.width}px)`} { width: ${(props) => props.width}px; } `;

width 是运行时 prop，每次渲染都会生成全新的媒体查询字符串，这会让 Babel 插件和 styled-components 的缓存完全失效，每次渲染都重新生成样式标签。在复杂页面里会明显感受到卡顿，尤其是列表中渲染大量这种组件时。

正确做法是：媒体查询条件尽量保持静态，变化的只是样式值。如果你确实需要响应式地改变某个尺寸，优先考虑内联样式或者 CSS 变量来承载动态值，而媒体查询结构本身保持稳定。

另一个性能相关的点是：styled-components 会把每个组件的样式以标签形式插入到<head>里。组件越多，style 标签越多。开发环境还好，生产构建后样式会统一抽离成 CSS 文件，就不太需要担心了。但如果你的项目用的是 React 18 + SSR，并且首屏要求极高，可以去了解 styled-components 的ServerStyleSheetAPI，避免 CSR 和 SSR 样式不一致导致的闪屏。

提示：在 styled-components 里尽量保持媒体查询结构静态，把"动态部分"放在样式值里，这样既能享受主题能力，又能保住性能底线。

6. 从组件里抽离响应式策略：当更复杂的业务出现时

你以为掌握了上面这些就够了吗？对大多数项目确实够了，但遇到过几种更复杂的业务场景，值得单独提出来。当响应式策略高度重复、或者业务规则和样式规则纠缠不清时，可以考虑把媒体查询从 styled-components 里抽离出来。

第一个场景是"同一个组件在不同页面有不同响应式表现"。比如 ArticleCard 在首页列表里用四列栅格，在专题页里用两列。直接的做法是给组件传一个dense或variant属性，然后在样式里做分支。但 props 分支写多了，组件样式会越堆越厚。更清爽的做法是用styled(ArticleCard)在页面层级做覆盖：

const FeaturedCard = styled(ArticleCard)` ${from.lg` grid-template-columns: repeat(2, 1fr); `} `;

这样页面关注页面的布局策略，组件关注组件自身的基础样式，彼此不会污染。

第二个场景是"媒体查询和业务逻辑需要联动"。比如移动端要隐藏搜索框、显示搜索图标，桌面端则展示完整搜索框。这个"显隐规则"同时涉及样式（display）和状态（input focus），纯粹用媒体查询写没问题，但要联动的话，就需要在 React 侧也判断当前屏幕宽度。常见方案是写一个 useMediaQuery 的 hook，把媒体查询结果交给 JS 逻辑：

import { useState, useEffect } from 'react'; function useMediaQuery(query) { const [matches, setMatches] = useState( () => window.matchMedia(query).matches ); useEffect(() => { const mql = window.matchMedia(query); const handler = (e) => setMatches(e.matches); mql.addEventListener('change', handler); return () => mql.removeEventListener('change', handler); }, [query]); return matches; } // 使用 const isMobile = useMediaQuery('(max-width: 767px)');

这个 hook 和 styled-components 并不冲突。你完全可以先用 styled-components 处理大部分纯样式层面的响应式，再用这个 hook 处理需要联动的业务逻辑。如果项目里引入了 useMediaQuery 的库，思路也是一样的。

第三个场景是"将媒体查询策略抽成配置对象"。这种通常出现在低代码配置平台或中后台的区块配置系统里。每个区块的布局策略都写在配置里：

const layoutStrategy = { default: { cols: 1, gap: 16 }, md: { cols: 2, gap: 24 }, lg: { cols: 4, gap: 32 }, };

然后通过一个工具函数把它解析成 styled-components 的样式字符串。这种做法虽然没有直接在组件里写媒体查询直观，但在配置驱动的系统里维护性极高。如果你的项目正往低代码方向走，可以考虑这种思路。

说白了，styled-components 的响应式方案没有银弹。组件数量少的时候怎么写都行，组件多了就需要纪律和模式规范。上面这些方案本质上是"用工具约束代码组织的复杂度"，具体选哪个，取决于你的团队规模、业务类型和既有代码风格。

我自己的项目实践里，最常用的是 breakpoints 常量加 from/between 工具函数那一套。它让我在写组件样式时不需要到处复制媒体查询字符串，又能像写普通 CSS 一样思考断点。如果你正在做一个从零开始的 React 项目，建议直接把这一套搭起来，后面会省很多麻烦。