响应式适配：让任务在不同屏幕与输入方式下成立

> **需要额外上下文**：目标平台/设备和使用场景。

将现有设计适配到不同的场景：其他屏幕尺寸、设备、平台或使用场景。陷阱在于将适配视为缩放。任务是针对新场景重新思考体验。

**仅限 Web**（包括移动端 Web）。原生平台 (`ios` / `android` / `adaptive`) 应跳转至 [adapt.native.md](adapt.native.md)；如果项目是原生的，请立即切换。

---

## 评估适配挑战

理解需要适配的内容及原因：

1. **识别源场景**：
   - 最初是为什么设计的？（桌面端 Web？移动端 App？）
   - 做了哪些假设？（大屏幕？鼠标输入？快速连接？）
   - 在当前场景中哪些表现良好？

2. **理解目标场景**：
   - **设备**：移动端、平板、桌面端、电视、手表、打印？
   - **输入方式**：触摸、鼠标、键盘、语音、游戏手柄？
   - **屏幕限制**：尺寸、分辨率、方向？
   - **连接**：快速 Wi-Fi、慢速 3G、离线？
   - **使用场景**：移动中 vs 桌面，快速浏览 vs 专注阅读？
   - **用户预期**：用户在这一平台上有什么预期？

3. **识别适配挑战**：
   - 什么内容无法容纳？（内容、导航、功能）
   - 什么交互无法运作？（触摸屏上的悬停状态、过小的触摸目标）
   - 什么设计不合适？（在移动端使用桌面端模式，在桌面端使用移动端模式）

适配是针对新语境重新思考体验，而非单纯缩放像素。

## 制定适配策略

创建符合语境的策略：

### 移动端适配 (桌面端 → 移动端)

**布局策略**：
- 使用单列布局而非多列布局
- 使用垂直堆叠而非并排排列
- 使用全宽组件而非固定宽度
- 使用底部导航而非顶部/侧边导航

**交互策略**：
- 触摸目标 44x44px 最低限度（不依赖悬停）
- 在适当处使用滑动手势（列表、轮播图）
- 使用底部弹层而非下拉菜单
- 大拇指优先设计（控件位于大拇指可触及范围内）
- 更大的点击区域及更大的间距

**内容策略**：
- 渐进式披露（不要一次性显示所有内容）
- 优先展示主要内容（次要内容放入标签页/折叠面板）
- 更短的文本（更简洁）
- 更大的文本 (16px 最低限度)

**导航策略**：
- 汉堡菜单或底部导航
- 降低导航复杂度
- 用于提供上下文的粘性页眉
- 导航流中的返回按钮

### 平板电脑适配（混合方法）

**布局策略**：
- 双栏布局（非单栏或三栏）
- 用于次要内容的侧边面板
- 主详情视图（列表 + 详情）
- 根据方向进行自适应（纵向 vs 横向）

**交互策略**：
- 同时支持触摸和指针
- 触摸目标 44x44px 但允许比手机更密集的布局
- 侧边导航抽屉
- 在适当情况下使用多栏表单

### 桌面端适配（移动端 → 桌面端）

**布局策略**：
- 多栏布局（利用水平空间）
- 侧边导航始终可见
- 同时显示多个信息面板
- 具有最大宽度限制的固定宽度（不要拉伸至 4K）

**交互策略**：
- 用于显示额外信息的悬停状态
- 键盘快捷键
- 右键上下文菜单
- 在有帮助的地方使用拖放
- 使用 Shift/Cmd 进行多选

**内容策略**：
- 预先显示更多信息（减少渐进式披露）
- 具有多列的数据表
- 更丰富的可视化效果
- 更详细的描述

### 打印适配 (屏幕 → 打印)

**布局策略**：
- 在逻辑点进行分页
- 移除导航、页脚、交互元素
- 黑白（或有限色彩）
- 预留装订边距

**内容策略**：
- 展开缩减的内容（显示完整 URL、隐藏部分）
- 添加页码、页眉、页脚
- 包含元数据（打印日期、页面标题）
- 将图表转换为适合打印的版本

