Chromedriver下载与版本匹配全攻略：官网挂了也能稳定获取驱动

你有没有遇到过这种早晨：自动化脚本昨天还跑得好好的，今天一启动就报错，说驱动和浏览器版本对不上。你一脸懵地打开Chromedriver官方下载页，准备下个新版本，结果页面转圈五分钟，最后只给你一片空白。干运维和自动化的人，十个里面至少八个和这个页面打过架。

这篇文章我不去分析那个官网为什么“看心情”才能访问，我只聊怎么解决问题。围绕“驱动文件从哪拿”“版本到底怎么匹配”“拿到手之后怎么不踩坑”“怎么把下载这件事彻底交给工具”四条线展开。无论你是初学者，还是正在维护一套持续集成的服务，都有对应的方案可以抄。

1. 动手前先锁死版本号：没有对应版本，换再多下载源也没用

1.1 版本匹配机制其实没那么复杂

很多人在官网打不开之后，第一反应是“随便找个地方下个Chromedriver装上”。这是最大的误区。Chromedriver和Chrome之间的关系不是“能用就行”，而是有严格的版本对应约束。好消息是，这个约束没有你想象的那么苛刻。

匹配规则很简单：大版本号必须一致。比如你的Chrome是120.0.6099.100，那Chromedriver只要是120开头的版本就行，后面的小版本差别不影响使用。120.0.6099.109、120.0.6099.99这些都可以跑。真正会让浏览器报错的是那种Chrome 120、Chromedriver 119甚至118的情况，一启动就会提示“This version of ChromeDriver only supports Chrome version 114”之类的错误。

所以，第一步永远都是先确认自己浏览器到底是什么版本。打开Chrome，在地址栏输入：

chrome://version

页面第一行就是完整的Chrome版本号。如果你习惯用命令行，也可以这样查：

# Windows "C:\Program Files\Google\Chrome\Application\chrome.exe" --version # macOS /Applications/Google Chrome.app/Contents/MacOS/Google Chrome --version # Linux google-chrome --version

拿到版本号之后，你要找的Chromedriver主版本就固定了，接下来不管从哪个渠道下载，心里都有底。

1.2 两条拿完整版本号的路子

有时候镜像目录不会直接显示“最新版推荐”这样的提示，你得自己判断该下哪个。两个方法都很实用。

方法一：在镜像站目录里按主版本号筛选。打开镜像目录之后，你会看到一堆以版本号命名的文件夹，比如120.0.6099.109/、119.0.6045.105/。优先选和你Chrome版本最近的那个目录。记住，目录里的版本号末尾比浏览器版本新一点或旧一点都无所谓，主版本号对齐就行。

方法二：用官方维护的JSON接口精确匹配。Google为了自动化测试专门维护了一份版本清单，包含历史上所有Chromedriver版本和对应的下载地址。这个接口路径稳定、数据完整，而且本身就是一个公开的JSON文件，非常适合脚本调用：

https://googlechromelabs.github.io/chrome-for-testing/known-good-versions-with-download-urls.json

文件体积有点大，浏览器直接打开可能比较吃力，建议用命令行拉取：

curl -s https://googlechromelabs.github.io/chrome-for-testing/known-good-versions-with-download-urls.json | grep -o '"version": "120[^"]*"' | tail -5

这样能快速筛出120大版本下最近的几个候选版本号。拿到完整版本号之后，再去镜像站找对应的目录，命中率几乎百分之百。

2. 官网打不开时的四条真实下载路线（附可用URL）

既然官网不稳定，那就绕开它。下面四条路线我都实测过，按推荐程度排序。

2.1 路线一：国内镜像站的Chromedriver目录

这是大多数人最省事的方案。熟悉Node生态的都知道那个镜像站，它除了同步npm包之外，还维护了一份完整的Chromedriver历史版本目录，地址是：

https://npmmirror.com/mirrors/chromedriver/

这个目录的结构非常规整，点进去是一个个版本号文件夹，再点进去就是对应平台的压缩包。Windows下载chromedriver_win32.zip，Linux下载chromedriver_linux64.zip，macOS根据芯片选择chromedriver_mac64.zip或chromedriver_mac_arm64.zip。

