WebDriver vs CDP：各连接能做什么
按具体操作、客户端支持和实际连接限制，选择 WebDriver、BiDi 或 CDP，避免把库名称当成协议能力。
BotBrowser Team
WebDriver 与 CDP 的选择，要从测试需要的具体命令或事件开始。BotBrowser 支持文档化的自动化集成，但不负责添加客户端缺失的操作，也不能替测试套件选择连接。
TL;DR
WebDriver、WebDriver BiDi 与 Chrome DevTools Protocol（CDP）是不同的协议契约。先确定需要的操作，再验证浏览器、驱动、库和连接模式是否支持。Selenium 可以提供经典 WebDriver、BiDi 与 CDP 集成，因此库名称本身不能说明当前协议。
目录
库不等于协议
“WebDriver vs CDP” 看似二选一，实际上把几项决策压缩在了一起。WebDriver 是通过远端控制用户代理的 W3C 标准；WebDriver BiDi 是另一个定义双向命令与事件的 W3C 协议；CDP 则是 Chromium 的 DevTools 协议，包含浏览器与 JavaScript 协议域。语言库又是另一层，可能暴露一种或多种协议，也可能提供框架自己的连接。
实用的问题不是“哪种协议看得更多”，而是“哪种受支持的连接能提供这条测试所需的操作，并满足行为和可移植性要求”。点击按钮并等待标题的测试，可能只需要标准 WebDriver 命令；记录网络生命周期事件的测试，则可能需要 BiDi 或浏览器专属的 CDP 路径。这两种情况都不能证明某个选择适合所有任务。
Selenium 同时记录经典 WebDriver API、BiDi API 和 CDP 示例。其 CDP 文档将这项支持描述为等待 WebDriver BiDi 实现期间的临时方案。Playwright 提供原生协议连接，以及另一种文档明确称为较低保真度的 Chromium CDP 连接。因此，“使用 Selenium”或“使用 Playwright”都不足以确定协议。选定 BiDi 后的订阅与传输生命周期见 WebDriver BiDi 事件工作流；框架迁移则由 Selenium 迁移清单承接。
能力对照表
下表说明协议定义了哪些操作形态，不保证每个浏览器或客户端都实现全部功能。协议模式里存在命令或事件，只是检查具体实现与版本的起点。
| 任务 | 经典 WebDriver | WebDriver BiDi | CDP | 需要验证 |
|---|---|---|---|---|
| 查找、点击、输入、导航 | 标准元素与浏览上下文命令 | 定义了上下文命令，但客户端支持不同 | Page、DOM 等域提供 Chromium 控制 | 定位语义、上下文与客户端命令 |
| 读取控制台 | 不是经典请求/响应模型的通用事件流 | log 模块定义事件报告 | Runtime 与 Log 暴露控制台相关事件 | 启用的事件、上下文映射与参数保留 |
| 观察网络 | 不是通用的经典 WebDriver 事件流 | network 模块定义请求与响应事件 | Network.enable 启用网络追踪和事件 | 事件覆盖、响应体策略、脱敏和实现支持 |
| 执行页面 JavaScript | 命令模型包含脚本执行 | 脚本操作以 realm 和上下文为目标 | Runtime.evaluate 在全局对象上求值 | realm、权限、CSP 与值的序列化 |
| 改变 UA 或设备指标 | 能力协商与浏览器选项可配置会话，但不是通用动态覆盖 | 不保证每个浏览器都有同样的专属覆盖功能 | 有 Network.setUserAgentOverride 和模拟域中的设备指标操作 | 元数据一致性与仍未改变的表面 |
| 改变浏览器权限 | 可能依赖浏览器专属选项或库 API | 取决于命令支持及实现 | 有标为实验性的 Browser.setPermission | 权限名、来源范围、上下文与实验状态 |
这是一张查证路径表，不是评分榜。经典 WebDriver 的价值在于面向不同实现的标准化控制面；BiDi 增加了有规范的双向事件模型；CDP 则提供面向 Chromium 的调试域和浏览器控制。库把调用包装得方便，并不会让浏览器专属方法变成跨浏览器保证。
具体命令的稳定性也不同：它可能是实验性或可选功能，也可能尚未在某个浏览器实现，或由旧驱动以不同方式暴露。会话握手成功只能证明会话创建成功，不能证明后续所有命令与事件可用。表中的权限方法明确标注实验性；CDP 网络追踪也必须先启用相应域，之后才能期待事件。
按操作选择
先列出操作与需要的证据，而不是先偏好某种协议。当前库恰好有哪个方法，并不能代替测试实际要回答的问题。
“需要更多可观察性”太宽泛。应明确缺少的是控制台条目、响应状态、权限状态、窗口尺寸，还是用户可见结果；再定义能证明已经收到该记录的最小条件。这样不会只因为协议域列表较长，就引入更低层的依赖。只有所需命令在真实环境中可用，并且输出能回答测试问题时，较大的接口面才有意义。
| 需求 | 优先评估的路径 | 前提 |
|---|---|---|
| 可移植导航和元素交互 | 经典 WebDriver 或框架文档化的原生连接 | 确认支持的浏览器与命令语义 |
| 命令执行期间接收事件 | WebDriver BiDi | 确认事件模块、订阅范围和驱动实现 |
| Chromium 网络细节或专属模拟 | CDP | 固定 Chromium 与客户端，保留这项浏览器依赖 |
| Selenium 测试不换框架地演进 | 先保留 WebDriver，只为具体缺口增加 BiDi 或 CDP | 协议变化仍可能影响事件时间与诊断产物 |
| 同一测试覆盖多个引擎 | 满足需求时优先标准化路径 | Chromium CDP 端点不能证明 Firefox 或 WebKit 等价 |
例如，一条测试需要确认成功页出现，同时保留失败请求的状态。用户可见断言属于页面流程；网络事件帮助解释失败，但收到响应不代表应用已经显示成功。BiDi 或 CDP 应补充语义断言，而不是取代它。如果只要求 Chromium，CDP 可能提供所选驱动的 BiDi API 尚未暴露的操作。应记录这项依赖，而不是称测试与协议无关。
JavaScript 求值也要作同样区分。WebDriver 有脚本执行命令，BiDi 定义 realm 和求值操作，CDP 提供 Runtime.evaluate。这些入口不意味着相同的 realm 选择、序列化、生命周期或错误行为。依赖页面全局变量时，要说明它属于哪个浏览上下文或 realm，以及客户端如何返回这个值。
还应记录脚本运行在顶层文档、子 frame 还是隔离世界。表达式在错误的 frame 中成功，可能返回看似合理但与断言无关的值。页面异常、传输失败和客户端序列化错误也应分开分类。如果命令发送与结果返回之间发生导航，求值条件就可能改变。协议支持时，把结果绑定到上下文或 realm 标识，并明确处理上下文消失的情况。
“能设置”不等于“能变成等价设备”。设备指标覆盖只改变指定的屏幕、视口或媒体查询值，不会重建物理设备的图形路径、字体、输入硬件或全部媒体能力。UA 覆盖也不会自动对齐所有 client hints 和文档表面。结论应写清测量了什么，以及操作之外还有哪些差异。
能力矩阵还要记录可移植性成本。测试只运行 Chromium 时，CDP 依赖可以是合理而明确的取舍。如果断言必须跨引擎运行，应先确认标准 WebDriver 或 BiDi 操作是否足够。不要仅为“多一份协议数据”而重复测试；只有额外观察能发现真实回归时，它才提供了额外证据。
另一浏览器没有等价路径时，将该格标为不支持或未验证，不要悄悄改变测试含义。备用方式能观察同一用户结果时可能有效，但返回同名字段并不证明等价。控制台事件与可见错误横幅就是不同证据。把结果、采集方式和备用规则放在一起，后续读者才能知道测试真正建立了什么。
验证实际使用的连接
加入协议专属操作前，记录四项事实：浏览器及版本、驱动或远端端点、客户端库及版本、连接方法。“Selenium 配 Chrome”不够具体；“Selenium 4、固定 Chrome 构建、本地 ChromeDriver、为 network.responseCompleted 启用 BiDi WebSocket”才是可验证描述。使用 CDP 时，也要说明是库启动浏览器，还是连接已有进程。
这些记录应靠近测试配置，而不只存在于运行手册中。包升级可能改变端点或默认模式，而测试源代码完全不变。CI 创建会话时应打印有效浏览器版本与连接模式。远端服务提供浏览器时，保留它声明的能力和接受的选项。发出一个配置值不能证明远端应用了它，需要会话响应或直接观察来确认实际行为。
先做一次有界支持检查，再执行完整流程：
- 使用 CI 完全相同的启动路径创建新会话。
- 发出所需的最小命令或事件订阅。
- 保存协商能力、命令结果和不支持操作错误。
- 在自有 fixture 中触发一个请求或控制台消息，验证事件与上下文。
- 关闭会话，确认监听器、浏览器进程和 fixture 状态已经清理。
不能仅凭协议网页推断运行时支持。协议定义说明某个模式中存在方法或事件；浏览器、驱动、远端服务和客户端决定它在这次运行中能否使用。需要重复性时，固定模式版本或发布引用。CDP 的 “tot” 查看器和 master JSON 都是持续变化的目标。
把命令输出与它支持的论断分开记录：
browser=Chrome <pinned version>
client=Selenium <pinned version>
connection=WebDriver BiDi
operation=subscribe to network.responseCompleted
result=subscription acknowledged; one fixture response observed
scope=owned local fixture, one browsing context
not established=all browsers support this event identically
先以真实环境替换占位值，才能把这份记录当作证据。订阅失败是该组合的支持结果，不证明 BiDi 本身没有这项功能。事件送达而页面断言失败时，两者应分别保留。协议跟踪能解释测试，却不能决定产品流程是否成功。
每次只改一个组件后重测。先固定浏览器改变客户端或驱动，再恢复客户端改变浏览器版本，才能归因支持变化。若同时替换托管浏览器服务，二进制版本、网络跳、会话归属和协议桥都可能变化。一份小范围变更日志比“我的机器可以运行”更有用。
事件型测试应只订阅所需事件与上下文，限制保留记录数量，并在关闭时移除监听器。控制台或网络数据可能包含 URL、请求头、页面文字或用户数据。协议选择不会附带数据保留政策。持久化前脱敏，只保留能关联事件与测试步骤的必要元数据，不要顺手保存无关流量。
命令型测试则记录名称或请求标识、响应类别及后续页面状态。确认响应表示远端接受命令，不一定表示页面已经完成预期流程。仍要等待确认区域可见等语义完成条件，把协议细节作为诊断背景。超时时，区分没有协议响应和没有页面结果，它们可能需要不同的恢复方法。
浏览器内核仍位于协议之下
协议暴露操作和观察，并不定义引擎产生的所有值。脚本能读取 DOM，事件能报告请求，但渲染结果仍可能依赖字体、图形后端、浏览器构建、操作系统与 profile。设置一项模拟值也不会自动改变全部相关表面。协议层与内核回答的是不同问题。
BotBrowser 提供文档化的自动化集成，但不把 WebDriver 命令转换为 CDP，不在客户端补齐缺失的 BiDi 事件，也不保证协议模式之间完全一致。自动化一致性参考说明浏览器侧边界，而不是协议符合性矩阵。评估连接时可以固定浏览器目标，但仍必须验证具体客户端与操作。出现差异时，依次区分请求的命令、协议支持、客户端映射和浏览器环境。
不能把协议比较写成身份结论。通过 JavaScript 观察一个值，或用命令修改它，不足以建立另一系统会如何判断整段会话，也不证明另一个引擎支持同样命令。结论应限于已记录的浏览器、连接、操作与 fixture。
自动化客户端可能加入默认值，驱动可能翻译调用，远端服务可能管理会话，而内核最终产生文档与渲染值。页面出现意外值时，按边界逐项检查：测试发出了预期操作吗；端点接受了吗；客户端正确返回结果了吗；浏览器达到了预期页面状态吗。这个顺序不预设哪层有错，而是避免用协议标签替代证据。
两条协议路径返回相同 DOM 值，只证明该次运行中该值相同，不建立事件顺序、错误处理、时序或未支持操作的等价性。如果项目需要等价，列出所需操作，并在受控条件下逐项比较相关结果；若只需要可靠的测试，则选择最窄的受支持路径，保留用户结果断言。
常见问题
CDP 与 WebDriver 是同一种东西吗？
不是。CDP 是 Chromium 的 DevTools 协议，WebDriver 是 W3C 浏览器控制标准，WebDriver BiDi 又有单独的双向协议规范。库可能提供多条路径，因此应检查实际连接模式，而不是从包名猜测。
Selenium 只使用 WebDriver 吗？
不是。主要控制 API 是 WebDriver，但 Selenium 也记录 BiDi 与 CDP 集成，其文档将 CDP 支持称为 BiDi 实现过程中的临时方案。可用性仍取决于 Selenium、浏览器与驱动版本。
CDP 对所有任务都更好吗？
不能这样概括。CDP 的 Chromium 专用域可能适合某项测试，WebDriver 与 BiDi 则提供标准化契约。关键是固定组合是否支持所需操作，以及项目能否接受其可移植性成本。
设备模拟能使 headless Chrome 等价于手机吗？
不能。命令可覆盖指定指标，却不会重建每个传感器、字体、GPU、编解码器、输入设备和系统行为。应分开说明模拟字段与没有建模的环境。
协议模式里有的方法就能直接依赖吗？
需要先验证实现。模式证明协议定义了方法，不证明特定浏览器、驱动、服务或客户端版本已经实现。应在与 CI 相同的连接模式中执行有界支持检查。
来源
- W3C WebDriver
- W3C WebDriver BiDi
- Chrome DevTools Protocol 查看器
- CDP Network 域
- CDP Runtime 域
- Selenium CDP 支持
- Playwright connectOverCDP
- BotBrowser 自动化一致性
实践结论
从所需操作倒推连接：明确命令或事件，确认浏览器、客户端、驱动支持，记录版本和模式，再为用户可见结果保留语义断言。标准交互使用已支持的 WebDriver 路径；BiDi 事件契约可用时选择 BiDi；只有 Chromium 专属操作值得其依赖时再选择 CDP。协议、库和浏览器环境应在测试记录中分别列出，任何一项都不能代替对其他项的验证。