### 电子邮件适配 (网页 → 电子邮件)

**布局策略**：
- 窄宽度 (最大 600px)
- 仅限单列
- 内联 CSS (不使用外部样式表)
- 基于表格的布局 (为了电子邮件客户端的兼容性)

**交互策略**：
- 大型、显眼的 CTA (按钮而非文本链接)
- 无悬停状态 (不可靠)
- 针对复杂交互，使用指向 Web 应用的深度链接

## 执行适配

系统地应用更改：

### 响应式断点

选择合适的断点：
- 移动端：320px-767px
- 平板端：768px-1023px
- 桌面端：1024px+
- 或以内容为驱动的断点 (设计发生断裂处)

### 布局适配技术

- **CSS Grid/Flexbox**: 自动重排布局
- **容器查询 (Container Queries)**: 基于容器而非视口进行适配
- **`clamp()`**: 在最小值和最大值之间进行流体缩放
- **媒体查询 (Media queries)**: 为不同场景提供不同样式
- **显示属性 (Display properties)**: 根据场景显示/隐藏元素

### 触摸适配

- 增大触摸目标尺寸（至少 44x44px）
- 在交互元素之间增加更多间距
- 移除依赖悬停 (hover) 的交互
- 添加触摸反馈（波纹、高亮）
- 考虑拇指区域（底部比顶部更容易触及）

### 内容适配

- 谨慎使用 `display: none`（仍会进行下载）
- 渐进式增强（核心内容优先，在更大的屏幕上进行增强）
- 对屏幕外内容进行懒加载
- 响应式图像（`srcset`、`picture` 元素）

### 导航适配

- 在移动端将复杂的导航转换为汉堡菜单/抽屉式菜单
- 为移动端应用提供底部导航栏
- 在桌面端提供持久的侧边导航
- 在较小屏幕上使用面包屑导航以提供上下文

在真实设备上进行测试。DevTools 模拟是一个有用的初步步骤，但会缺失真实的触摸、性能和浏览器外壳 (browser chrome) 体验。

**避免**：
- 在移动端隐藏核心功能（如果很重要，请确保其可用）
- 假设桌面端 = 高性能设备（考虑无障碍性、旧款机器）
- 在不同语境下使用不同的信息架构（会导致混淆）
- 破坏用户对平台的预期（移动端用户预期移动端交互模式）
- 忘记移动端/平板电脑的横向模式
- 盲目使用通用的断点（使用内容驱动的断点）
- 忽略桌面端的触摸功能（许多桌面设备支持触摸）

## 验证适配情况

在不同语境下进行彻底测试：

- **真实设备**：在实际的手机、平板电脑、桌面端进行测试
- **不同方向**：纵向和横向
- **不同浏览器**：Safari、Chrome、Firefox、Edge
- **不同操作系统**：iOS、Android、Windows、macOS
- **不同输入方式**：触摸、鼠标、键盘
- **边缘情况**：极小屏幕 (320px)、极大屏幕 (4K)
- **慢速连接**：在限速网络下进行测试

**自定义控件**（滑块、拖拽表面、可滚动控制条）：一个“前后对比”滑块可能通过上述所有宽度检查，但在 iOS 上仍无法拖拽，因此请在上述检查的同一批次中对范围内的每个控件进行测试：

- **主要手势**：点击它并确认其响应符合设计，然后使用目标输入方式对其进行拖动；拖动必须完成，而不仅仅是开始
- **跨越控件滚动**：沿页面滚动轴跨越控件的滑动会滚动页面或容器，而不会激活控件；在控件上沿其轴线开始的拖动会移动控件，而不是页面。两者失败都不会抛出错误，因此请尝试两者
- **证据**：说明证据的来源：模拟视口、通过浏览器工具合成的触摸输入、运行它的引擎（Chromium 不是 Safari）或物理设备。截图和调整大小的视口用于验证布局，绝非用于验证手势。说明哪些内容未经过测试并继续；无法触及的硬件是报告的差距，而非阻碍

