Chrome DevTools Network request blocking 模拟接口失败

想测试页面在接口失败时是否能显示降级提示，不必先改服务端代码。Chrome DevTools 可以在本地开发或测试环境中阻断某个网络请求，让页面收到失败结果，再观察错误提示、重试按钮和兜底数据是否按预期出现。

当前入口已经从旧的 Network request blocking 面板并入 Request conditions。本文使用一个名为 profile 的接口作为示例，完整地址放在这里，方便复制官方说明：https://developer.chrome.com/docs/devtools/request-conditions/。

最短操作路径是：打开 DevTools 的 Network 面板找到目标请求，右键选择 Block request（或用 Command Menu 打开 Request conditions），添加 URL pattern，勾选 Enable blocking and throttling 后重新加载页面。成功时，Network 表会用红色的 (blocked:devtools) 标出目标请求。

先准备一个能重复触发的请求

先进入本地开发页或测试页，打开 DevTools，选择 Network。刷新页面后，在请求表的 Name 列找到要模拟失败的接口，例如 profile、orders 或 /api/search。先记住它的 URL 片段，规则越具体，越不容易误伤同一页面的其他请求。

如果页面还没有可观察的请求，可以在测试页面里放入一个最小调用。下面的示例只用于制造可识别的接口请求，注释说明了请求目的与错误分支：

async function loadProfile() {
  // 只请求测试页需要的资料接口，便于在 Network 中定位。
  try {
    const response = await fetch('/api/profile');
    // 非 2xx 响应也进入失败分支，避免只判断网络异常。
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    return await response.json();
  } catch (error) {
    // 这里显示真实产品的降级提示，阻断后可检查它是否出现。
    document.querySelector('#profile-error').textContent = '资料加载失败，请稍后重试';
    throw error;
  }
}

这段代码不是必须项；已有接口时直接使用现成页面即可。关键是先让请求出现在 Network 表中，再建立阻断规则。

步骤一：从 Network 面板进入阻断设置

1. 打开目标页面，按 F12 或右键选择“检查”，再点击顶部的 Network。
2. 在请求表中找到 profile 请求，确认它的 Name、Status 和请求 URL 与当前页面动作对应。
3. 右键该请求，选择 Block request。如果右键菜单没有该项，按 Command + Shift + P（Windows/Linux 使用 Ctrl + Shift + P），输入 block，选择 Show Request Conditions。

继续条件：右侧或底部出现 Request conditions 抽屉。不要在还没确认请求对象时直接填写宽泛的域名，否则后面很难判断究竟是哪一个请求导致页面失败。

步骤二：添加需要阻断的接口规则

1. 在 Request conditions 中点击 Add pattern（部分界面显示为加号）。
2. 在 URL pattern 输入框中填入目标请求的稳定片段，例如 *://api.example.com/profile*；如果页面走相对路径，也可以填写 *://*/api/profile*，但应尽量缩小匹配范围。
3. 保存规则，并确认 Enable blocking and throttling 已勾选。规则列表中应能看到刚加入的模式与启用状态。

可见状态：规则已经列在 Request conditions 中，并且总开关处于启用状态。Chrome 会保存这些模式，但关闭 DevTools 会让阻断和限速暂时停用，因此不要把“规则还在列表里”误认为“当前仍在阻断”。

步骤三：重载页面确认接口失败态

1. 保持 Network 面板打开，勾选需要的 Preserve log 后重新加载页面；如果只想观察一次结果，也可以先清空旧请求。
2. 执行会触发 profile 的页面动作，观察请求表中对应行的 Status。
3. 切回页面预览，检查产品自己的错误提示、重试按钮或默认数据是否出现。

成功标准：Network 表中的目标请求以红色显示 (blocked:devtools)，页面同时进入自己的失败或降级状态。这里验证的是前端在“请求没有拿到正常响应”时的行为，不代表后端接口真的返回了 500。

步骤四：停用规则并确认请求恢复

1. 回到 Request conditions，先取消 Enable blocking and throttling，这是保留规则、暂时停用的方式。
2. 如果这条规则以后不再使用，点击对应行的删除按钮；需要清空全部规则时使用面板提供的移除全部阻断规则操作。
3. 重新加载页面并再次触发接口，观察目标请求是否回到正常响应或服务端原本的状态。

最终确认：请求不再显示 (blocked:devtools)，页面也不再因为这条本地规则进入失败态。完成测试后建议删除临时规则，避免下一次调试时误以为接口本身不稳定。

常见问题

为什么规则已经添加，重新加载却没有被阻断？

先看 Enable blocking and throttling 是否打开，再确认 URL pattern 是否覆盖了实际请求。规则匹配的是请求 URL，不是页面按钮文字；可以从 Network 请求详情复制稳定的域名或路径片段后再缩小规则。

为什么关闭 DevTools 后页面恢复正常？

这是预期行为。Chrome 会保存阻断模式，但关闭 DevTools 会停用当前的网络阻断和限速。重新打开 DevTools 后，检查总开关和单条规则是否仍处于启用状态。

为什么页面显示失败，但 Network 没有出现 blocked:devtools？

可能匹配到了别的请求，或者页面失败来自 CORS、服务端错误、超时或前端自身校验。先在 Network 表中按 Name 或 URL 过滤目标请求，再区分 (blocked:devtools)、CORS error、HTTP 状态码和 (failed)，不要把它们当成同一种故障。

操作速查