订单中心集成：浏览器联调与消息队列入门｜课后复习
本次商城补强回收
本日产物：真实浏览器订单调用链与独立通知队列实验。逐项回到课堂同名章节，解释 应用既学 Python 模型/异常/事务/async/线程进程边界；fetch 四态、Cookie/CSRF/CORS；MQ 生产消费和 ACK，指出本人代码中输入、状态与失败的位置。再用独立变体证明解释有效，不把讲过当会做。
| 风险 | 提前预防 | 怎样发现 | 怎样处理 | 怎样复验 |
|---|---|---|---|---|
| 页面成功冒充事务成功 | 同订单号贯穿页面和数据库 | 核对 Network、日志、订单和库存 | 定位第一处不一致做最小修复 | 正常与失败旅程复跑 |
| create_task 当持久通知 | 先画进程与保存边界 | 重启后查任务是否仍存在 | 按持久需求选消息服务 | 记录入队、消费、ACK 各自状态 |
| 先 ACK 或无限重试 | 处理后确认并定义失败出口 | 查看 pending 与重复事件结果 | 修确认顺序与去重 | 重投不重复虚构业务效果 |
自测：构建与浏览器分栏；201/404/403/409；数据库事实；Redis 实验入队/消费/pending，未运行仍待验证。下一日接口：完整端到端交付与个人变化；不再增加 Python 主概念。
今天学会了什么
能把浏览器接到已保护的 API，定位请求与页面问题；能解释消息交给独立消费者后，接受、执行、确认与重复处理的区别。
沿图指出已有身份检查怎样接入浏览器，按 Network 的请求、状态、响应、页面顺序排错；消息队列另画生产者→Broker→消费者→ACK，区分入队与完成。
今天讲了什么（对照复习）
下面逐项对应课堂正文。先盖住右边那一栏，凭记忆回答；卡住了再翻回左边同名的小节。光说得出名字不算会，还要能讲清它会做什么、什么时候会失效。
| 课堂对应章节 | 必须能解释的机制与边界 |
|---|---|
| Node.js、npm 与 Vite 第一次使用；前端只做最小 API Consumer | Node 运行前端工具，npm 管依赖，Vite 负责开发／构建；有可信 lockfile 用 npm ci，首次生成则审查锁文件。不提交 node_modules，不删 engines 绕过版本条件；本周沿用 vanilla JavaScript 模板。 |
| 从 OpenAPI 生成候选 | 以你接口合同、错误结构、允许文件和验收条件约束 AI；每轮只改一种行为，读 diff、查 Network、运行后决定接受，页面不能靠 Mock 数据假装联调。 |
| fetch 最小结构；Bad Case：不判断 response.ok | fetch 返回 Response 不代表业务成功，404/409 通常不会自动抛网络异常；检查 ok／status，再按成功或错误合同解析 JSON 并更新 DOM。页面区分加载、成功、空结果和失败。 |
| Origin 和 CORS；先故意移除 CORS；最小 CORS 配置 | Origin 由协议、主机和端口组成；跨源凭据需显式来源与 credentials。浏览器限制不等于后端没收到请求；CORS 不替代身份。部署同源 /api 代理与开发跨源直连分别配置，不在带凭据场景随意用 *。 |
| Network 排错路径；Bad Case：API base 写死；先接好浏览器的身份和错误状态 | 按请求 URL／方法／参数→状态／响应→解析→DOM 排查，关联 request_id。API base 由环境提供；Cookie 自动携带，写请求需 CSRF。401 回登录、403 说明权限、503 说明依赖故障，不统一写“网络错误”。 |
| 从同步通知到消息队列；生产者、Broker、消费者与确认 | 同步等待在请求链；async/await 与 create_task 属于进程内调度；消息队列在进程间交接工作。生产者入队、Broker 接受、消费者完成、ACK 各是不同阶段；202 仅表示接受任务，本例不改变订单 201 语义。 |
| 用已有 Redis 做最小队列演示 | Redis Streams 的生产者与消费者分别运行，使用自己的 namespace；未 ACK 的消息可处于 pending，故障后按条件 reclaim。观察“消息存在”与“处理完成”，通知记录为本地教学数据，不发送真实消息。 |
| 为什么需要重试、幂等和失败出口 | 完成后 ACK 前故障会引起重复投递，按 event_id 控制重复效果；示例 Redis 内原子操作不能证明外部邮件 exactly-once。重试要有次数与退避、死信／人工出口；积压增长需查消费能力和下游。 |
| 为什么需要重试、幂等和失败出口；自主学习任务：从最小示例走向常用消息系统 | 订单落库与发布消息有失败窗口，Outbox 在同一数据库事务保存业务及待发事件，是今天需认识的思路。核心交选型风险卡；RabbitMQ 生产消费及确认实验为选做，Kafka 是延伸阅读。 |
出了问题：怎么发现、怎么修、怎么验证
只在你自己那份课程副本或专用实验数据上复验，把改之前和改之后的真实结果都留下来。
| 风险／现象 | 提前预防 | 怎样发现 | 怎样处理 | 怎样复验 |
|---|---|---|---|---|
| fetch 收到业务错误却显示成功 | 按状态码与错误合同分支 | 用 404/409 请求观察页面和 Network | 先检查 ok，再渲染对应状态 | 成功、空结果、加载、失败均有正确反馈 |
| Cookie／CSRF／跨源配置错 | 明确同源代理或开发跨源路线 | 检查请求是否带凭据、来源与响应头 | 修 API base、来源和 CSRF，保留服务端鉴权 | 登录查询与授权写入成功，越权仍失败 |
| 页面字段错误被归咎后端 | 以 OpenAPI 与实际响应为准 | 响应正确但 DOM 为 undefined 时查字段和选择器 | 只修前端映射及渲染 | 正常详情与错误响应都可读 |
| 入队被当完成或先 ACK | 明确消费者完成点和状态语义 | 记录入队、pending、处理与确认顺序 | 成功处理后确认，保留可恢复状态 | 受控退出后能重新领取，状态记录可区分 |
| 重复效果或无界重试 | 用事件标识、重试预算和失败出口 | 重复事件及 ACK 前故障后再消费 | 按业务边界去重；永久失败进入待处理路径 | 本地示例仅一份效果，不承诺真实外部 exactly-once |
| 把 create_task 当持久队列 | 标明进程与数据存储位置 | 解释进程退出时未完成任务去向 | 可靠需求交独立队列方案，画落库／发消息窗口 | 以持久、确认及恢复证据判断，不看关键字 |
闭卷自测
先自己答一遍，再去运行或翻回课堂核对；不确定的地方标出来，别用 AI 的答案顶掉你自己的第一次判断。
- npm ci 与首次 install 有什么前提差异？为什么页面能显示 Mock 数据不证明联调成功？
- fetch 收到 409 会自动进入 catch 吗？四种页面状态应怎样区分？
- 5173 到 8000 与同源 /api 有什么不同？Cookie、credentials、CSRF 和 CORS 各在哪里检查？
- 画出生产者、Broker、消费者、ACK，说明入队确认和消费完成为什么不同。
- 消费者处理后、ACK 前退出会怎样？pending、reclaim、event_id 去重各解决什么问题？
- 为什么重试不能无限进行？Outbox 要补哪个失败窗口？哪些 MQ 实现属于本周选做？
再看一眼真实业务
用有赞批次任务的公开状态反馈检查自己的“已接受／处理中／已完成”文案。页面进度不是平台使用 Redis Streams 或 RabbitMQ 的证据，课堂方案需另用本地实验说明。
今天留下什么，下节课怎么接着用
保留浏览器订单中心、环境示例、身份与错误请求记录、前后端容器联调证据及消息队列风险卡。跟随课堂示例记录生产／消费与 ACK 前故障；W03-D05 将已实现核心能力整合成用户旅程。
队列示例与真实订单主事务解耦，不能说已实现可靠订单通知。独立搭建 RabbitMQ、完整 Outbox、死信系统及高可用消息服务均为进阶，核心不加量。