Webhook 重放 会把先前捕获的 HTTP 回调重新发送到你的本地处理器，而无需让上游服务商再次投递该事件。你不必重新触发一笔 Stripe 扣款、一次 GitHub 推送或一条 Twilio 消息，而是从请求历史中重放完全相同的请求——请求头、请求体，一应俱全。
为什么 Webhook 重放很重要
Webhook 调试通常陷入一个痛苦的循环：触发事件、检查投递、找到 bug、修复代码、再次触发。重新触发上游事件既慢又嘈杂，有时甚至不可能（一次性支付事件、已删除的资源，或受速率限制的测试 API）。
重放压缩了这个循环。捕获一次，修复处理器，反复重放同一个负载直到通过——完全不必碰外部服务商。
Webhook 重放如何工作
- 回调到达你的隧道 URL 并被转发到本地应用。
- 隧道工具捕获完整请求：方法、路径、请求头和请求体。
- 你根据捕获请求中看到的内容修复处理器代码。
- 你用一个动作把捕获的请求重放到本地端点。
- 重复直到处理器返回正确响应。
这个工作流需要一个内置请求捕获的 localhost 隧道——而不仅仅是流量转发。
Webhook 重放的使用场景
处理器开发
迭代地构建和测试 Webhook 处理器。在打磨解析逻辑时，把同一个 Stripe checkout.session.completed 事件重放十次。
幂等性测试
服务商在重试期间会投递重复事件。多次重放同一负载，确认你的处理器能安全处理重复，不会重复扣款或产生重复记录。
签名校验调试
当签名校验失败时，用完整的请求头重放原始请求，以判断问题出在校验逻辑还是负载解析。
回归测试
保存来自贴近生产的测试事件的捕获请求，在重构后重放它们，以在部署前捕捉破坏性变更。
用 PortPreview 进行 Webhook 重放
- 启动你的应用并运行
npx portpreview 3000。 - 配置服务商把回调发送到隧道 URL。
- 触发一个测试事件，并在 PortPreview 中检查捕获的请求。
- 修复处理器，然后重放捕获的请求。
- 验证响应状态和响应体，无需重新触发服务商。
PortPreview 保留原始请求头，因此服务商的签名校验在重放期间依然有意义。
重放与重新触发：何时用哪个
- 重放：处理器逻辑 bug、负载解析、幂等性检查、签名调试。
- 重新触发：测试服务商端的事件生成、验证 Webhook 注册，或与服务商实时状态的端到端集成。
关于各服务商的设置，请参阅 本地测试 Stripe Webhook、本地测试 GitHub Webhook 和 本地测试 Twilio Webhook 的指南。
Webhook 重放的最佳实践
- 始终在重放时校验签名，而不仅是首次投递时。
- 通过多次重放同一事件来测试重复投递。
- 在功能分支期间保留请求历史以供回归检查。
- 使用测试模式凭据，使重放的事件绝不影响生产数据。
加入 PortPreview 等候名单，把 Webhook 捕获与重放内置到你的隧道工作流中。