# Selenium (WebDriver) VS CDP(Playwright/opencli)
Selenium 是一套为了兼容所有浏览器而不得不做的“标准化HTTP API”，它通过模拟用户行为间接影响页面，胜在稳重但天生带着网络I/O的性能枷锁；而基于 CDP 的框架（如 Playwright/opencli）则是直接挂钩浏览器内核的“RPC后门”，通过长连接直击JS引擎和DOM内存，追求的是极速、高并发与绝对的控制力。
Selenium 诞生于 2004 年，而 CDP（Chrome DevTools Protocol）虽然在 2011 年就被引入 Chrome，但初期仅仅是给浏览器自带的 F12 开发者工具用的。
在长达十几年的 Web 2.0 时代，前端自动化测试是个刚需。Selenium 早早入场，把坑位占满了。绝大多数程序员一提到“自动化”，第一反应就是调库写 Selenium 脚本，这种“先入为主”的心智是很难被撼动的。
在 AI 出现之前，企业做自动化测试最核心的需求是什么？是跨浏览器兼容性（不仅要测 Chrome，还要测 Firefox、Safari、Edge 甚至老旧的 IE）。
Selenium：是个“世界公民”，所有浏览器都认它。
CDP：早年基本是 Chrome/Edge 的“御用通道”（直到近两年 Safari 和 Firefox 才开始慢慢跟进）。
如果一个公司只用 CDP 做测试，就意味着放弃了 30% 其他浏览器的用户。这在商业项目中是不可接受的。因此，CDP 当年只能在做“纯 Chrome 专属任务”（比如网页截图、生成 PDF）的小圈子里流行。
CDP 是一个偏底层的调试协议，它暴露的是极其繁杂的原子级操作（比如：监听某个网络请求、在内存里执行一段 JS）。
普通开发者去用 CDP 原生接口，简直是种折磨。一直到 2018 年，谷歌官方推出了基于 CDP 封装的 Puppeteer 框架，大家才发现：“哇，原来用 CDP 写爬虫这么爽！”。后来微软又推出了更好用的 Playwright。但即便如此，它们在生态体量上依然拼不过老牌的 Selenium。
但在 AI 时代，自动化的主体变成了“大模型 AI”。AI 有大模型幻觉，传统的 Selenium 那种死板的定位方式（XPath/CSS Selector）经常失效。此时，AI 需要的是一个能够实时双向通信、能给它返回完整网页结构、甚至能直接拦截修改网络请求的底层控制器——这正是 CDP 的强项。
所以，不是 CDP 不够好，而是以前的时代它英雄无用武之地。如今到了 AI 接管电脑的浪潮里，CDP 终于等到了属于它的主场。
# 分层分析
┌─────────────────────────────────────────────────┐ │ WebDriver │ │ (标准化测试协议 / 带外控制平面) │ └───────────────────────┬─────────────────────────┘ │ HTTP 1.1 (Request-Response) ┌───────────────────────▼─────────────────────────┐ │ Browser Driver │ │ (代理网关 / 协议转换器) │ └───────────────────────┬─────────────────────────┘ │ ┌───────────────────────▼─────────────────────────┐ │ CDP │ │ (Chrome 调试协议 / RPC通道) │ └───────────────────────┬─────────────────────────┘ │ WebSocket / Pipe (全双工) ┌───────────────────────▼─────────────────────────┐ │ Blink 渲染引擎 │ │ ┌─────────────┐ ┌──────────────────┐ │ │ │ DOM 树结构 │ ◄────── │ JS 引擎 (V8等) │ │ │ │ (UI 绑定) │ │ (逻辑执行环境) │ │ │ └─────────────┘ └──────────────────┘ │ └─────────────────────────────────────────────────┘
# Layer 4：WebDriver —— 定义在应用层的“标准化 API”
本质：它是一个位于应用层的协议标准（W3C Standard），而不是具体的技术实现。
工作机制：就像你调用一个 RESTful API 一样，WebDriver 规定了统一的 HTTP 端点（比如 /session/:id/element）。无论底层是谁，只要实现了这个标准，就能跨平台、跨浏览器工作。
痛点（从性能角度看）：它是严格的 Request-Response（请求-响应）模型。每执行一步操作（如 click()），都要经历一次完整的 HTTP 建链、传输、等待服务器处理、返回的过程。这在高并发或复杂场景下，网络 I/O 会成为巨大的性能瓶颈。
# Layer 3：Browser Driver (如 ChromeDriver) —— 协议转换网关
本质：一个独立于浏览器的代理服务器（Proxy/Gateway）。
工作机制：它起一个本地 HTTP 服务，接收 WebDriver 的 JSON 指令，将其翻译成浏览器内核能听懂的底层语言。它是 WebDriver 能够跨浏览器兼容的核心，但也增加了一层网络转发的延迟。
# Layer 2：CDP (Chrome DevTools Protocol) —— 内核级的 RPC 通道
本质：基于 WebSocket 的远程过程调用（RPC）协议。
工作机制：它直接挂钩在浏览器内核上。不同于 WebDriver 的“带外管理”，CDP 更像是一个“带内控制平面”。建立连接后，它通过长连接（Long-lived WebSocket）进行全双工通信。
性能碾压的优势：因为它是长连接，省去了每次请求的 TCP 握手和 Teardown 开销。更重要的是，它可以批量推送事件（比如网络请求拦截、Console 日志），而不需要客户端去轮询（Polling）。
# Layer 1：JS 引擎 & DOM —— 浏览器的“内存数据库与业务逻辑层”
JS 引擎（如 V8）：这就是浏览器这台服务器的“CPU/执行器”。它维护着 Call Stack（调用栈）和 Heap（堆内存）。
DOM（Document Object Model）：这是浏览器在内存中维护的一个树状数据结构（Document Tree）。它是 JS 与渲染层（Renderer）之间的桥梁（API）。
两者的耦合：JS 引擎执行脚本时，通过 DOM API 来修改内存中的节点对象。一旦 DOM 树发生变化，渲染引擎会触发 Reflow/Repaint 来更新 UI。