响应式与自适应

前五节学的都是「在一个屏幕上怎么摆」，这一节回答一个躲不开的问题：同一张界面，怎么在 4 寸手机、13 寸平板、27 寸显示器上都活得体面？这就是响应式设计（Responsive Design）——2010 年由伊桑·马科特（Ethan Marcotte）正式命名，此后成了整个前端行业的默认底线。说白了，响应式就是「一套代码，多副面孔」：窗口拉窄，三栏自动叠成一栏；字号调大，按钮自动让位；屏幕是视网膜屏，图片自动换高清版。它由三件套起家（流式网格、弹性图片、媒体查询），这些年又添了容器查询、动态视口单位、clamp() 一批新兵器。这一节把整套武器库过一遍，并给这一章收官——学完你会发现：响应式不是一个功能，而是一种「承认世界是变化的」的布局世界观，前五节的每一件工具，生下来就带着它的基因。

术语对照：先把响应式的行话翻译成人话

响应式 vs 自适应：亲兄弟，两种脾气

先把最容易混的一对词掰开。响应式（responsive）是一套流式版面，连续变形：宽一点就多显一列、窄一点就收一栏，任何中间宽度都活得下去——桌面是「无级变速」的。自适应（adaptive）是预备几套固定版面，检测设备落在哪一档就上哪套，档与档之间不保证平滑。好比买衣服：响应式是弹力面料，穿到谁身上都贴合；自适应是 S / M / L 三档成衣，落档合身、档间凑合。Web 主流选了响应式（维护一套代码省心），但自适应思想没死：很多大型网站给手机和桌面各自维护一套页面（m. 站点时代），原生 App 的分栏策略（§ 3.5 讲过的 size classes）本质也是自适应——档位清晰、体验极致，代价是每档都要养。判断口诀：预算和人力充足、追求每档极致，自适应；一套代码养千屏，响应式。绝大多数项目是「响应式打底、个别关键档位精调」的混血。

历史的债：960 像素的黄金年代是怎么崩塌的

要理解响应式为什么在 2010 年前后成为行业共识，得看它前面的世界。2005 年前后，桌面显示器主流宽度一路涨到 1024px，行业慢慢收敛出一个「黄金画布」：960px 固定宽度的版心——960 Grid System 这类栅格框架遍地开花，设计师按 960 出图，工程师按 960 切页，皆大欢喜。这套默契的前提只有一个：屏幕宽度是可预测的。2007 年 iPhone 出场，前提碎了：手机屏幕 320px 宽（还是虚拟的，下一节讲这个坑），960px 的版面在手机上要么横向滚动如读卷轴，要么整体缩小字如蚁群。紧接着安卓阵营尺寸开花、iPad 2010 年登场、视网膜屏让「像素」一词歧义翻倍——固定画布的假设在四五年内全线崩塌。2010 年 5 月，伊桑·马科特在 A List Apart 发表《Responsive Web Design》一文，把「流式网格 + 弹性图片 + 媒体查询」三件旧技术组成的新打法命名为响应式设计——注意一个反直觉的细节：三件套没有一件是为 2010 年发明的，媒体查询 1998 年就在 CSS2 里了，百分比布局比它更老。所谓革命，常常不是新技术登场，而是旧技术在新问题面前突然说得通了。

栅格平民化：Bootstrap 与框架时代

960px 崩塌之后，行业需要新默契，两件事几乎同时发生。一是马科特的响应式三件套成了思想共识，二是框架把它做成了「拿来就能用」的商品：2011 年 Twitter 开源 Bootstrap，12 列栅格 + 预制断点 + 响应式工具类，普通人 copy 几行 class 就能得到一个能自适应的页面——响应式从论文词汇变成了大路货。好比预制菜把厨房手艺送进千家万户：手艺还是那些手艺，门槛从「会颠勺」降到「会加热」。Bootstrap 3 在 2013 年整体转向移动优先，是这套方法论成为行业默认的标志性事件；此后的 Tailwind 等新框架延续着同一传统——断点和栅格直接内置，不等你操心。框架的功劳是把响应式变成了「不写都不好意思」的默认；框架的代价是「默认断点」养出了一代不太拉窗口看效果的工程师——参考答案背熟了，判卷标准反而忘了。本节的忠告从头到尾只有一句：框架可以帮你起步，断点必须亲手把窗口拉一遍再定。

