AI PM Buddy从学习到交付
♢新
正在读取本机记录…
拓展技术沟通◷ 55 分钟

Webhook、轮询、WebSocket 与流式响应

根据实时性、成本和复杂度选择通信方式。

学完你能做到
  • 用自己的话解释“Webhook、轮询、WebSocket 与流式响应”及其核心术语。
  • 在真实 AI 产品场景中识别何时应该使用本课方法。
  • 完成一份可沉淀进“系统关系图、一次 API 调用与基础 SQL 练习”阶段任务的实践产出。
前置与关联课程

完成阶段 2 的能力检查，或先预览相关基础课

前置 · Session、Token、OAuth 与权限控制关联 · 关系型数据库、表、字段、主键与外键
01

REAL SCENE

先从一个真实场景开始

!

支付完成后，外部平台需要通知系统更新订单；报告任务则要在页面持续展示进度；客服聊天希望逐字显示回答。团队笼统要求“实时”，却没说明事件频率、容忍延迟、连接数量与失败补偿，最终用了昂贵复杂的长连接。

02

PLAIN EXPLANATION

说人话：它到底是什么？

轮询是客户端定时询问状态，简单但会产生空请求和延迟；Webhook 是一个服务在事件发生后回调另一个服务，适合系统间通知但必须验签、去重和补偿；WebSocket 建立双向长连接，适合高频互动；流式响应在一次请求中逐块返回内容，适合生成文本。选择取决于谁知道事件发生、频率、方向、延迟和可靠性，而非追求技术名词。

01

轮询与渐进刷新

轮询易实现、易穿过网络设施，适合低频短时任务。间隔影响体验与成本，可随等待时间退避；页面不可见时暂停，完成后停止，错误时避免形成请求风暴。

  • 定义最大轮询时长
  • 失败采用指数退避
  • 状态变化后立即更新界面
02

Webhook 可靠通知

Webhook 由事件源主动发送，接收方应快速确认再异步处理。网络重试会造成重复，因此需签名、时间戳、事件 ID、幂等与重放保护，并提供事件查询作为补偿。

  • 验证来源和消息完整性
  • 先持久化事件再返回成功
  • 失败重试和人工补发可观察
03

长连接与流式输出

WebSocket 支持客户端与服务端高频双向消息，但连接管理和恢复复杂。生成式回答通常只需服务端向客户端连续发送片段，可使用流式响应，并另行定义完成、错误、取消与重连。

  • 心跳和断线重连有上限
  • 片段不等于最终已保存结果
  • 连接数量与消息顺序需监控
01

先定义事件方向、频率、延迟和可靠性，再选择通信方式。

02

所有推送与重试都要考虑验签、去重、顺序和补偿。

03

实时体验仍需完整的完成、断线、取消与恢复状态。

#Webhook#WebSocket#流式响应
03

KEY POINT

这节课最重要的结论

核心重点
实时不是越快越好，要根据事件频率与用户体验选择推送或查询。
为什么重要
这决定了听懂工程语言、阅读接口和数据库方案，并判断技术取舍时，团队是否拥有一致、可验证的判断标准。
适用边界
当问题目标、数据来源或失败成本发生变化时，不要机械套用；先重新确认假设和风险等级。
04

EXAMPLES

正确案例与常见反例

✓ 正确做法

支付平台用签名 Webhook 发送唯一 eventId，系统先持久化再异步处理，重复事件由幂等拦截，并每日对账补漏。30 秒报告任务使用逐步退避轮询；AI 回答用流式响应，断线后可根据 taskId 读取最终结果。

× 常见误区

所有场景都使用 WebSocket，支付结果只依赖一次未验签消息，连接断开就永久丢单。报告页面每秒无限轮询，即使切到后台也不停；AI 流结束后没有完成标记，用户不知道内容是否完整。

和工程师这样沟通

“支付回调用 Webhook：校验签名、时间戳和 eventId，入库成功后再 2xx，重复事件幂等，对账负责补漏。报告状态轮询采用退避并在隐藏页暂停；生成文本流必须包含 done、error 和 taskId。”

05

HANDS-ON

必做实操任务

本节产出：“系统关系图、一次 API 调用与基础 SQL 练习”阶段任务中的《Webhook、轮询、WebSocket 与流式响应》一页实践卡

  1. 步骤 1为支付通知、报告进度和聊天生成分别选择通信方式并写出理由。

  2. 步骤 2设计 Webhook 的签名、事件 ID、确认、重试、去重和补偿流程。

  3. 步骤 3为轮询设置初始间隔、退避、暂停条件、终止条件和错误上限。

  4. 步骤 4模拟流式响应中途断线，设计已显示内容、最终状态与恢复路径。

○
实践完成度 0/4

实践结果会自动保存在本机，并进入项目工坊的任务来源。

实时通信选型表业务事件：____ 谁最先知道事件：____　发送方：____　接收方：____ 方向：单向 / 双向　频率：____　允许延迟：____ 可靠性与丢失成本：____ 候选：轮询____ Webhook____ WebSocket____ 流式____ 最终选择与理由：____ 身份与验签：____ 事件 ID / taskId：____ 去重与顺序：____ 断线与重试：____ 补偿或对账：____ 用户完成/失败/取消状态：____ 监控：____
06

CHECKLIST

产品经理工作检查表

07

MASTERY QUIZ

掌握测验

达到 60% 即可完成本课。

1Webhook 接收方为什么要实现幂等？
2低频、几十秒完成的后台任务常可优先选择什么？
3流式文本结束时为什么需要明确 done 事件？
08

INTERVIEW

常见面试题

轮询、Webhook、WebSocket 和流式响应该如何选型？
展开参考回答

先看谁掌握事件、通信方向、事件频率、可接受延迟、连接规模和丢失成本。低频状态可轮询，系统间事件常用 Webhook，高频双向协作用 WebSocket，单次生成渐进展示用流式响应。无论选哪种，都要设计身份、验签、幂等、重试、顺序、完成、断线和补偿。

09

RECAP & FURTHER READING

重点回顾、延伸阅读与下一步

一句话回顾实时不是越快越好，要根据事件频率与用户体验选择推送或查询。
  1. 1

    围绕“Webhook、轮询、WebSocket 与流式响应”继续阅读：查阅对应技术的官方入门文档，重点核对输入输出、失败方式、权限边界与可观测性。

  2. 2

    用“Webhook、WebSocket、流式响应”作为检索词，分别写下一条定义、一条适用边界和一个反例。

  3. 3

    对照本课正确案例与反例，寻找一个公开案例并记录其中可复用的判断与不能照搬的条件。