前端开发教程：手把手带你搭建响应式网站
每次有人问我"响应式网站到底怎么做"，我都不太愿意直接甩出三段媒体查询。不是藏私，而是因为如果你把响应式理解成"在 768px 和 1024px 各写一套样式"，那你学到的其实是十几年前的手艺，而不是 2026 年该有的做法。
我的观点很直接：今天做响应式，重点早就不在"适配设备"，而在"设计一套会自己妥协的布局规则"。设备只是结果，规则才是你要交付的东西。下面这篇教程，我按自己真实的工作顺序走一遍，它更像一次带路的散步，而不是一张检查清单。
一、断点不是设备清单，而是内容撑不住的那一刻
大多数教程的第一步是"先规划断点：手机 375、平板 768、桌面 1440"。我建议把这一步往后挪，先做另一件事：把内容按重要性排一遍序。
理由很简单。断点的本质，是"当可用宽度不足以舒服地容纳当前内容时，重新分配空间"的决策点。既然决策依据是内容，答案就只能从内容里长出来，而不是从某款流行手机的像素宽度里抄过来。
具体做法是：把页面缩到很窄，然后慢慢拉宽，眼睛盯着内容本身——句子什么时候长到一行放不下，卡片什么时候窄到读起来费劲，导航什么时候挤成一团。这些"难受的瞬间"就是你的断点。它们可能是 430px，可能是 611px，也可能是 1180px，无所谓，因为它们回答的是真问题。
还有一个我越来越坚持的原则：能不断点就不不断点。先用弹性布局把空间吃掉，只在真的撑不住时才引入断点。断点越少，维护成本越低，也越不容易在某个奇怪的尺寸上出丑。
二、让尺寸自己呼吸：流体排版与 clamp()
过去我们习惯写 font-size: 24px，再在断点里改成 32px。结果是文字在断点之间永远是某个固定值，宽一点显得小，窄一点显得挤。更好的方式是把尺寸交给视口，用 clamp() 给它划一条底线和一条上限。
css :root { --step-0: clamp(1rem, 0.95rem + 0.25vw, 1.125rem); --step-2: clamp(1.5rem, 1.2rem + 1.6vw, 2.5rem); --gutter: clamp(1rem, 4vw, 3rem); --measure: 68ch; }
这几行几乎是我每个项目的模板：正文、标题、间距、内边距，全都变成流体值。注意 clamp 的中间项我用的是 rem 与 vw 的混合，而不是纯 vw——纯 vw 会让文字在窄屏上缩到不可读，混合写法则既跟随视口，又尊重用户自己调过的字号。
布局层面同理。与其写"桌面四列、平板两列、手机一列"，不如写一行：
css .grid { display: grid; gap: var(--gutter); grid-template-columns: repeat(auto-fit, minmax(min(280px, 100%), 1fr)); }
这一行就完成了从一列到多列的全部过渡，中间没有任何断点。这就是所谓"内在响应式"（intrinsic web design）：你把规则写清楚，让浏览器去算，而不是你替所有屏幕提前算一遍。
三、容器查询：让组件拥有自我意识
如果说这几年响应式最大的观念转变是什么，我会说是从"页面响应式"走向"组件响应式"。
过去的媒体查询问的是"视口有多宽"。可问题在于，同一个卡片组件，放在侧边栏里和放在主内容区里，可用宽度完全不同，视口却可能一模一样。于是你被迫写一堆 .sidebar .card、.main .card 之类的上下文选择器，脆弱又难读。
容器查询改变的就是这件事。它让组件能问"我被放进了一个多宽的容器"，然后自己决定长相：
css .card-wrap { container-type: inline-size; }
.card { display: flex; flex-direction: column; }
@container (min-width: 30rem) { .card { flex-direction: row; align-items: center; } }
这个小小的 @container 背后是一次权责转移：页面层不再负责告诉组件该长什么样，组件自己知道。对设计系统来说这是质变——你终于可以交付一个"放哪儿都合适"的组件，而不是一份附带十五个使用场景说明的说明书。
2026 年的今天，容器查询早已不是什么前沿实验特性，主流浏览器都稳稳支持。我甚至觉得，如果一个响应式教程到现在还不讲容器查询，那它已经落后了。
四、被忽视的另一半：图片、字体与性能
布局做得再漂亮，如果首屏是一张两兆的大图，用户的体验依然是灾难。响应式的隐形一半在资源上。
图片要给它多个候选，让浏览器根据视口和像素密度自己挑：
html
这里有几个细节值得说：width 和 height 一定要写，即使图片本身是自适应的——它们让浏览器提前算出宽高比，避免布局抖动；loading='lazy' 只用在首屏之外的图上；格式优先 AVIF，退到 WebP，再退到 JPEG。
字体同理。一套动辄几百 KB 的中文字体，是移动端性能的隐形杀手。我的做法是：标题用可变字体并按 unicode-range 切片，正文干脆用系统字体栈，把预算省下来给真正重要的东西。加载策略上，font-display: swap 配合关键字体 preload，基本能兼顾"不空白"和"不错版"。
五、最后一道关：可访问性与真机测试
响应式做到最后，绕不开两件事：键盘和网络。
很多人测试响应式的方式是"把浏览器窗口拉窄"，这只验证了一半。真正该做的：用键盘 Tab 走一遍，确认窄屏下导航抽屉打开后焦点被正确锁住；打开系统的"减少动态效果"，确认你的过渡动画会优雅降级；把字号调到 200%，确认布局不塌；再切到弱网加慢速 CPU，看看首屏多久能读出第一行字。
这些检查听起来琐碎，但它们其实都在问同一个问题——"当条件变差时，我的页面还体面吗？"响应式的本质，就是不断回答这个问题。
六、把它们串起来：一个最小可用骨架
讲了这么多原则，落到代码上其实很短：
html
这里面没有一行是为某个具体设备写的。所有规则都在描述"内容与空间的关系"，剩下的交给浏览器。这也正是我想说的：好的响应式代码读起来像设计规范，而不像设备适配表。
结语：响应式是一种态度，不是一张清单
回头看，这篇文章写的是布局，其实说的是取舍。
从"给每种设备写一套样式"，到"写一套能适应所有设备的规则"，这中间变化的不是工具，而是姿态。前者假设你能穷举所有情况——在折叠屏、车机屏幕、AR 眼镜、手表表盘轮番出现的 2026 年，这个假设早就不成立了。后者承认自己不可能穷举，于是把决策权交给更聪明的规则，和更懂上下文的浏览器。
所以，如果这篇教程只能留给你一句话，我希望是这句：不要问"我的网站在手机上长什么样"，要问"我的网站在空间不够时，会怎么让步"。想清楚这个问题，剩下的媒体查询、clamp、容器查询，都只是表达方式而已。
现在，打开你的编辑器，把窗口从最窄慢慢拉到最宽，看看哪里最先"难受"。那里，就是你的第一个断点。