视口：手机浏览器的一个善意的谎言

响应式的第一课不是写代码，是理解一个「谎言」。第一代 iPhone 面对的全是 960px 时代的网页，苹果做了个工程决定：手机浏览器假装自己是一块 980px 宽的画布，把整页渲染完，再整体缩小塞进 320px 的物理屏——用户看到的是缩略图，双击放大看正文。这个「善意的谎言」叫布局视口（layout viewport）：它救活了旧网页，也带来了新问题——你精心写的 320px 小屏样式根本轮不到生效，浏览器压根不认为自己是 320px。解药是那行每个页面都该有的 meta：

<meta name="viewport" content="width=device-width, initial-scale=1">

它对浏览器宣布：「别装了，把布局视口的宽度设成设备的真实宽度」——从这句起，你的媒体查询、百分比、vw 才是量着真实的屏幕工作的。说白了，这行 meta 就是响应式的开机钥匙：没它，后面所有兵器全部哑火。忘了写它的症状极具辨识度——手机上页面整体缩成一小条、文字小到没法点——看到这画面，先查 meta，再谈别的。顺带把两个概念分开：布局视口是你写 CSS 时依据的画布，视觉视口（visual viewport）是用户眼前实际看到的那块（双指缩放改变的是它）——分清这对概念，一半的「手机上显示诡异」问题就先排除了。

相对单位全家：换一把尺子，换一种思维

固定像素是响应式最大的敌人，因为它的尺子刻度是死的。CSS 备了一柜子会伸缩的尺子，先认最常用的四把：rem——跟着根元素的字号走（默认 1rem = 16px），整站字号体系用一把尺子统一管理，改一处全站缩放；em——跟着父元素的字号走，适合「跟当前文字成比例」的间距（按钮内边距用 em，字大了边距自动跟着大）；%——跟着父盒子的尺寸走，流式布局的老前辈；vw / vh——视口宽高的百分之一，天生「跟屏幕走」。不妨这样想：px 是刻死在尺子上的厘米，rem 是「单位跟着总指挥走」，em 是「单位跟着直属领导走」，vw 是「单位跟着场地走」——响应式的思维转换，说到底是从「写死数字」换到「写关系」，这和 § 3.5 约束布局「讲关系不讲坐标」是同一场思想革命在两个世界的重演。实用组合记一个：max-width: 68ch——ch 单位跟字符宽走，正文容器限到「六七十个字符一行」，正是排版学里最舒服的阅读行宽，比任何像素数字都聪明。

视口单位的坑：100vh 在手机上为什么「超高」

尺子柜里 vh 是事故高发单位，单独立案。桌面浏览器窗口多高，100vh 就多高，天经地义；手机浏览器的地址栏却是会伸缩的：页面刚打开时地址栏在场，往下一滚它收起——窗口实际高度变了，而 100vh 偏偏按「地址栏收起后的最大高度」计算，结果首屏底部的按钮被地址栏挡住半截，经典翻车现场。W3C 后来补了三个新单位：dvh（动态视口高，跟着地址栏实时变）、svh（小视口，按地址栏在场算）、lvh（大视口，按收起算）——2022 年起各浏览器陆续支持。全屏封面页的口诀：先写 100vh 兜底，再写一行 100dvh 增强——老浏览器不认识 dvh 就当没看见，新浏览器认了就覆盖，CSS「无效值自动回退」的机制一行吃定两代。说白了，这个坑的教训超出单位本身：「视口」在手机上根本不是一个固定的概念——地址栏、软键盘、手势条都在实时改写它。凡是「跟视口走」的尺寸，落笔前都该先问一句：跟的是哪个时刻、哪个视口？

