ChromeDriver不是“驱动”，而是Web自动化世界的翻译官与调度员
你有没有遇到过这样的场景：
-driver.find_element(By.ID, "submit")突然抛出TimeoutException，但页面明明已经渲染完成；
- CI流水线里Chrome启动失败，日志只有一行冰冷的session not created: This version of ChromeDriver only supports Chrome version XX；
- 用 Selenium 登录某电商网站，刚输完账号密码，页面就弹出“检测到自动化行为”，直接跳转验证码页；
- 或者更隐蔽的问题：本地跑得好好的脚本，一上Docker就卡在driver.get(...)，CPU空转，无报错、无响应。
这些问题背后，几乎都站着同一个角色——ChromeDriver。但它到底是谁？为什么必须和Chrome版本严丝合缝？为什么加了--no-sandbox还会启动失败？为什么execute_cdp_cmd能做到find_element做不到的事？
答案不在API文档里，而在它真实运行时的进程关系、协议流转与内存上下文中。
它不是驱动，是协议翻译中枢 + 进程协调器
先破一个广泛误解：ChromeDriver不是像显卡驱动那样“让硬件能被系统识别”的底层模块。它甚至不碰Chrome的二进制代码、不修改内存、不注入DLL或so。
它是一个独立进程（standalone binary），由Chromium团队维护，作用非常具体：
✅ 接收来自Selenium客户端的HTTP请求（遵循W3C WebDriver规范）；
✅ 启动并管理一个Chrome子进程（带调试端口）；
✅ 在自己和Chrome之间建立WebSocket连接，使用Chrome DevTools Protocol（CDP）发号施令；
✅ 把CDP返回的原始数据，“翻译”成WebDriver标准格式再塞回HTTP响应体。
换句话说：
Selenium说人话（RESTful JSON），ChromeDriver做翻译（协议桥接），Chrome只听CDP黑话（WebSocket二进制帧）。
这个三层结构，决定了所有稳定性、调试性、绕过反爬能力的上限与下限。
它怎么“叫醒”Chrome？一次会话背后的四步握手
当你写下这行代码：
driver = webdriver.Chrome(service=service, options=chrome_options)背后发生了一连串精密协作，远不止“打开浏览器”那么简单：
第一步：ChromeDriver HTTP服务就位
ChromeDriver启动后，立刻监听本地端口（默认9515），成为一个轻量级HTTP服务器。它不依赖Apache/Nginx，自带精简HTTP栈（基于C++的net/server）。
第二步：Selenium发来“建会话”请求
Selenium客户端向http://127.0.0.1:9515/session发起POST，body类似：
{ "capabilities": {
