Playwright waitForResponse超时但对应API调用实际成功如何解决

这个超时和请求是否成功返回无关，是写法问题叠加Blazor WebAssembly（WASM）的运行特性导致的：

• URL匹配逻辑容错性极差：用===做全字符串严格匹配的鲁棒性非常弱，只要实际请求和硬编码的URL有一点差异就会匹配失败：常见的差异点包括前端防缓存自动追加的时间戳查询参数、URL末尾斜杠、部署时配置的base path前缀、甚至域名/协议的大小写差异，都会让判断条件返回false。哪怕接口已经返回200，监听器匹配不到目标响应就会一直等到超时。
• Promise.all写法存在竞态风险：Blazor的@onclick事件不是直接绑定在DOM上的业务逻辑，点击按钮后事件要先经过JS interop层转发到.NET WASM运行时，执行完组件内的点击逻辑才会通过HttpClient发API请求，整个链路是异步的。而locator.click()本身内置了元素可操作性检查、点击坐标计算等异步等待逻辑，放在Promise.all里时，可能出现浏览器侧的响应监听器还没注册完成，API请求就已经发出去的情况，直接错过响应事件。

按以下规则调整即可：

1. 放弃全URL严格匹配，改用路径片段包含匹配，忽略域名、查询参数、尾斜杠的影响
2. 调整执行顺序，先注册响应监听器，再执行点击动作，不要用Promise.all包裹两个逻辑，彻底消除竞态
3. 适当拉长超时阈值，适配Blazor WASM冷启动时runtime预热带来的请求延迟

修复后的参考代码：

// 第一步：先注册监听器，确保在点击发起前监听器已经生效
const targetResponsePromise = page.waitForResponse(
  resp => resp.url().includes('/api/Organization/GetTokenFromMobile') && resp.status() === 200,
  { timeout: 10000 } // 可根据项目冷启动实际耗时调整，默认30秒在WASM场景下可能偏短
);

// 第二步：监听器注册完成后再执行点击
await page.locator('button.btn-success', { hasText: 'GetToken' }).click();

// 第三步：等待目标响应返回
const apiResponse = await targetResponsePromise;

如果项目发布时开启了Blazor默认的Service Worker离线缓存，需要额外给waitForResponse开启Service Worker请求匹配，避免缓存响应被漏检。

内容的提问来源于stack exchange，提问作者NSS