媒体查询：CSS 的 if 语句

单位管「平滑伸缩」，形态切换靠媒体查询。语法一眼看懂——就是给 CSS 装了 if：

/* 容器至少 760px 宽时，卡片排成三列 */
@media (min-width: 760px) {
  .cards { grid-template-columns: repeat(3, 1fr); }
}

读法：「当视口宽度 ≥ 760px，花括号里的样式生效」。条件可以组合（and）、取反（not）、多选（逗号 or），还能问的不止宽度：（hover: hover） 问「设备支不支持悬停」，（prefers-color-scheme: dark） 问「用户开了暗色模式吗」，（prefers-reduced-motion: reduce） 问「用户要求减少动画吗」——后面这几个「偏好类查询」越来越重要，它们让界面第一次能听见用户的无声声明。打个比方，媒体查询就是那张餐桌说明书上的条款：「四人以上——展开长桌」「需要转盘——换圆桌面」「顾客要求少油——换烹饪方式」——每一条都是「看条件办事」，而条件里最经典的那条，就是下一节的断点。

断点设计：跟着内容走，别跟着设备走

初学者设计断点的第一反应是抄设备：320（iPhone SE）、768（iPad 竖屏）、1024（iPad 横屏）、1440（笔记本）——这是响应式第一大误区。设备的型号清单永远追不完：折叠屏展开多宽？安卓千元机多宽？车机屏幕多宽？拿设备清单当断点，等于拿「今天几号」当换桌子的条件。正确做法是让内容自己开口：把窗口从 320px 慢慢拉宽，盯住版面——到某个宽度，三列卡片明显太挤、文字行短得难受、间距开始失衡——版面开始不舒服的那个宽度，就是你的断点。768 和 1024 可以作为参考起点（它们背后是「拇指够得着」和「能并排放两栏正文」的真实体验分界），但最终数值必须由你的内容说了算。这套方法论叫内容优先断点，它的深层逻辑和 § 3.4 的 auto-fill 一脉相承：auto-fill 是「让浏览器算换列点」，手写断点是「自己看内容定换档点」——一个交给机器，一个留给人眼，但判据都是版面本身舒不舒服，从来不是「用户拿的是哪款机器」。

移动优先：为什么先写窄的

媒体查询写多了，一个路线问题浮出水面：基础样式写大屏版，窄屏逐级降级（桌面优先）；还是基础样式写小屏版，宽屏逐级增强（移动优先）？行业标准答案是移动优先，三个理由个个扎实。理由一，约束出好设计：小屏是最苛刻的环境——没有空间可浪费、没有悬停可用、网络还慢，先在 hardest 的环境里把内容和交互磨到最简，大屏版本自然清爽；反过来先写大屏，小屏版本往往是被硬塞剩下的。好比行李箱：先按登机箱尺寸收拾，必需品留下、装饰品舍弃；先按大箱子收拾再往小里倒，永远倒不干净。理由二，代码更干净：移动优先的媒体查询全是 min-width（「至少这么宽才增强」），条件单调递增，覆盖关系清晰；桌面优先满屏 max-width 互相打架，改一处崩三处。理由三，老手机不吃亏：低档设备只需要执行基础样式，越强的设备才执行越多增强——性能账单自动按设备能力分配。Bootstrap 3 在 2013 年转向移动优先，是这套方法论成为主流的标志性事件。

流式的智慧：无级变速与它的刹车