这个镜像的优点有两个：一是历史版本保留得很全，早期版本也能找到；二是国内服务器，访问速度比官方源稳定得多。缺点是偶尔会有同步延迟，最新版本可能要隔一天才出现。真遇到这种情况，用主版本号稍微往前退一个版本就行，不影响使用。

2.2 路线二：云厂商镜像站的通用目录格式

除了上面那个知名镜像，国内几个主流云厂商也提供开源软件的镜像服务，其中就包括Chromedriver。这类镜像的URL结构有规律可循，基本都是：

https://镜像域名/chromedriver/{版本号}/chromedriver_{平台}.zip

比如某个云镜像的路径就是：

https://某云镜像域名/chromedriver/120.0.6099.109/chromedriver_win32.zip

实际使用中你会发现，不同镜像站在版本同步及时性上各有差异。有个小技巧：如果某个镜像站点进去之后看到目录列表是空的，别马上放弃，换个云厂商的镜像再试。同类镜像往往互相补位，总有一个是好的。

2.3 路线三：官方JSON接口里的直接下载地址

这个思路很多人没想到：官网主网页打不开，不等于官方文件存储服务也挂了。尤其Google为Chrome for Testing准备的那套下载接口，数据是专门给机器用的，走的存储链路和普通网页不一样，可用性通常更高。

用我前面提到的那个JSON接口，找到目标版本号之后，直接看对应条目的downloads.chromedriver字段，里面按操作系统列出了直链URL。把这个URL复制到浏览器或者用curl下载即可：

curl -O https://storage.googleapis.com/chrome-for-testing-public/120.0.6099.109/win64/chromedriver-win64.zip

这个办法的好处是拿到的永远是官方原版文件，不用担心里面被塞了别的东西。配合脚本使用的话，这也是最“正规军”的拿驱动方式。

2.4 路线四：让Python库替我们下载和解压

不想手动比对版本号、不想自己解压文件的人，直接用自动化生态里现成的库。Python的webdriver-manager就是专门干这个的，它会自动读取你本机Chrome的版本，自动去下载匹配的Chromedriver，自动解压，自动缓存，整个过程不需要手动介入：

pip install webdriver-manager

from selenium import webdriver from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager service = Service(ChromeDriverManager().install()) driver = webdriver.Chrome(service=service) driver.get("https://example.com") print(driver.title) driver.quit()

如果默认下载源访问不畅，这个库也支持显式指定镜像地址，这个问题等你读到后面第4章，我会专门展开讲怎么配置。

3. 下载不等于能用：解压与授权环节的三个经典坑

很多人在下载前折腾了半天，一激动把文件解压出来就往代码里填路径，结果依然报错。文件拿到手只是第一步，下面的坑几乎人人都踩过至少一个。

3.1 Windows：解压位置、PATH路径和SmartScreen

Windows下最推荐的做法不是把chromedriver.exe随便扔到项目目录里，而是建一个统一的驱动目录，比如C:\WebDrivers，把chromedriver.exe放进去，然后把这个目录加入系统PATH。这样做的好处是，所有项目都能直接按文件名调用驱动，不用每个项目都配一份。

加入PATH的操作路径是：右键“此电脑” → 属性 → 高级系统设置 → 环境变量 → 系统变量里的Path → 新建 → 填入C:\WebDrivers。

第一次运行chromedriver.exe时，Windows Defender的SmartScreen大概率会弹一个拦截框，提示“已阻止此应用”。这是正常的，因为Chromedriver没有正式的代码签名证书。点“更多信息”，再选“仍要运行”即可。

如果你运气不好，双击驱动直接报0xc000007b错误，不用怀疑，大概率是系统缺了VC++运行库。去微软官网下载最新的Visual C++ Redistributable安装包装上，这个问题就能解决。

3.2 macOS/Linux：不是解压出来就能跑

这两个系统的坑比Windows更隐蔽。解压出来第一件事，必须给驱动文件加执行权限：

chmod +x chromedriver

不信邪的人会看到什么？Permission denied，或者是Selenium报“cannot find Chrome binary”。加完权限之后还要验证一下：

./chromedriver --version

