Chrome Driver不是Chrome专用的——它是Chromium生态的通用控制中枢
你有没有遇到过这样的场景：CI流水线里，Chrome测试稳如泰山，Firefox却频频报element not interactable，Edge干脆连会话都创建失败？翻日志发现错误是session not created: This version of ChromeDriver only supports Chrome version XXX——可明明本地Chrome已经升级到最新版，驱动却还卡在上个月的手动下载包里。
这不是个别现象。2024年Q2全球浏览器份额中，Chrome（65.2%）、Edge（12.8%）、Firefox（7.1%）和Safari（18.3%，iOS/macOS主力）共同构成真实用户访问入口。但很多团队的自动化测试仍停留在“只跑Chrome”的舒适区，或靠人工维护四套驱动版本清单，每次浏览器升级都像拆弹——小心翼翼比对 chromedriver.chromium.org 上的兼容矩阵，生怕一个数字错位就让整个回归测试雪崩。
其实问题根源不在工具本身，而在于我们长期把chromedriver误解为“Chrome的司机”。它真正的角色，是WebDriver协议在Chromium系浏览器上的标准服务端实现——一个遵循W3C规范、通过HTTP暴露API、用CDP操控内核的轻量级代理进程。它不绑定Chrome品牌，只认Chromium内核版本。正因如此，同一份chromedriver v126既能驱动Chrome 126，也能驱动Edge 126（基于Chromium）、Brave 126，甚至国产双核浏览器的Chromium模式。
而真正让多浏览器测试从“高危操作”变成“日常流水线”的，不是更复杂的框架，而是WebDriverManager（WDM）这种看似简单却直击痛点的自动化治理机制。它不写测试用例，不设计Page Object，却默默解决了90%的环境类失败——驱动版本错配、系统架构不匹配、缓存路径混乱、跨平台二进制缺失……这些让工程师深夜改配置的琐碎问题，本不该出现在质量保障的核心链路上。
Chrome Driver的本质：协议翻译器 + 进程控制器
先破除一个迷思：Chrome Driver不是浏览器插件，也不是SDK库，它就是一个独立运行的HTTP服务进程（chromedriver.exe或chromedriver）。你执行webdriver.Chrome()时，Python/Java客户端做的第一件事，是启动这个进程并监听默认端口9515；然后所有find_element、click()调用，都会被序列化成JSON格式的HTTP请求，发往http://127.0.0.1:9515/session/xxx/click。
它的核心工作流只有三步：
- 接收请求：比如
POST /session → {"capabilities": {...}}创建会话； - 翻译协议：把WebDriver命令转成Chrome DevTools Protocol（CDP）指令，例如
element.click()→Input.dispatchMouseEvent+DOM.querySelector； - 控制进程：通过
--remote