断点解决「档位切换」，档位之间靠流式布局平滑过渡——百分比、fr、auto-fill 这些前几节学的工具全部在此集合。但纯流式有两个经典翻车点，各配一副刹车。翻车一：行文太宽。24 寸显示器上正文拉满全宽，一行一百多字，读者的眼睛在行尾找不到下一行的开头，读三行就串行——刹车是 max-width: 68ch（或 720~820px）给版心封顶，多余的空间留给留白；排版学里 45~75 字符是阅读的黄金行宽，这把尺子一百年没变过。翻车二：拉伸过度。图片和视频被百分比拉到失真、按钮在宽屏上胖成横幅——刹车是 max-width 给内容封顶、object-fit 保比例。这一收一放之间的分寸感，就是「流式」的全部智慧：容器可以无级变速，内容要有速度上限。简单说，响应式版面的功力不在「能变形」，而在「知道在哪停下来」——变形是手段，可读才是目的。

clamp()：一行代码的平滑字号

相对单位里有个近年蹿红的函数值得单独一节：clamp()。写法 clamp(最小值, 首选值, 最大值)，读作「首选按中间那个算，但不低于第一个、不超过第三个」。配合 vw 就有了响应式排版的招牌菜：

h1 { font-size: clamp(1.75rem, 4vw + 0.5rem, 3rem); }

窄屏时 4vw 算出来太小，clamp 兜底到 1.75rem；宽屏时算出来太大，封顶到 3rem；中间地带随视口连续平滑地变化——一个函数，替你写完了「最小字号保护 + 平滑缩放 + 最大字号封顶」三段逻辑，还省掉了两三个断点。本质上就是把 minmax() 的思想（§ 3.4 轨道的地板天花板）搬到了任意数值上：伸缩可以，底线和上限先谈好。标题、版心宽度、段间距都适合这一味药；反过来正文Body一般不用它（正文字号跟着用户的浏览器设置走才是正道，这个细节下一节展开）。

正文字号跟谁走：用户、根字号与无障碍

上一节留的扣子在这解：标题适合 clamp，正文为什么不行？因为正文字号的裁判不该是视口，是用户自己。浏览器都留了一个「基础字号」设置（默认 16px，老花眼的用户可能直接调到 20px 以上），rem 的一切随它缩放——你的正文写 1rem，用户调大基础字号，全站文字应声变大，这才是无障碍的正道。反过来把正文写死 px、或让正文跟着 vw 走（窗口越窄字越小），等于把裁判权从用户手里抢走：低视力用户刚把系统字号调大，你的页面纹丝不动——他只有两个选择，眯着眼看，或者按 Ctrl 加号让整个页面连图带字一起放大（很多版面一放大就破）。所以字号政治学的核心就一句：标题可以跟视口（clamp），正文必须跟用户（rem）。说白了，视口宽窄是设备的事，读不读得清是人的事——设备的话可以商量，人的话得听。这条规矩与 § 3.5 的「dp 量布料、sp 量字」遥相呼应：两个平台在「文字要跟着用户走」这件事上，结论完全一致。

容器查询：组件的自适应自觉

§ 3.4 已经预介绍的这位，这里正式编入武器库。媒体查询问的是「窗口多宽」，但现代界面是组件拼装的：同一张卡片，可能住满宽主区、也可能挤在半宽侧栏、还可能塞进弹窗——窗口宽度一样，卡片的「生存空间」天差地别。容器查询把判断权下放给组件自己：

.card { container-type: inline-size; }
@container (min-width: 400px) {
  .card-body { display: flex; gap: 16px; }   /* 房间够宽：图文横排 */
}

两行配置，卡片从此有了「自适应的自觉」：房间里铺得开就横排，铺不开就竖排，搬到哪个页面都体面。容器查询还配套了自己的单位 cqw（容器宽的百分之一），字号都能跟着容器伸缩。2023 年全浏览器落地以来，它和媒体查询形成了清晰分工：@media 管页面级骨架（几栏、侧栏在不在），@container 管组件级姿态（横排竖排、显不显示次要信息）——前者是「整屋户型」，后者是「家具自己的变形」，正好接着本节开头的餐桌比喻：户型图变更是媒体查询的事，桌子展开到哪档是容器查询的事。

响应式图片：流量大头的一鱼三吃

