由 pnpm docs:lessons 生成。教学脚本在 src/data/network-state.json，合同补充在 scripts/generate-network-state.mjs。本页含教师参考答案。
用 Initiator 和依赖解释启动时机。先修按 完整目录 的章节关系；基础操作、原理关系随本课讲解。
瀑布图的开始时刻与请求本身持续时间是两件事，Initiator 帮助追依赖。
串行依赖会推迟后续资源启动
并行只适用于没有真实依赖的任务
Initiator 的调用与依赖要结合同次操作，不能把总时间都归为服务慢
切换串行、并行与重复调用。模型不改变真实浏览器设置，不计为实战完成。
- 先预测一个条件变化的结果。
- 只改变一个条件，比较输入与输出。
- 将模型中的关系对应到真实 DevTools。
症状：主图晚出现，或一次页面更新重复读取库存。
正常结果：主图不等待无关推荐，库存只读取一次。
真实机制：推荐请求默认延迟约 350ms，主图是实际 SVG 资源。
- 从本课准备并打开独立商城；先打开 DevTools，再运行故障。
- 查看 Waterfall 的左侧起点和 Duration，区分启动晚与传输慢。
- 展开 hero 或 inventory 的 Initiator，定位 runtime.js 中的命名调用。
- 用同一条件运行对照；保留真正的业务依赖，不为并行而并行。
- 先保存证据，再应用针对性的对照；错误对照不会通过页面检查。
- 回到教程选择真实证据，完成独立挑战后写下排查与恢复步骤。
区分接口自身慢、启动晚和依赖等待。新会话改变输入与故障配置，可能再次抽到同一类型；按实际证据判断。
| 配置 | 原因 | 证据 | 修复/验证 |
|---|---|---|---|
| 配置1 | 无关推荐接口阻塞主图启动 | hero 等 recommendations 完成才开始，主体传输很短 | 解除无关串行依赖后公平比较 |
| 配置2 | 同一业务入口重复读取库存 | 相同 run 的 inventory 出现两次及两个调用位置 | 只保留一次库存读取并检查 Initiator |
| 干扰项 | 只凭界面颜色判断 | 没有对应请求或存储证据 | 同时改变全部条件且不复测 |
- 先区分实际请求、浏览器策略、存储与界面处理，记录第一次偏离的环节。
- 查看 Waterfall 的左侧起点和 Duration，区分启动晚与传输慢。
- 比较两个候选解释：无关推荐接口阻塞主图启动；同一业务入口重复读取库存。保持其他输入一致再验证。
本例用解除无关串行证明启动时机；不能将 350ms 当作线上性能阈值。
清理与会话约定见 共同合同。请在复盘写下条件、观察对象、实际值、根因、最小修改与恢复设置；将 HTTP 缓存、Cache Storage、内存状态分开。