当适配在每个上下文中感觉都像原生设计时，移交给 `{{command_prefix}}impeccable polish` 进行最终审核。

---

## 参考资料

以下章节此前为 `responsive-design.md`，现在以行内形式存在，以便适配流程在同一个地方拥有其深度响应式参考。

### 响应式设计

#### 移动优先：正确编写

从移动端的基础样式开始，使用 `min-width` 查询逐层增加复杂度。桌面优先（`max-width`）意味着移动端会先加载不必要的样式。

#### 断点：由内容驱动

不要追逐设备尺寸，让内容告诉你应该在哪里设置断点。从窄屏开始逐渐拉宽，直到设计出现问题，再在那里添加断点。通常 3 个断点就足够（640, 768, 1024px）。无需断点的流体数值可使用 `clamp()`。

#### 检测输入方式，而不仅是屏幕尺寸

**屏幕尺寸无法告诉你输入方式。** 笔记本可能有触摸屏，平板可能接有键盘。使用 pointer 和 hover 查询：

```css
/* Fine pointer (mouse, trackpad) */
@media (pointer: fine) {
  .button { padding: 8px 16px; }
}

/* Coarse pointer (touch, stylus) */
@media (pointer: coarse) {
  .button { padding: 12px 20px; }  /* Larger touch target */
}

/* Device supports hover */
@media (hover: hover) {
  .card:hover { transform: translateY(-2px); }
}

/* Device doesn't support hover (touch) */
@media (hover: none) {
  .card { /* No hover state - use active instead */ }
}
```

**关键**：不要让功能依赖 hover。触摸用户无法悬停。

#### 安全区域：处理刘海屏

现代手机有刘海、圆角和主页指示器。使用 `env()`：

```css
body {
  padding-top: env(safe-area-inset-top);
  padding-bottom: env(safe-area-inset-bottom);
  padding-left: env(safe-area-inset-left);
  padding-right: env(safe-area-inset-right);
}

/* With fallback */
.footer {
  padding-bottom: max(1rem, env(safe-area-inset-bottom));
}
```

在 meta 标签中 **启用 viewport-fit**：
```html
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
```

#### 响应式图片：正确处理

##### 使用宽度描述符的 srcset

```html
<img
  src="hero-800.jpg"
  srcset="
    hero-400.jpg 400w,
    hero-800.jpg 800w,
    hero-1200.jpg 1200w
  "
  sizes="(max-width: 768px) 100vw, 50vw"
  alt="Hero image"
>
```

**工作原理**：
- `srcset` 列出了可用图像及其实际宽度（`w` 描述符）
- `sizes` 告知浏览器图像将以多宽显示
- 浏览器根据视口宽度和设备像素比选择最佳文件

##### 用于艺术指导的 Picture 元素

当您需要不同的裁剪/构图（而不仅仅是分辨率）时：

```html
<picture>
  <source media="(min-width: 768px)" srcset="wide.jpg">
  <source media="(max-width: 767px)" srcset="tall.jpg">
  <img src="fallback.jpg" alt="...">
</picture>
```

#### 布局适配模式

**导航**：分为三个阶段：移动端为汉堡菜单 + 抽屉式菜单，平板端为水平紧凑型，桌面端为带标签的全尺寸。**表格**：在移动端使用 `display: block` 和 `data-label` 属性转换为卡片。**渐进式披露**：对于可以在移动端折叠的内容，请使用 `<details>/<summary>`。

#### 测试：不要仅信任 DevTools

DevTools 的设备仿真对于布局很有用，但会忽略：

- 实际的触摸交互
- 真实的 CPU/内存限制
- 网络延迟模式
- 字体渲染差异
- 浏览器外壳/键盘外观

**至少在以下设备上进行测试**：一部真实的 iPhone，一部真实的 Android 手机，如果相关，还需包含一台平板电脑。廉价的 Android 手机会揭示你在模拟器上永远看不到的性能问题。

---

**避免**：桌面优先设计。使用设备检测而非特性检测。分离移动端/桌面端代码库。忽略平板电脑和横屏模式。假设所有移动设备都性能强大。