状态：样板实现目标。真实 Chrome 验证版本以 STATUS.md 的实际记录为准。
前置：01–03、19–20 的课程概念。能在 Network 中定位商品请求、打开 Timing。完成后能区分响应开始前等待较长与响应主体传输较长，并设计针对性复测。长 TTFB 可能包含往返延迟和服务处理，不能单凭此认定数据库慢。
来源：https://developer.chrome.com/docs/devtools/network/reference
- 故障现场：商品列表约一秒后出现。先猜想等待、传输或证据不足；不以猜中计通过。
- 理解时序：教学模型允许改变等待时间和传输时间；横轴与阶段值同步。连接等简化段明确注明，示意不输出成真实测量。
- 真实实战：独立商城源。打开 DevTools → Network → Fetch/XHR → 清空 → 重新加载商品 → 选择
/api/products→ Timing。记录 Waiting (TTFB) 与 Content Download。 - 比较两种故障：等待场景在发送响应头前延迟；传输场景尽早发送头并分块发送较大 JSON。显示浏览器 Resource Timing 实测作辅助，DevTools 为实际观察工具。
- 应用修复：等待场景减少服务人为等待；传输场景减少练习响应体及人为分块间隔。界面明确这两项是受控实验，不声称真实项目一律如此优化。
- 同条件复测：固定本地网络、缓存条件、操作；查看对应阶段的变化。练习 API 返回 no-store，避免 HTTP 缓存干扰本课。
- 独立挑战：服务随机选择一个未在链接中暴露根因的案例。先运行故障，再选诊断和证据阶段，提交；选适合的验证方案，应用修复并运行对照。返回逐项检查及说明。
- 复盘：记录现象、证据、根因假设、下一步验证与结论边界。支持笔记持久化。
- 方向：总耗时相近不代表原因相同；找最长的阶段。
- 证据：检查 Timing 中 Waiting (TTFB) 与 Content Download，并比较响应体大小。
- 步骤：清空 Network，重新加载，打开 products 请求的 Timing；修改一个条件后重复。
API 验证挑战已实际请求、故障/修复对照均已完成，并校验诊断、证据与验证方案。服务端记录的是响应完成，页面辅助时序来自浏览器；二者均不证明用户已点击 DevTools 的特定控件。界面明确自动检查范围。失败可重试；答案查看标记辅助，不限制学习。
实验恢复仅影响商城：清除当前结果、恢复故障配置和按钮状态。课程进度不受影响。提醒用户自行恢复限速与阻断等 DevTools 设置。服务未启动、请求失败、挑战过期、记录无法保存均有可操作的说明。
- 教学模型可键盘操作，阶段与总值一致；提供非颜色解释。
- 两类请求在真实 Timing 中可区分；修复改变对应阶段。
- 新挑战不会在题干或 URL 参数中暴露正确根因。
- 无实际运行或无修复对照不能通过挑战；错误选择有解释。
- 页面显示自动检查边界，不以测量辅助取代真实工具观察。
- 阅读、练习、挑战状态各自持久化；导入导出可验证。