告别Replay XHR：Chrome DevTools推出Resend功能

从Replay XHR到Resend：开发者工具的重要更新

Chrome DevTools的Network面板迎来了一次看似微小但影响深远的变化。据Chrome for Developers官方YouTube频道发布的最新一期"What's New in DevTools"节目，陪伴开发者近十年的"Replay XHR"功能已正式退役，取而代之的是一个名为"Resend"的全新功能。

对于长期使用Chrome开发者工具的前端工程师来说，Replay XHR并不陌生。这个按钮允许开发者在Network面板中重新发送已经捕获的XHR请求。然而，随着Fetch API在过去近十年中逐渐成为Web应用构建的主流方式，Replay XHR的局限性日益凸显——它本质上是为XHR时代设计的工具，在面对现代Fetch请求时显得力不从心。

XHR（XMLHttpRequest） 是浏览器早期提供的用于发起异步HTTP请求的JavaScript API，曾是AJAX技术的基础。它通过 new XMLHttpRequest() 创建实例，使用 open()、send() 等方法发起请求，并通过 onreadystatechange 或 onload 回调处理响应。XHR的API设计相对繁琐，需要手动处理状态码、事件监听和错误捕获，且对Promise、async/await等现代异步模式支持不友好。

Fetch API 是2015年前后随Service Worker一同标准化的新一代网络请求接口，基于Promise设计，语法更简洁直观，调用形式为 fetch(url, options)。它统一了请求与响应的抽象（Request/Response对象），天然支持流式读取、CORS语义明确、可与async/await无缝配合，已成为现代前端框架和库的首选请求方式。正因如此，为XHR时代设计的Replay XHR在面对Fetch请求时无法正确复现请求，这也是它被Resend取代的根本原因。

Resend带来了什么改变

传统的API调试流程相当繁琐：开发者需要在Network面板中找到目标请求，右键点击，选择"Copy as Fetch"，然后切换到Console面板粘贴代码，最后才能执行请求测试。这个过程中，任何手动操作都可能引入错误，尤其是在处理复杂的请求头或认证信息时。

Resend功能彻底简化了这一流程。现在，开发者只需在Network面板中选中任意请求，点击"Resend"按钮即可立即重新发送。更关键的是，该功能能够完美保留原始请求的所有Header、Cookie和Payload信息，确保重发请求与原始请求的一致性。这对于调试需要认证的API接口尤其有价值——开发者不再需要手动处理token或session信息。

Copy as Fetch 是Chrome DevTools Network面板长期提供的一项右键菜单功能，它能把选中的网络请求自动转换成一段等效的JavaScript fetch() 代码并复制到剪贴板。开发者随后需切换到Console面板粘贴并回车执行，才能完成一次请求重发。这种方式虽然灵活，但存在明显痛点：手动切换面板增加了操作成本；粘贴的代码可能因上下文（如变量作用域、相对URL）而需要额外调整；对包含复杂Header、Cookie或认证token的请求，容易在复制或修改过程中出错。Resend把“复制—切换—粘贴—执行”四步压缩为一次点击，其价值正体现在对这类高频调试场景的直接优化上。

Edit and Resend：更灵活的调试方式

除了直接重发，Resend还提供了"Edit and Resend as Fetch"选项。当开发者需要先调整请求参数再发送时，可以通过这个入口将请求转换为Fetch代码，在Console面板中进行修改后再执行。

这种设计兼顾了两种常见场景：快速重发验证接口稳定性，以及需要微调参数进行深入调试。相比过去单一的"Copy as Fetch"方式，Resend提供了更符合直觉的操作路径。

对开发工作流的影响

Resend的推出反映了Chrome DevTools团队对现代Web开发实践的响应。Fetch API已经成为事实上的标准，而工具链的更新则是对这一现实的确认。对于日常需要频繁调试API的前端开发者而言，这个看似简单的功能改进实际上能节省大量时间——减少的操作步骤和在请求保真度上的提升，在长期使用中会积累出可观的效率收益。

开发者需要确保Chrome浏览器保持最新版本，才能获得Resend功能以及Network面板的其他增强特性。Chrome for Developers频道提供了完整的节目内容，感兴趣的开发者可以前往观看详细演示。