页面字节的大头从来不是 CSS，是图片——一张桌面端横幅直接 2MB，手机流量和加载速度（§ 2.4 渲染管线、网络篇的加载三剑客都要算它）全被拖下水。响应式图片的核心思想「一鱼三吃」：同一张图备多个尺寸，浏览器按屏幕实际需要挑一张下载。

<img src="photo-800.jpg"
     srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1600.jpg 1600w"
     sizes="(min-width: 760px) 360px, 100vw"
     alt="海边日出">

srcset 报菜名（「我有 400 / 800 / 1600 三种宽度」），sizes 报饭量（「宽屏上我占 360px，窄屏上占满全宽」），浏览器自己算账下单——手机拿 400 那张，视网膜屏自动翻倍上 800，谁也不浪费。<picture> 元素更进一步支持「艺术指导」：宽屏用横构图、窄屏裁成竖构图，相当于同一道菜按碗的大小换摆盘。这套机制的哲学和整节一脉相承：别替设备做决定，把选择权和信息一起交给它——你不知道用户的屏幕和网速，浏览器知道。

图片响应式还有最后一块拼图：懒加载（lazy loading）。首屏之外的图片先不下载，滚到快看见时再加载——img 标签加一个 loading="lazy" 属性就生效（2020 年起浏览器原生支持，零 JS）。好比快递分拣中心只把「今天要派送的包裹」装上车，后面几站的货先留在仓库——货架一屏一屏地补给，首屏速度立竿见影，一篇三十张图的长文，用户可能只看三张就关了，其余二十七张的字节一个都不用花。至此图片三件套配齐：srcset 管「拿多大的图」，sizes 管「用多大尺寸显示」，lazy 管「什么时候拿」——流量大户的账，这才算治完。

性能账本：给还没到的内容预留座位

响应式的及格线是「不崩」，高分线是「不跳」。想象一个场景：手机上读长文，你正要点「阅读原文」按钮，一张图片恰好加载完成，「啪」地插进正文，按钮被顶下去半屏——手指已经落下，点中了别的东西。这种「内容迟到导致版面跳动」有个正式名字：累积布局偏移（CLS，Cumulative Layout Shift），谷歌网页体验三大指标之一，跳动越少分越高。好比电影院对号入座：座位表开场就定死，观众一个个进场、谁来了谁坐自己的位置，前排永远不必因为后排来了人而挪窝——网页要学的就是这张座位表。

跳动有三大惯犯，各配一副手铐。惯犯一：图片。img 不声明尺寸时，浏览器先按高度 0 排版，图下载完才知道自己多大，正文被顶一次。手铐两副任选：img 标签写上 width / height 属性，或 CSS 一行 aspect-ratio: 16 / 9——座位先占住，图到了直接躺进去，版面纹丝不动。惯犯二：网络字体。自定义字体文件没到之前，浏览器先用备用字体渲染，字体一到整段文字集体换装，行长行高全变。缓解办法是 font-display: swap 配 size-adjust 微调（让备用字体的尺寸尽量贴近正式字体，换装时跳动最小），或者干脆用系统字体栈——零下载、零换装。惯犯三：迟到的内容块：广告位、Cookie 横幅、慢接口的数据。药方是「先占位后到货」：给它们留固定高度的骨架屏，内容到了填坑，不推搡邻居。

顺着这笔账再记两条纪律。一是加载优先级：首屏大图是访客对站点的第一印象，标上 fetchpriority="high" 让浏览器优先伺候；首屏之外的图全部 loading="lazy"。二是断点数量是负债：断点不是越多越精细——每加一个断点，就多一档要测试、要维护、要在三压测试里多拉一遍的版面；能靠流式工具（auto-fill、fr、clamp）自动消化的变化，就别手写断点去接。说白了，机器能接的球留给机器，人只接机器接不住的那几个。

高清屏的账：DPR 与「像素」一词的两副面孔