能正常输出版本号，说明驱动本身没问题。

macOS还有一个特有的隔离属性问题。从网上下载的文件默认会被打上com.apple.quarantine标记，直接运行会被系统拦截。多出来的一步操作是：

xattr -d com.apple.quarantine chromedriver

如果忘了执行这一步，运行时会弹“无法验证开发者”的提示。另外，如果你的机器是Apple Silicon芯片，记得下载mac_arm64的包，别下成Intel版本。

3.3 报错信息对照表：排错比下载更有技术含量

把所有常见报错汇总成一张表，遇到问题直接对着查，比临时翻搜索引擎高效得多：

这张表我建议直接放进自己团队的排错手册里。排查问题的时候，先看报错的是“驱动本身不能运行”还是“驱动和浏览器没对接上”，方向对了，五分钟就能解决。

4. 把驱动交给自动化工具：Selenium Manager与webdriver-manager实操

手动下载驱动这事，偶尔一次两次还能忍，一旦你同时维护多个环境、多个版本的Chrome，或者要在持续集成流水线里跑测试，就会意识到：驱动管理必须自动化。

4.1 Selenium Manager：新版Selenium自带的驱动管家

从Selenium 4.6开始，官方直接在库内部集成了Selenium Manager。也就是说，只要你用的是比较新的Selenium版本，什么都不用配置，首次启动时会自动检测Chrome版本，然后自动下载匹配的Chromedriver到本地缓存目录，整个过程在日志里能看到类似“Driver located”的提示。

这意味着，以往那套“手动下载驱动、手动配置PATH、手动指定服务路径”的流程可以彻底废掉：

from selenium import webdriver # 就这一行，Selenium Manager自动处理驱动的下载与匹配 driver = webdriver.Chrome()

这个设计最大的价值是让新手少踩一半的坑。你不再需要关心驱动从哪来，只需要关心测试脚本逻辑本身。

如果希望驱动下载后缓存在项目指定的位置，还可以通过环境变量SE_CACHE_PATH来调整缓存目录。在持续集成环境中，提前把驱动打包进镜像或者挂载到共享缓存卷，这样每次跑任务就不需要重新下载了。

4.2 webdriver-manager的镜像配置进阶用法

即便Selenium Manager已经内置，我还是会向很多同事推荐webdriver-manager，因为它有一个Selenium Manager目前做得不够灵活的点：支持显式指定镜像下载源。前面第2章里提到的所有镜像地址，都可以直接填进来：

from selenium import webdriver from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager service = Service( ChromeDriverManager( version="120.0.6099.109", mirror="https://npmmirror.com/mirrors/chromedriver" ).install() ) driver = webdriver.Chrome(service=service)

这里的mirror参数是关键。它告诉库“别去官方源折腾了，直接去镜像站下载”。配合version参数，还能锁定你需要的精确版本，避免因为自动匹配到了错误版本而翻车。这在公司内部网络受限、或者官方源访问不稳定的场景下，价值非常大。

4.3 写一个不怕官网抽风的下载脚本

如果你的项目不是Python技术栈，或者你需要一个不依赖任何第三方库的通用方案，那就手动写一个下载脚本，把整个链路握在自己手里。思路是：先通过官方JSON接口拿版本和直链，再从直链下载，最后解压到约定目录。

下面提供一个Python版本的参考脚本：

