设计稿通常只有几个固定画板，浏览器宽度却是连续的。前端如果逐张“对像素”，中间尺寸就会靠补丁维持，CSS越来越难维护。
高质量响应式开发要先理解组件的伸缩规则，再选择Grid、Flex、容器、媒体和资源策略实现。
01 从语义结构开始
先用清楚的header、nav、main、section、article、footer和标题层级组织内容，再处理视觉布局。
语义结构有利于可访问性、SEO和样式降级，也能减少为了布局堆砌无意义容器。
02 使用流式布局，避免到处固定宽度
容器、网格和间距可在合理区间伸缩，组件设置最小和最大边界。
固定像素适合图标和局部尺寸，不应让整页只能在某个画板宽度成立。
响应式开发检查点
| 区域 | 实现要点 | 常见问题 |
|---|---|---|
| 布局 | Grid/Flex、流式容器、内容断点 | 大量绝对定位和固定宽度 |
| 图片 | srcset、sizes、合适格式与裁切 | 手机下载桌面超大图 |
| 字体 | 可读行长、缩放、字体加载 | 禁用缩放或文本溢出 |
| 导航 | 键盘、焦点、层级返回 | 仅Hover可用、菜单无法关闭 |
| 表格 | 列优先、滚动、标题关联 | 直接缩小到无法阅读 |
| 表单 | 正确输入类型、触控与错误 | 键盘遮挡、标签消失 |
03 断点服务内容，而不是框架默认值
框架断点可以作为起点，但应在组件失效时增加或调整。使用容器查询时，也要设计清楚组件内部规则。
避免每个页面自定义一套断点，造成系统难以维护。
04 响应式资源决定真实性能
根据展示尺寸和像素密度提供图片，非首屏延迟加载，关键图片合理预加载。
字体减少字重和不必要字符，视频在移动端提供降级。
05 同时支持鼠标、键盘和触控
Hover不能是唯一信息入口，焦点状态清楚，触控目标足够，弹层和菜单可通过键盘关闭。
移动端不仅是窄屏，还可能有横屏、外接键盘和读屏。
06 建立浏览器与设备测试矩阵
根据用户数据确定主流浏览器、系统和设备，覆盖真实内容、长文案、多语言、慢网和异常状态。
自动截图能发现视觉回归，真机测试负责触控、键盘、性能和系统行为。
常见问题
可以只测试Chrome吗？
不建议。应按目标用户覆盖Safari、Edge等主要浏览器和移动WebView。
响应式开发一定需要Bootstrap或Tailwind吗？
不需要，工具只是实现方式，关键是布局规则和维护。
图片都用WebP就够了吗？
不够，还要按尺寸、质量、裁切和加载时机提供合适资源。
移动端能用Hover效果吗？
不能依赖Hover完成核心任务，应为触控和键盘提供等价方式。
如何防止后续页面破坏响应式？
使用组件与Token、内容约束、代码检查和视觉回归测试。
链接复制成功