2010 年 iPhone 4 带着视网膜屏登场，「像素」从此有了两副面孔：CSS 像素（写样式用的逻辑单位）和物理像素（屏幕上真实的小点）。两者之比叫 DPR（设备像素比）：普通屏 1:1，视网膜屏 1:2、1:3——一个 CSS 像素宽的按钮，物理上由 2×2 甚至 3×3 个点渲染。这个比率带来两张账单。账单一：位图要按 DPR 备料——一张 CSS 尺寸 100px 的头像，@2x 屏需要 200px 的图才不糊（srcset 的算法自动算这笔账）；矢量图（SVG、字体图标）天生无量纲，DPR 多高都锐利，图标首选它。账单二：1px 边框的玄学——视网膜屏上最细的真实线是「半个 CSS 像素」宽的物理线，高清屏上 hairline（发丝线）要专门处理才够细。说白了，DPR 把「像素」从物理名词变成了会计单位：写 CSS 时按逻辑像素记账，出货时浏览器按 DPR 换算成物理点——你只管账面，汇率它来换。

交互也响应：hover 之死与安全区

响应式常被理解为「尺寸自适应」，其实交互方式同样要跟着设备变形，这是最容易被漏掉的一课。最典型的是 hover（悬停）：鼠标时代的下拉菜单靠 hover 展开天经地义，触屏上没有「悬停」这回事——手指点一下就是点击，菜单要么点不开、要么一碰就弹。正解是媒体特性查询：@media (hover: hover) 才启用悬停展开，触屏设备改用点击展开；「大按钮」同理，触屏上点击目标建议至少 44×44px（拇指的物理尺寸，苹果 HIG 和谷歌规范在这惊人一致），而鼠标可以点更小的目标。第二个被漏掉的是安全区（§ 3.5 在原生侧讲过，Web 这边是同一个概念）：全面屏的刘海和手势条区域，网页用 env(safe-area-inset-bottom) 读取并让位——底部固定栏不加这句，手势条会直接叠在按钮上。打个比方，交互适配就是「菜单也要看人下菜」：给堂食的顾客上刀叉、给外卖的顾客配筷子——同一道菜（功能），餐具（交互方式）按场景配齐，这才是完整的响应式。

暗色模式：会听话的界面

媒体查询能问的除了宽度，还有用户的「偏好声明」，最出名的就是暗色模式。写法一行：@media (prefers-color-scheme: dark) { … }——用户在系统里开了深色，你的网页自动换一套配色。工程上的标准做法呼应 § 3.4 的「图纸参数化」：把所有颜色提成 CSS 变量，浅色一套值、深色一套值，媒体查询里只改变量——正文结构一个字不动。实操的坑记两个：纯黑（#000）在 OLED 屏上反而刺眼，深色主题通常用「接近黑的深灰」；阴影在深色下几乎看不见，层次感要改用「亮度差」来表达。更深一层看，暗色模式的意义远不止护眼：它是「界面听用户无声偏好」的第一课——用户没在你的网站里点过任何开关，你却响应了他在系统层面的选择，像一间客人还没开口就调好灯光的餐厅。这个家族还在壮大：prefers-reduced-motion（用户要求减少动画——前庭敏感人群坐车刷手机时的福音，检测到它就该关掉视差和转场）、prefers-contrast（要求更高对比度）。说白了，偏好类媒体查询让 CSS 第一次有了服务「人」而不只是「屏幕」的接口——尺寸类查询问的是设备长什么样，偏好类查询问的是人需要什么，后者才是无障碍的正门。

被遗忘的媒体类型：打印

