C# Selenium WebDriver 等待未完成HTTP请求的解决方案咨询

零依赖优先方案：基于Selenium 4内置CDP能力实现 #

这是目前社区最常用的替代DOM等待逻辑的方案，完全不需要额外搭建代理。

• 核心逻辑：Selenium 4原生集成了Chrome DevTools Protocol连接能力，只需要在驱动初始化时开启网络事件监听，用计数器维护当前正在进行的请求数即可。
• 实现要点：
  • 连接CDP会话后开启Network域，注册两个核心事件回调：请求正式发出时计数器+1，请求加载完成/请求报错失败时计数器-1
  • 封装统一的等待逻辑：完成页面交互后轮询判断计数器是否归零，同时提前配置过滤规则，排除不需要等待的静态资源（第三方埋点请求、静态CSS/JS、图片资源）
  • 注意需要在每次交互前重置计数器，避免之前页面操作遗留的计数值干扰判断
• 优势：没有额外的网络跳转开销，计数完全匹配浏览器实际的HTTP请求生命周期，不会被DOM层的假加载状态误导。

你调研的BrowserUp方案是完全适配这类场景的 #

你之前关注的BrowserUp项目（BrowserMobProxy的社区延续维护版）本身就支持这类等待需求，只是公开文档没有专门针对“等待所有请求完成”的使用场景做直白的示例说明：

• 实现逻辑：启动本地代理实例后，将浏览器的代理配置指向该实例，所有页面流量都会经过代理节点，可以直接通过代理的API实时查询当前的活跃请求列表。
• 配套的实用能力：
  • 可以按请求路径、方法、状态码自定义匹配规则，只等待和业务逻辑相关的XHR/fetch请求
  • 自带全量请求日志能力，测试失败时可以直接回溯对应时间段的网络请求详情，不需要额外做抓包操作
  • 有成熟的C#客户端封装，不需要自己写代理通信的底层对接代码
• 适用场景：如果你的测试框架本身有弱网模拟、流量录制的需求，用这个方案的投入产出比最高，不需要额外维护多套独立工具。

版本受限场景的兜底方案 #

如果暂时没法升级到Selenium 4，也不方便引入代理工具，可以通过页面脚本注入的方式实现简单的请求追踪：

• 实现逻辑：在页面加载前注入一段劫持脚本，重写XHR和fetch API的原型，在页面全局上下文里维护一个活动请求的计数变量，完成交互后轮询读取这个变量的值判断请求是否结束。
• 缺陷：没法追踪第三方插件、跨域脚本发起的请求，容易出现计数不准的问题，只适合内部完全可控的测试页面使用，不建议作为长期维护的方案。

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