简介：本资源面向Web自动化测试开发者与Selenium学习者，提供Windows 64位系统下ChromeDriver与Chrome浏览器的配套组合，解决版本不匹配导致的驱动兼容问题。压缩包共84个文件，约150.08MB，包含chromedriver.exe驱动主程序、chrome.exe等6个可执行文件、11个dll动态链接库、58个pak语言与界面资源包，以及json配置、bin快照、manifest版本清单等，覆盖驱动与浏览器运行所需的完整组件。其中ChromeDriver版本为123.0.6312.122，与同版本Chrome浏览器匹配，可直接用于搭建稳定的自动化测试环境。目前已有324人学习下载，适合需要快速部署Selenium测试环境、避免版本冲突的开发者参考使用，也可作为学习WebDriver协议与浏览器自动化原理的实践素材。
1. ChromeDriver+Chrome（win64）：版本对齐这件事，比写代码本身更折腾
在 Windows 64 位机器上跑 Selenium，十次有八次卡住的地方不是定位器写错，而是 ChromeDriver 和 Chrome 浏览器版本对不上。你装好了 Python、pip 了 selenium，代码也没问题，一运行就抛SessionNotCreatedException: This version of ChromeDriver only supports Chrome version XX。这个标题讲的就是这件事：在 win64 环境下，把 ChromeDriver 和 Chrome 浏览器的版本关系理清楚，让自动化脚本能稳定跑起来。适合正在做 Web 自动化测试、爬虫、RPA 的从业者，也适合刚接触 Selenium 但被版本问题反复卡住的新手。核心就一句话：Chrome 每次自动更新，ChromeDriver 必须跟着换，而 win64 下的路径、位数、环境变量又有它自己的坑。
2. 版本对应关系：ChromeDriver 和 Chrome 到底怎么配对
2.1 为什么 Chrome 一更新，ChromeDriver 就罢工
ChromeDriver 本质是一个实现了 WebDriver 协议的中转进程，它通过 DevTools Protocol 跟 Chrome 浏览器通信。Chrome 每个大版本会改动 CDP 的接口细节，ChromeDriver 必须针对对应版本的 CDP 做适配。所以 Chrome 从 136 升到 137，旧版 ChromeDriver 就无法跟新版 Chrome 建立会话，直接报版本不匹配。
这里有个很多人忽略的点：ChromeDriver 的版本号前三段必须和 Chrome 的前三段一致。比如 Chrome 是136.0.7103.114，ChromeDriver 就得是136.0.7103.x。第四段可以不严格对齐，但前三段必须匹配。这就是为什么你看到chromedriver 136下载这种搜索词——大家都是在追 Chrome 的版本号跑。
从 Chrome 115 开始，Google 调整了 ChromeDriver 的发布方式，改成了 Chrome for Testing 体系。以前有一个固定的下载页列出所有版本，现在需要通过 Chrome for Testing 的 JSON 接口来查。这个变化让很多人找不到下载入口，也是chromedriver下载地址成为高频搜索词的原因。
2.2 查版本、下驱动的完整操作路径
第一步，确认本机 Chrome 的精确版本。有三个方法，我一般用第一个：
# 方法1：通过注册表查（win64 最可靠） reg query "HKEY_CURRENT_USER\Software\Google\Chrome\BLBeacon" /v version # 方法2：通过 Chrome 界面 # 地址栏输入 chrome://version/ 回车，看第一行 # 方法3：通过 PowerShell 查文件版本 powershell -Command "(Get-Item 'C:\Program Files\Google\Chrome\Application\chrome.exe').VersionInfo.ProductVersion"注册表方式最稳，因为它读的是 Chrome 自己写入的版本记录，不受安装路径影响。如果你用的是便携版 Chrome，注册表可能没有记录，那就得用方法三直接读 exe 文件的版本信息。
第二步，根据 Chrome 版本号找到对应的 ChromeDriver。Chrome for Testing 提供了一个已知版本的查询接口：
# 查询最新稳定版 ChromeDriver 的下载地址（win64） # 返回 JSON 中包含 version 和 downloads.chromedriver 字段 curl -s https://googlechromelabs.github.io/chrome-for-testing/last-known-good-versions-with-downloads.json返回的 JSON 里，channels.Stable下面有version和downloads.chromedriver，其中platform为win64的那条就是你要的。如果你需要特定版本（比如公司测试环境锁定了 Chrome 136），可以用另一个接口：
# 查询所有可用版本号列表 curl -s https://googlechromelabs.github.io/chrome-for-testing/known-good-versions.json | python -c " import json,sys data = json.load(sys.stdin) for v in data['versions']: if v['version'].startswith('136.'): print(v['version']) "这段 Python 一行流的作用是从完整版本列表中筛出 136 开头的所有版本。参数说明：known-good-versions.json包含每个版本的完整号和对应的驱动下载路径，数据量比较大，建议用脚本过滤而不是肉眼翻。
第三步，下载并放置。win64 的 ChromeDriver 解压后是一个chromedriver.exe，你需要把它放到以下任一位置：
| 放置方式 | 路径 | 适用场景 |
|---|---|---|
| 系统 PATH 目录 | C:\Windows\System32或自定义 PATH | 全局使用，多项目共享 |
| Python 脚本同级目录 | 与.py文件同目录 | 单项目快速验证 |
| 指定路径传参 | 代码里写绝对路径 | 多版本共存，精确控制 |
我一般选第三种，因为测试机上有时候要同时维护两三个 Chrome 版本的兼容测试，放 PATH 里反而容易搞混。
2.3 在代码里锁定 ChromeDriver 路径
from selenium import webdriver from selenium.webdriver.chrome.service import Service from selenium.webdriver.chrome.options import Options # 指定 ChromeDriver 的绝对路径，避免 PATH 污染 service = Service(executable_path=r"D:\drivers\chromedriver_136\chromedriver.exe") # 指定 Chrome 浏览器的二进制路径（便携版或多版本共存时必须） options = Options() options.binary_location = r"C:\Program Files\Google\Chrome\Application\chrome.exe" # 常用启动参数 options.add_argument("--no-sandbox") # 避免权限问题导致的启动失败 options.add_argument("--disable-gpu") # win64 远程桌面环境下建议加 options.add_argument("--window-size=1920,1080") # 固定窗口尺寸，避免响应式布局干扰 driver = webdriver.Chrome(service=service, options=options) driver.get("https://www.example.com") print(driver.title) driver.quit()executable_path指向你解压出来的 chromedriver.exe，binary_location指向 Chrome 主程序。两个都写绝对路径的好处是：不管系统里装了几个 Chrome、PATH 里放了几个版本的驱动，这段代码的行为都是确定的。--no-sandbox在 Windows 上不是必须的，但在 CI 环境或权限受限的机器上能省掉很多玄学问题。
3. win64 环境下的部署细节：路径、位数与环境变量
3.1 32 位和 64 位驱动的选择
ChromeDriver 在 win64 平台上有专门的win64包，也有win32包。虽然 32 位的驱动在 64 位 Windows 上也能跑，但如果你用的是 64 位 Chrome，建议驱动也选 win64。混用虽然大多数时候没事，但在高并发或长时间运行的场景下，32 位驱动受限于内存寻址，可能出现莫名其妙的超时。
判断当前 Chrome 是 32 位还是 64 位：打开chrome://version/，看「命令行」那一行，如果路径里有Program Files (x86)就是 32 位，Program Files就是 64 位。win64 的驱动包解压后目录结构是chromedriver-win64/chromedriver.exe，别把整个文件夹丢进去，要的是那个 exe。
3.2 环境变量配置的两种做法
# 方法一：临时添加到当前会话的 PATH（cmd） set PATH=%PATH%;D:\drivers\chromedriver_136 # 方法二：永久添加到用户环境变量（PowerShell，需要管理员权限） [Environment]::SetEnvironmentVariable( "Path", [Environment]::GetEnvironmentVariable("Path", "User") + ";D:\drivers\chromedriver_136", "User" )方法一只在当前 cmd 窗口有效，关掉就没了，适合临时调试。方法二是永久写入用户级环境变量，不影响系统级配置，比较安全。改完之后要新开一个终端才生效，这个坑我踩过——改完环境变量在原来的窗口里怎么试都不行，以为配错了，其实是没刷新。
注意：如果你同时装了多个版本的 ChromeDriver 并且都在 PATH 里，Windows 会按 PATH 中的顺序找第一个匹配的。所以要么只保留一个在 PATH 里，要么在代码里写绝对路径。
3.3 用 webdriver-manager 自动管理版本
手动下载驱动这件事，在 Chrome 频繁更新的环境下确实烦。webdriver-manager这个库可以自动检测本机 Chrome 版本并下载匹配的驱动：
from selenium import webdriver from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager # webdriver-manager 会自动检测 Chrome 版本并下载对应驱动 service = Service(ChromeDriverManager().install()) driver = webdriver.Chrome(service=service) driver.get("https://www.example.com") driver.quit()ChromeDriverManager().install()会做三件事：读本机 Chrome 版本、查询匹配的驱动版本、下载并缓存到本地（Windows 下默认在~/.wdm目录）。下次运行时如果缓存命中就不会重复下载。这个方案适合个人开发和快速原型，但在 CI 环境里要注意缓存策略，否则每次构建都重新下载会拖慢流水线。
不过 webdriver-manager 也有翻车的时候：它依赖网络请求去查版本信息，如果公司网络有限制或者接口变动，就会卡住。所以生产环境我还是倾向于手动管理驱动版本，把 chromedriver.exe 作为项目资产一起版本控制。
4. 避坑与排查：版本对了但跑不起来的情况
4.1 坑一：SessionNotCreatedException 但版本号看起来是对的
现象：Chrome 是 136.0.7103.114，ChromeDriver 也是 136.0.7103.x，但启动就报SessionNotCreatedException。
原因：Chrome 后台自动更新了，实际运行的版本和你查到的版本不一致。Chrome 的更新是静默的，注册表里写的版本可能还是旧的，但内存里跑的是新版本。
解决：完全退出 Chrome（包括后台进程），重新打开chrome://version/确认。或者在任务管理器里把所有 Chrome 进程杀掉再查。更彻底的做法是关掉 Chrome 自动更新，在测试机上锁定版本。
4.2 坑二：chromedriver.exe 被杀毒软件拦截
现象：驱动文件明明在，路径也对，但代码报WebDriverException: 'chromedriver' executable needs to be in PATH或者直接超时。
原因：Windows Defender 或第三方杀毒软件把 chromedriver.exe 当成可疑程序隔离了。ChromeDriver 的行为模式（启动浏览器、注入脚本）确实容易被误判。
解决：把 chromedriver.exe 所在目录加入杀毒软件白名单。如果是公司统一管理的终端，可能需要找 IT 加例外规则。这个坑很隐蔽，因为文件看起来还在，但实际已经被隔离了。
4.3 坑三：多版本 Chrome 共存时 binary_location 没设对
现象：代码跑起来打开的是旧版 Chrome，或者打开 Chrome 后页面行为异常。
原因：系统里装了多个 Chrome（比如稳定版 + 测试版 + 便携版），options.binary_location没指定或者指错了，Selenium 用了默认路径的 Chrome，但 ChromeDriver 是按另一个版本下载的。
解决：始终显式设置binary_location，并且在代码注释里写清楚这个路径对应哪个版本。如果做多版本兼容测试，把不同版本的 Chrome 和对应的驱动分目录存放，用配置文件管理路径映射。
4.4 坑四：Chrome 自动更新导致 CI 流水线突然挂掉
现象：昨天还跑得好好的自动化测试，今天 CI 上全部失败，报版本不匹配。
原因：CI 机器上的 Chrome 自动更新到了新版本，但项目里锁定的 ChromeDriver 还是旧版。
解决：在 CI 环境里禁用 Chrome 自动更新。Windows 下可以通过组策略或注册表关闭：
# 关闭 Chrome 自动更新（需要管理员权限） reg add "HKLM\SOFTWARE\Policies\Google\Update" /v AutoUpdateCheckPeriodMinutes /t REG_DWORD /d 0 /f或者更简单的方式：在 CI 脚本开头加一步，每次构建时自动查询并下载匹配的驱动。这样虽然多花几秒下载时间，但不会因为版本漂移导致流水线挂掉。
4.5 坑五：headless 模式下窗口尺寸和普通模式不一致
现象：同样的代码，有界面时能跑通，切到 headless 就找不到元素。
原因：headless 模式默认窗口尺寸和普通模式不同，页面响应式布局会变化，导致元素位置或可见性改变。
解决：在 options 里显式设置--window-size，headless 和普通模式用同一个值。新版 Chrome 的 headless 模式（--headless=new）在渲染上更接近普通模式，建议用新参数替代旧的--headless。
5. 进阶技巧：把版本管理做成自动化流程
前面讲的都是手动对齐版本的方法，但如果你维护的测试机不止一台，或者 CI 每天跑几十次构建，手动管理迟早会出错。我现在的做法是写一个启动脚本，在每次运行测试之前自动完成版本检查和驱动更新。
import json import subprocess import urllib.request from pathlib import Path DRIVER_DIR = Path(r"D:\drivers\chromedriver_current") def get_chrome_version(): """从注册表读取本机 Chrome 版本号""" result = subprocess.run( ['reg', 'query', r'HKEY_CURRENT_USER\Software\Google\Chrome\BLBeacon', '/v', 'version'], capture_output=True, text=True ) # 输出格式: " version REG_SZ 136.0.7103.114" return result.stdout.strip().split()[-1] def get_matching_driver_url(chrome_version): """查询 Chrome for Testing 接口，找到匹配的驱动下载地址""" major = chrome_version.split('.')[0] api = "https://googlechromelabs.github.io/chrome-for-testing/known-good-versions-with-downloads.json" with urllib.request.urlopen(api) as resp: data = json.load(resp) # 从后往前找，优先取最新的匹配版本 for item in reversed(data['versions']): if item['version'].startswith(major + '.'): for dl in item['downloads'].get('chromedriver', []): if dl['platform'] == 'win64': return item['version'], dl['url'] raise RuntimeError(f"未找到匹配 Chrome {chrome_version} 的驱动") def ensure_driver(): """确保本地驱动与 Chrome 版本匹配""" chrome_ver = get_chrome_version() driver_ver_file = DRIVER_DIR / "version.txt" if driver_ver_file.exists(): cached = driver_ver_file.read_text().strip() if cached.split('.')[0] == chrome_ver.split('.')[0]: return # 大版本一致，直接复用 driver_ver, url = get_matching_driver_url(chrome_ver) print(f"Chrome {chrome_ver} -> 下载 ChromeDriver {driver_ver}") # 下载并解压（省略解压细节，可用 zipfile 模块） # ... DRIVER_DIR.mkdir(parents=True, exist_ok=True) driver_ver_file.write_text(driver_ver) if __name__ == "__main__": ensure_driver()这段脚本的核心逻辑是：读本机 Chrome 版本 → 查接口找匹配驱动 → 比对本地缓存 → 不匹配就下载。get_chrome_version用注册表查询，get_matching_driver_url从后往前遍历版本列表，优先取最新的匹配版本。缓存策略是只比对大版本号，因为小版本差异通常不影响兼容性。
几个参数需要根据实际情况调整：DRIVER_DIR改成你自己的驱动存放目录；如果公司网络访问不了外部接口，需要把 JSON 文件提前下载到本地，改成读本地文件；解压部分我用了zipfile模块但没展开写，实际使用时注意解压后把chromedriver.exe放到DRIVER_DIR根目录。
这个脚本我放在 CI 的 setup 阶段执行，每次构建前跑一次，耗时大概两三秒（有缓存的情况下）。自从加了这个步骤，因为版本不匹配导致的流水线失败基本没再出现过。血泪经验就是：版本对齐这件事，能自动化就别手动，手动迟早会忘。
还有一个细节值得注意：如果你用的是selenium4.x 版本，webdriver.Chrome()的初始化方式跟 3.x 有区别，executable_path参数被移到了Service对象里。网上很多老教程还在用webdriver.Chrome(executable_path="...")的写法，在 4.x 里会报TypeError。遇到这种报错先检查 selenium 版本，别急着怀疑驱动。
希望帮到你。
本文还有配套的精品资源，点击获取