媒体查询里「媒体」二字，提醒我们它查询的从来不止屏幕。@media print 里写的样式只在打印（或浏览器「另存为 PDF」）时生效：导航栏、广告、评论框统统 display: none，正文拉通全宽，链接地址补在文字后面（纸上点不了链接，得让人看得见网址），再给标题加上 break-after: avoid，防止「标题孤零零留在页尾、正文全在下一页」的尴尬。别小看这个冷门场景：电商打印订单确认页、银行打印流水单、医院打印缴费凭证、办公室打印的会议材料——「纸上界面」至今是真实需求。屏幕上的排版讨好眼睛，纸上的排版讨好打印机：白底黑字、去交互、防孤行——同一份数据两副面孔，正是响应式「一套内容、按媒体变形」的原始教义。顺带补一笔历史：@media print 在 CSS2 时代（1998 年）就有——比「响应式」这个名词早了十二年。说白了，响应式不是 2010 年的发明，是那次命名把一个老传统扩编成了新军种。

超宽屏与折叠屏：宽度没有上限之后

响应式的讨论总围着「窄屏」转，宽屏也有自己的烦恼，而且只会越来越多。第一，超宽屏：带鱼屏、34 寸显示器上，无节制拉满的版面一行能排两百字——读者眼球从行尾回到下一行行首要「长途跋涉」，读三行就串行。这时候版心封顶（68ch）就是救命稻草，多余宽度交给留白，或者干脆让相关内容升为第二栏。第二，折叠屏：展开是窄平板、合上是窄手机，中间还多一条铰链折痕——Web 侧媒体查询照常工作，但要注意展开瞬间视口突变造成的断点跳变（关键过渡配个 transition 缓一缓，别让版面「啪」地闪变）。第三，也最釜底抽薪的一条：多窗口与分屏让「窗口宽度」和「设备类型」彻底脱钩——iPad 分屏里一个 320px 的窄窗，它的身份还是 iPad。凡是「按设备型号判断」的逻辑在这种场景全线失效，「按视口实际宽度判断」再次证明是唯一活路。设备形态的创新还会继续，这节的全部原则却一条都不用改——因为它们从一开始就没绑定任何具体形态，只绑定「尺寸变了就重排」这一个事实。

原生那边：size classes 与 resource qualifiers

响应式思维跨平台通用，原生阵营各有各的官方姿势，认个脸。iOS 用 size classes（尺寸类别）：把宽高各归为 compact（紧凑）和 regular（常规）两档，iPhone 竖屏是「宽紧凑高常规」，iPad 是「宽常规高常规」——你不用问「具体是哪台设备」，只问「这档尺寸类别里该用什么版面」，同一套界面在分屏、旋转、折叠时自动换档，这正是 § 3.5「讲关系不讲坐标」在宏观布局层的再现。Android 用资源限定符（resource qualifiers）：给不同条件备不同资源——layout-sw600dp 目录里的布局只在「最小宽度至少 600dp」的设备上启用，平板和手机各拿各的版本；字号、暗色模式、语言都可以用同样的机制分档。说白了，三家的词汇不同，句式是同一句：「别问我是谁，告诉我你要什么条件」——Web 问视口宽度，iOS 问尺寸类别，安卓问最小宽度。工具是方言，思路是普通话。

综合施工：一篇文章页的六步响应式改造

兵器谱过完了，用一个真实尺寸的案例把整章工具串成一条流水线。素材是一篇普通技术博文：顶栏（logo + 菜单）、正文、目录侧栏（长文专属的「本页导航」）、底部评论区。需求只有一句——手机、平板、桌面都要体面。改造按六步走，每一步都只用本章教过的兵器。

第一步，HTML 只写一份，按「内容优先」排顺序：正文在前、目录在后、评论垫底。小屏上这个顺序就是阅读顺序——最重要的内容最先出场；往后到大屏档，这份顺序一个字都不用动。第二步，打底样式全按最窄屏写（移动优先）：单列流式、正文 68ch 封顶居中、菜单收进汉堡按钮、图片 width: 100% 随容器伸缩。第三步，亲手拉窗口找断点：从 320 一路拉宽，到约 860px 时正文行宽正舒服、右侧开始出现大片空白——版面自己开口了，目录侧栏在此浮出，几行 Grid 交接：

