流式布局是响应式的基础，媒体查询只是增强手段；必须先用max-width、百分比和rem构建可伸缩基础，再用@media解决列数变化等结构性适配问题。
流式布局是响应式的基础，媒体查询是它的增强手段；不先做好流式，光靠媒体查询堆断点只会让样式越来越难维护。
为什么不能只靠 @media 做响应式
很多人一上来就写一堆 @media (min-width: 768px)、@media (min-width: 1024px)，结果发现小屏样式崩了、中屏文字挤成一团、大屏留白太多——问题不在断点数量，而在基础布局没“流”起来。
- 媒体查询本身不改变元素尺寸逻辑，它只是“在某个视口宽度下换一套样式”
- 如果基础样式里还用
width: 960px、padding: 20px这类固定值，那无论加多少@media，都只是在补洞 - 真实设备的视口宽度是连续变化的（比如 iPhone 15 Pro Max 横屏是 932px，折叠屏展开可能到 1200px+），靠几个离散断点覆盖不完
max-width + 百分比 + rem 是流式布局的铁三角
真正让页面“跟着屏幕缩放”的，是这三样配合使用的默认行为：
-
max-width: 1200px控制内容区最大宽度，避免桌面端无限撑开 -
width: 100%让容器始终占满可用空间（注意：要配合box-sizing: border-box） - 内边距、字体、间距统一用
rem或em，再通过根字体大小动态调整（例如用html { font-size: calc(16px + 0.25vw); }）
示例：
立即学习“前端免费学习笔记（深入）”；
.container {
width: 100%;
max-width: 1200px;
margin: 0 auto;
padding: 0 1rem;
box-sizing: border-box;
}
这段代码在 320px 宽的手机上自动收缩，在 1440px 的笔记本上停在 1200px，中间所有尺寸平滑过渡——根本不需要媒体查询。
什么时候该加 @media？只解决流式搞不定的事
媒体查询不是“适配屏幕”，而是“适配内容结构”。它该出现在以下明确场景：
- 列数变化：比如移动端单列，平板双列，桌面三列 —— 用
@media (min-width: 768px)切换display: flex的flex-wrap或grid-template-columns - 交互模式切换：触摸优先的按钮尺寸、隐藏/显示侧边栏、折叠导航菜单
- 图片或视频尺寸策略变更：小屏用
object-fit: cover裁剪，大屏用contain完整展示 - 字体层级重排：小屏标题用
1.5rem，大屏升到2.25rem并加粗
关键判断标准：这个改动是否改变了信息组织方式，而不是仅仅调大了字号或边距？ 如果答案是否定的，大概率不该进 @media。
断点设置最容易踩的三个坑
断点不是设备尺寸表，也不是设计师给的“iPad Pro 宽度”，它必须从内容出发：
- 别用
@media (max-width: 767px)和@media (min-width: 768px)做“移动/平板”二分——768px 是 iPad 竖屏宽度，但很多安卓大屏手机横屏也超 768px，结果触发了平板样式却操作不便 - 避免“像素陷阱”：不要硬写
@media (min-width: 1024px)，改用内容驱动的断点，比如当卡片宽度超过30em就转双列，写成@media (min-width: 30em) - 别漏掉
orientation：iPad 横屏时视口宽高反转，仅靠宽度断点会失效，必要时加and (orientation: landscape)
真正稳定的断点往往藏在内容里：一段文字开始换行不自然了、一个按钮被截断了、两列卡片之间空隙过大了——这时候才是加 @media 的信号。
