响应式布局的核心诉求只有一句话：同一份HTML代码，在不同尺寸的屏幕上都要呈现出合理的排版。要实现这个目标，CSS提供了两个最基础的武器，一个是Flexbox弹性盒模型，负责在一维方向上灵活分配空间；另一个是媒体查询，负责在特定屏幕宽度下切换布局策略。这两者经常被初学者混为一谈，有人以为用了flex布局就自动响应式了，有人则把所有适配工作都堆给媒体查询，写出一大堆断点覆盖代码。本文将从原理、断点设计和实战案例三个层面，把两者的配合方式讲透。
一、Flexbox的核心原理：一维方向上的空间分配
要理解Flexbox在响应式布局中的角色，必须先弄清它的两个基本身份：容器和项目。给一个元素设置display: flex之后，它就成为flex容器，其直接子元素自动变成flex项目。容器上最常用的属性有三个：flex-direction决定主轴方向，justify-content决定项目在主轴上的对齐与分布方式，align-items决定项目在交叉轴上的对齐方式。
项目级别最重要的属性是flex，它是flex-grow、flex-shrink和flex-basis的缩写。很多教程推荐直接写flex: 1，这等价于1 1 0%，意思是项目可以等分剩余空间、允许收缩、基础宽度为零。这个写法在响应式场景中极为常用，比如左右两栏布局中让侧边栏固定宽度、内容区自动填满剩余空间，一行代码就能搞定，不需要任何媒体查询。
/* 经典的两栏布局：侧栏固定，内容自适应 */
.layout {
display: flex;
}
.sidebar {
width: 240px; /* 固定宽度 */
flex: none; /* 不参与伸缩 */
}
.main {
flex: 1; /* 填满剩余空间 */
min-width: 0; /* 防止内容撑破容器 */
}
上面代码里的min-width: 0是一个高频踩坑点。flex项目默认的min-width值是auto，当内容是一段长英文单词或者一个宽表格时，项目会被内容撑开，导致flex: 1失效、布局溢出。显式设置min-width: 0之后，项目才真正愿意收缩到比内容更窄。类似的问题还有flex-shrink的默认值为1，如果不希望某个项目被压缩，需要单独设置flex-shrink: 0。
另一个值得关注的属性是flex-wrap。默认情况下flex项目挤在一行里，空间不够时只会按比例缩小。开启flex-wrap: wrap后，放不下的项目会自动换行，这本身就是一种无需媒体查询的响应式能力。比如一组标签按钮，容器宽就多显示几个，窄了就自动换行，配合gap属性控制间距，几乎不需要写任何断点代码。
二、媒体查询的断点设计：以内容为准而不是设备为准
媒体查询的作用是在满足特定条件时应用一段样式，最常用的条件是屏幕宽度。但断点应该设在哪里，很多人存在误区——照抄某个手机、平板的分辨率。正确的思路是让内容决定断点：从桌面端开始逐步缩小浏览器窗口，观察布局在哪一个宽度开始变得难看、拥挤或者失衡，那个宽度就是断点位置。
主流的断点方案大致分为移动优先和桌面优先两种写法。移动优先的意思是默认样式针对小屏编写，然后用min-width向上扩展；桌面优先则相反，默认样式面向大屏，用max-width向下兼容。两种方式没有绝对优劣，但移动优先通常更符合渐进增强的理念，而且默认样式更简单，大屏增强的代码量往往比大屏拆解的代码量少。
/* 移动优先：默认单列布局，小屏样式直接写在基础规则里 */
.card-list {
display: flex;
flex-wrap: wrap;
gap: 16px;
}
.card {
flex: 1 1 100%; /* 小屏下每张卡片占满一行 */
}
/* 平板：两列 */
@media (min-width: 600px) {
.card {
flex: 1 1 calc(50% - 16px); /* 减去一个gap的一半 */
}
}
/* 桌面：三列 */
@media (min-width: 960px) {
.card {
flex: 1 1 calc(33.333% - 16px);
}
}
这段代码展示了Flexbox与媒体查询配合的经典模式：容器的display: flex和flex-wrap写一次就够了，媒体查询里只改动项目的flex-basis值。也就是说，布局骨架交给flex，断点切换交给媒体查询，两者各司其职，样式代码非常精简。如果不用flex，就得在每个断点里重写float或定位，代码量成倍增加。
断点数量也需要克制。一个常规的展示型页面，两到三个断点完全够用。断点过多意味着布局对宽度太敏感，后续维护成本直线上升。另外要注意calc中减去的gap值必须与实际间距一致，这里可以用CSS自定义变量统一管理，改间距时只改一处：
.card-list {
--gap: 16px;
display: flex;
flex-wrap: wrap;
gap: var(--gap);
}
@media (min-width: 600px) {
.card {
flex: 1 1 calc(50% - var(--gap));
}
}
三、实战案例：响应式导航栏的完整实现
导航栏是检验响应式功力的最佳案例，因为它涉及方向切换、空间挤压和交互变化三个维度。桌面端通常是横向排列的菜单，移动端则需要变成纵向堆叠或者收进一个汉堡按钮。下面给出一个不依赖JavaScript纯CSS切换的版本，借助checkbox技巧实现菜单展开：
<nav class="navbar">
<div class="brand">LOGO</div>
<input type="checkbox" id="menu-toggle" class="menu-toggle">
<label for="menu-toggle" class="menu-btn">菜单</label>
<ul class="nav-list">
<li><a href="#">首页</a></li>
<li><a href="#">产品</a></li>
<li><a href="#">关于</a></li>
</ul>
</nav>
<style>
.navbar {
display: flex;
flex-wrap: wrap;
align-items: center;
justify-content: space-between;
padding: 12px 20px;
}
.menu-toggle { display: none; } /* 大屏隐藏复选框本身 */
/* 移动端：菜单默认收起，纵向排列 */
.nav-list {
display: none;
flex-basis: 100%; /* 占满整行，换到第二行显示 */
}
.menu-toggle:checked ~ .nav-list {
display: flex;
flex-direction: column;
gap: 8px;
}
.menu-btn { display: block; }
/* 桌面端：横向菜单，隐藏菜单按钮 */
@media (min-width: 768px) {
.nav-list {
display: flex;
flex-direction: row;
gap: 24px;
flex-basis: auto;
}
.menu-btn { display: none; }
}
</style>
这个实现里有几个细节值得琢磨。第一，flex-basis: 100%配合外层容器的flex-wrap: wrap，让菜单列表强制换到导航栏的第二行，这是纯flex实现两行导航的技巧，省去了额外嵌套容器。第二，选择器.menu-toggle:checked ~ .nav-list利用了兄弟选择器，checkbox被勾选后展示菜单，无需JavaScript。第三，桌面端断点里只做了三件事：显示菜单、改回横向、隐藏按钮，改动量极小，这正是flex布局打底带来的好处。
四、什么时候用弹性伸缩，什么时候必须切断点
最后回到一个判断层面的问题：并非所有响应式需求都要写媒体查询，也并非flex能包打天下。经验法则是这样的：如果布局变化只是空间分配比例的变化，比如三列变两列、侧栏变窄，优先考虑flex的伸缩能力和flex-wrap换行；如果布局发生了结构性的变化，比如横向导航变纵向、侧栏消失、元素顺序调换，那基本绕不开媒体查询。
元素顺序调换这个场景值得单独说。flex提供了order属性可以调整项目显示顺序，配合媒体查询就能实现移动端与桌面端内容顺序不同，比如桌面端图片在左文字在右，移动端图片优先展示在上方，HTML结构完全不用动：
.media {
display: flex;
gap: 24px;
}
.media .text { order: 2; }
.media .image { order: 1; }
@media (max-width: 767px) {
.media { flex-direction: column; }
.media .image { order: 1; } /* 移动端图片在上 */
}
此外还要留意容器查询这个新趋势。传统的媒体查询只能针对视口宽度判断，而容器查询可以针对父容器的宽度应用样式，同一张卡片在宽容器里横排、窄容器里竖排，即使是动态插入的组件也能正确适配。新项目可以在支持度允许的前提下尝试用容器查询替代一部分媒体查询，但在当前阶段，Flexbox加媒体查询依然是响应式布局最稳妥、兼容性最好的组合方案。
CSS Flexbox媒体查询响应式布局修改时间：2026-09-13 00:22:43