/* 桌面档（860px 起）：正文 + 目录双栏 */
@media (min-width: 860px) {
  .article-page {
    display: grid;
    grid-template-columns: minmax(0, 1fr) 220px;  /* minmax(0,1fr)：长代码块撑不爆左栏 */
    gap: 40px;
  }
  .nav-menu { display: flex; }   /* 汉堡收起，菜单整排展开 */
}

这里藏着移动优先的一份红利：DOM 里正文在前、目录在后，进网格后自动各归各位——正文落进宽的 1fr 栏，目录落进 220px 窄栏。为小屏排的顺序，在大屏网格里恰好也是正确顺序，一份结构两头讨好；220px 也可以写成 minmax(180px, 240px)，给目录栏留一点呼吸的余地。第四步，尺度体系：正文 1rem 跟用户走，标题 clamp(1.75rem, 4vw + 0.5rem, 2.5rem)，间距全站只用一档比例尺——4 的倍数（8 / 16 / 24 / 40），密不透风和稀稀拉拉都不会犯，全站节奏一致。第五步，组件级交给容器查询：评论区每张评论卡片写 @container，窄容器只显头像加两行字，容器够宽才展开「引用 / 回复」按钮组——这套卡片将来搬到任何页面都不用改。第六步，偏好收尾：prefers-color-scheme 备一套深色变量，@media print 隐掉侧栏和评论、正文拉通全宽留给纸。六步走完回头看：HTML 始终一份，变的只是 CSS 里那几行条件——结构是骨骼，只长一次；样式是表情，随境而变。这句总结，就是整章布局篇的临别赠言。

测试矩阵：模拟器、真机与三压

武器齐了，最后一段是验收纪律。第一档，浏览器 DevTools 设备模拟：一键切 iPhone / iPad / 自定义宽度，日常开发九成的检查在这完成，媒体查询和容器查询都能可视化调试。第二档，真机抽查：模拟器骗得过眼睛骗不过手指——触控目标大小、滚动惯性、软键盘弹出后视口被压扁（100vh 的经典陷阱就在这现形，现代解法是 dvh 动态视口单位）这些只有真机说了算。第三档，是我给它起的名字，三压测试：压宽度（窗口从 320 一路拉到 1920 不许有横向滚动条）、压字号（浏览器基础字号拉到 120%，版面不许爆）、压网络（DevTools 限速到慢速 3G，看图片策略和不行的体验兜底）。就像新装的电路验收不只「通电就算」——要测空载、测满载、测漏电；响应式版面的验收同样三关全过才算数。一套版面敢不敢上线，看的不是它在你那台显示器上多好看，是它在三压之下没死。

排错手册：响应式七案

• 案情一：手机上页面整体缩成一小条，字小如蚁。十有八九是 viewport meta 没写——布局视口还停在 980px 的善意的谎言里。补 meta，立竿见影。
• 案情二：某几个宽度下出现横向滚动条。逐个元素排查谁超宽：固定宽度的图、写死的 min-width、不容许换行的长单词。DevTools 选中 body 看滚动宽度，二分定位元凶。
• 案情三：断点附近版面「闪跳」。档位切换处元素尺寸突变——把跳变改成 clamp() 平滑过渡，或检查是不是断点设在了内容并不需要换挡的位置。
• 案情四：手机流量跑得飞快。图片没做 srcset 分档，所有屏都下载最大那张。检查 sizes 写没写、档位够不够。
• 案情五：触屏上菜单点不开或一碰就乱弹。hover 依赖症。用 @media (hover: hover) 隔离悬停行为，触屏改点击交互。
• 案情六：全面屏底部按钮被手势条挡住。安全区没让位。底部固定元素 padding 加 env(safe-area-inset-bottom)。
• 案情七：读着读着正文往下跳，按钮跑位。累积布局偏移（CLS）：没占位的图片、换装的字体、迟到的广告在推搡版面。img 补 width/height 或 aspect-ratio，动态内容先留骨架屏。