import json import os import sys import zipfile import platform import requests VERSIONS_URL = "https://googlechromelabs.github.io/chrome-for-testing/known-good-versions-with-download-urls.json" TARGET_DIR = os.path.expanduser("~/webdrivers") def get_platform_key(): if platform.system() == "Windows": return "win64" if platform.system() == "Darwin": return "mac-arm64" if platform.machine() == "arm64" else "mac-x64" return "linux64" def find_latest_driver(major_version): data = requests.get(VERSIONS_URL, timeout=30).json() candidates = [ v for v in data["versions"] if v["version"].startswith(f"{major_version}.") and v.get("downloads", {}).get("chromedriver") ] if not candidates: sys.exit(f"没有找到主版本为 {major_version} 的驱动") return candidates[-1] def download_and_extract(version, platform_key): urls = { d["platform"]: d["url"] for d in version["downloads"]["chromedriver"] } url = urls.get(platform_key) if not url: sys.exit(f"当前平台 {platform_key} 无对应安装包") os.makedirs(TARGET_DIR, exist_ok=True) zip_path = os.path.join(TARGET_DIR, "chromedriver.zip") print(f"下载 {version['version']} ...") with requests.get(url, stream=True, timeout=120) as r: r.raise_for_status() with open(zip_path, "wb") as f: for chunk in r.iter_content(chunk_size=8192): f.write(chunk) with zipfile.ZipFile(zip_path, "r") as z: z.extractall(TARGET_DIR) os.remove(zip_path) print(f"驱动已解压到 {TARGET_DIR}") return os.path.join(TARGET_DIR, "chromedriver", "chromedriver") if __name__ == "__main__": major = sys.argv[1] if len(sys.argv) > 1 else "120" latest = find_latest_driver(major) driver_path = download_and_extract(latest, get_platform_key()) print(f"驱动路径: {driver_path}")

使用方式很简单，把脚本保存为fetch_driver.py，然后执行：

python fetch_driver.py 120

脚本会自动找到120主版本下最新的驱动，下载、解压，输出最终的驱动路径。把这个脚本集成到CI流水线里，每次跑测试前执行一次，驱动永远是最新且匹配的。

5. 最后的兜底方案：用Chrome for Testing绕开版本地狱

5.1 Chrome for Testing是什么

如果你已经被版本匹配折腾得心力交瘁，还有一个更彻底的办法：放弃“用日常Chrome配Chromedriver”的组合，改用Google专门为自动化测试打造的Chrome for Testing版本，简称Cft。

Cft的特别之处在于，它和对应版本的Chromedriver是同源发布、同步捆绑的。也就是说，你下载某个版本的Cft压缩包，解压后里面自带配套的Chromedriver，浏览器和驱动天然就是匹配好的，根本不给你制造版本不一致的机会。这个包同样在官方存储的下载接口里，JSON接口中downloads.chrome字段就是它的直链。

5.2 配合Selenium启动的完整流程

下载Cft包并解压，你会看到类似这样的目录结构（以Linux为例）：

chrome-linux64/ chrome chromedriver

注意，这个chromedriver就在浏览器可执行文件的同级目录下。Selenium启动时有两个地方要指定，一个是浏览器二进制路径，一个是驱动路径：

from selenium import webdriver from selenium.webdriver.chrome.options import Options from selenium.webdriver.chrome.service import Service options = Options() options.binary_location = "/opt/chrome-linux64/chrome" service = Service("/opt/chrome-linux64/chromedriver") driver = webdriver.Chrome(service=service, options=options) driver.get("https://example.com") print(driver.title) driver.quit()

这套方式对版本匹配的容错能力极强，因为你用的是浏览器+驱动的打包组合，任何版本对都是经过官方验证的。

5.3 使用Cft的几个注意事项

第一，Cft不会像日常Chrome那样自动更新，你需要定期去JSON接口查新版本，手动维护。第二，不要在Cft里登录日常账号，它是纯测试用途，环境隔离要做好。第三，如果你的日常浏览器是某个特定版本，Cft下载的版本可以自由选择，两者互不干扰，日常浏览器依然自动更新，Cft固定在测试版本上，这是它的核心优势。

在我自己维护的测试环境里，Cft是作为“最后一道保险”存在的。日常开发环境用Selenium Manager自动匹配，一旦发现官方源更新策略变动导致驱动落后，就切到Cft方案，稳定住测试环境。

最后再分享一点个人经验。Chromedriver官网打不开这事，在这个行业里跟“今天下雨”一样常见，所以真的不用烦躁。解决问题的关键从来不是死磕某一个页面，而是想清楚两件事：第一，版本号是否匹配；第二，下载渠道是否稳定。把这两点理顺了，官网挂不挂，都影响不到你。我现在的做法是：日常靠Selenium Manager自动匹配，团队CI里跑那个下载脚本，真要出状况就切Chrome for Testing兜底。这套组合拳打下来，已经很久没有被驱动问题打断过工作了。