简介这份整合包面向使用 Python 做浏览器自动化的开发者尤其是 Selenium 项目实践者解决 Chrome 浏览器与驱动版本不匹配、项目打包后环境依赖缺失等常见痛点。包内为 Chrome 105.0.5195.102 稳定版包含 chromedriver.exe、chrome_proxy.exe 等完整浏览器组件可直接将整个解压目录放入项目通过相对路径引入即可调用无需再单独下载匹配驱动。资源共 103 个文件以 58 个 pak 资源包、12 个 dll 动态库、8 个 exe 可执行文件为主另含 json 配置、png 图标及 sig、bin、dat 等运行支撑文件压缩包约 152.05MB目录结构完整便于随项目整体分发。目前已有 729 人学习下载。对于需要将自动化脚本打包交付、或在离线环境中部署 Selenium 的开发者这份整合包能省去版本比对与驱动配置环节直接复用示例中的 ChromeOptions 与 ChromeService 写法即可启动浏览器降低环境搭建与迁移成本。1. 谷歌浏览器对应版本驱动整合包一次把版本错配的坑填平做 Web 自动化、爬虫或者 RPA 的人几乎都经历过同一个场景脚本昨天还跑得好好的今天一执行就抛出SessionNotCreatedException: This version of ChromeDriver only supports Chrome version XX。原因不复杂——谷歌浏览器在后台悄悄自动更新了而本地的 chromedriver 还停在旧版本两者大版本号一旦对不上Selenium 直接拒绝启动。所谓「谷歌浏览器对应版本驱动整合包」本质就是把浏览器安装包和与之严格匹配的驱动二进制打包在一起让版本对齐这件事从「每次手动查表下载」变成「开箱即用」。它解决的不是什么高深算法问题而是环境一致性这个最容易被忽视、又最消耗时间的工程细节。适合谁写自动化测试的、做数据采集的、跑 RPA 流程的以及任何需要在多台机器上批量部署浏览器环境的运维同学。这篇笔记就按「版本怎么对 → 整合包怎么搭 → 怎么用 → 坑在哪」的顺序把整套方案讲透。2. 版本对齐的底层逻辑Chrome 与 ChromeDriver 到底怎么匹配2.1 为什么大版本号必须一致ChromeDriver 是谷歌官方提供的、实现了 WebDriver 协议的独立进程Selenium 通过它来间接操控浏览器。它和 Chrome 之间走的是 DevTools Protocol这个协议在不同大版本之间会有增删改。所以 ChromeDriver 在启动时会主动校验目标 Chrome 的主版本号也就是版本号第一段一旦不匹配就直接拒绝服务连降级兼容的余地都不给。这里有个很多人搞混的点匹配规则只看主版本号。比如 Chrome 是131.0.6778.86那么 ChromeDriver 只要是131.x.x.x就能用不需要后三段完全一致。但反过来130.x的驱动配131.x的浏览器必挂。所以整合包的核心价值就是锁定「主版本号相同」这一对组合而不是追求逐位一致。另一个高频误区是以为驱动可以向下兼容多个版本。实际上从 Chrome 115 之后谷歌调整了分发策略Chrome for Testing 成为官方推荐的下载渠道驱动的版本粒度更细跨主版本兼容基本不存在。这也是为什么「整合包」这种形态最近一两年特别流行——手动去对版本号太折腾了。2.2 三种获取匹配驱动的路径对比在动手打包之前先想清楚驱动从哪来。常见做法有三条路各有适用场景获取方式版本覆盖是否需联网适用场景Chrome for Testing 官方端点115 以后全量需要新版本、CI 环境旧版 chromedriver 存储库115 以前需要维护老项目本地已缓存驱动 版本探测取决于缓存不需要内网、离线部署我一般会优先用 Chrome for Testing 的 JSON 端点来查版本因为它返回的是结构化数据能直接喂给脚本做自动匹配。旧版存储库虽然还在但目录结构混乱不适合自动化。离线场景就只能靠本地缓存这也是整合包要解决的问题——把浏览器和驱动一起塞进包里断网也能装。2.3 用脚本自动查出匹配的驱动版本手动查表容易出错写个脚本把「读本地 Chrome 版本 → 查可用驱动 → 下载对应文件」串起来才是可持续的做法。下面这段 Python 演示核心逻辑import json import re import subprocess import urllib.request # 1. 读取本地 Chrome 主版本号Windows 注册表方式 def get_local_chrome_major(): # 通过注册表查询已安装 Chrome 的版本 cmd rreg query HKCU\Software\Google\Chrome\BLBeacon /v version out subprocess.check_output(cmd, shellTrue).decode() version re.search(r(\d)\.\d\.\d\.\d, out).group(1) return version # 返回主版本号如 131 # 2. 从 Chrome for Testing 端点拉取已知版本清单 def fetch_known_versions(): url https://googlechromelabs.github.io/chrome-for-testing/known-good-versions-with-downloads.json with urllib.request.urlopen(url) as resp: return json.load(resp) # 3. 匹配主版本号取出对应平台的驱动下载地址 def pick_driver(data, major, platformwin64): for item in reversed(data[versions]): # 从新到旧找 if item[version].startswith(major .): for d in item[downloads].get(chromedriver, []): if d[platform] platform: return item[version], d[url] return None, None if __name__ __main__: major get_local_chrome_major() data fetch_known_versions() ver, url pick_driver(data, major) print(f本地主版本 {major} - 匹配驱动 {ver}) print(f下载地址: {url})逻辑说明第一步从注册表读版本比解析chrome://version页面稳定得多第二步拉官方 JSON这个文件同时包含浏览器和驱动的下载链接是整合包的数据源第三步用startswith(major .)做前缀匹配保证主版本一致。参数上platform可选win64、win32、mac-x64、linux64打包时按目标系统传参即可。注意reversed是为了优先拿最新的小版本避免匹配到过老的驱动。3. 整合包怎么搭目录结构、打包脚本与离线部署3.1 整合包的目录约定一个能直接分发的整合包目录结构必须让人一眼看懂否则接手的人还得猜哪个文件对应哪个版本。我一般用下面这套约定chrome-driver-bundle/ ├── chrome/ # 浏览器安装包或解压后的绿色版 │ └── chrome.exe ├── driver/ # 对应版本的驱动 │ └── chromedriver.exe ├── manifest.json # 版本清单记录两者版本号 ├── install.bat # 一键部署脚本 └── README.txt # 使用说明manifest.json是关键它把「这个包里 Chrome 是什么版本、驱动是什么版本」写死后续脚本读它就能自检不用再去猜。内容大致如下{ chrome_version: 131.0.6778.86, driver_version: 131.0.6778.86, platform: win64, packed_at: 2026-01-15 }3.2 用脚本把浏览器和驱动打进一个包打包这件事没必要手动拖文件写个脚本按 manifest 自动组装才能保证每次产出的包结构一致。下面这段演示从下载到组包的全流程import json import os import shutil import urllib.request import zipfile BUNDLE_DIR chrome-driver-bundle def download_and_extract(url, target_dir): # 下载 zip 并解压到指定目录 zip_path os.path.join(target_dir, tmp.zip) urllib.request.urlretrieve(url, zip_path) with zipfile.ZipFile(zip_path) as z: z.extractall(target_dir) os.remove(zip_path) def build_bundle(chrome_url, driver_url, manifest): os.makedirs(BUNDLE_DIR, exist_okTrue) # 分别下载浏览器和驱动 download_and_extract(chrome_url, os.path.join(BUNDLE_DIR, chrome)) download_and_extract(driver_url, os.path.join(BUNDLE_DIR, driver)) # 写入版本清单 with open(os.path.join(BUNDLE_DIR, manifest.json), w) as f: json.dump(manifest, f, indent2) print(整合包构建完成:, BUNDLE_DIR) if __name__ __main__: manifest { chrome_version: 131.0.6778.86, driver_version: 131.0.6778.86, platform: win64 } # 两个 URL 来自上一节的匹配结果 build_bundle( https://storage.googleapis.com/chrome-for-testing-public/131.0.6778.86/win64/chrome-win64.zip, https://storage.googleapis.com/chrome-for-testing-public/131.0.6778.86/win64/chromedriver-win64.zip, manifest )逻辑说明download_and_extract负责下载和解压解压后删掉临时 zip 避免包体膨胀build_bundle把浏览器和驱动分别放进chrome/和driver/子目录再写 manifest。参数上两个 URL 必须来自同一版本号这是整合包不翻车的底线。注意解压出来的目录名可能带平台后缀如chrome-win64实际打包时建议重命名成统一的chrome和driver方便脚本引用。3.3 离线部署时怎么让脚本找到驱动整合包分发到目标机器后最大的问题是「驱动路径写死导致换机器就失效」。稳妥做法是让代码从 manifest 反推路径而不是硬编码绝对路径import json import os from selenium import webdriver from selenium.webdriver.chrome.service import Service def create_driver(bundle_root): # 读取清单确认版本信息 with open(os.path.join(bundle_root, manifest.json)) as f: manifest json.load(f) driver_path os.path.join(bundle_root, driver, chromedriver.exe) chrome_path os.path.join(bundle_root, chrome, chrome.exe) # 显式指定浏览器和驱动路径避免走系统 PATH options webdriver.ChromeOptions() options.binary_location chrome_path service Service(executable_pathdriver_path) return webdriver.Chrome(serviceservice, optionsoptions) if __name__ __main__: driver create_driver(./chrome-driver-bundle) driver.get(https://example.com) print(driver.title) driver.quit()逻辑说明options.binary_location强制指定用整合包里的浏览器而不是系统装的那个这样即使目标机器上装了别的版本也不会串Service(executable_path...)同理锁定驱动。参数上bundle_root用相对路径配合部署脚本切换工作目录即可。这一步是整合包「自包含」的关键——不依赖系统环境变量才能真正做到拷过去就能跑。4. 避坑与排查整合包落地时最容易翻车的 5 个点4.1 现象脚本报 SessionNotCreated但版本号看着一样原因看着一样实际主版本不同。比如浏览器是131.0.6778.86驱动是131.0.6778.204主版本都是 131理论上能用但如果驱动是从旧存储库下的、构建号差太多偶尔也会出问题。更隐蔽的是浏览器被自动更新到了 132而整合包还是 131。解决在启动前加一道自检读 manifest 和实际浏览器版本做比对不一致就报警而不是硬跑。同时把浏览器的自动更新关掉避免整合包刚做好就失效。4.2 现象驱动能启动但页面加载一半就崩原因多半是浏览器和驱动的位数不匹配比如 64 位驱动配了 32 位浏览器或者反过来。整合包里如果混进了错误位数的文件表现就是这种「能连上但不稳定」。解决打包时严格按platform字段选文件win64对应 64 位别图省事混用。部署后可以用chrome.exe --version和驱动的--version各跑一次确认。4.3 现象换台机器就找不到 chromedriver原因代码里写了绝对路径或者依赖系统 PATH 里的驱动。整合包拷到新机器后路径变了自然找不到。解决统一用相对路径 manifest 反推如 3.3 节所示。部署脚本里先cd到包根目录再启动避免工作目录不一致。4.4 现象整合包体积异常大传输慢原因把浏览器的完整安装包和解压后的文件都塞进去了重复占用空间或者没清理下载的临时 zip。解决只保留解压后的绿色版目录删掉原始安装包和临时文件。浏览器解压后通常几百 MB驱动只有几 MB控制好这部分体积整合包才便于分发。4.5 现象多台机器同时跑驱动进程残留原因脚本异常退出时没调driver.quit()chromedriver 进程留在后台下次启动端口被占。解决用try/finally包住驱动生命周期确保无论如何都执行quit()。批量部署时可以在部署脚本里加一句清理残留进程的命令作为兜底。5. 进阶把整合包做成可自检、可升级的版本管理工具前面讲的整合包是「静态」的——打一次包用一段时间浏览器一更新就得重打。真正省心的做法是让整合包具备自检和增量升级能力。核心思路是manifest 里除了记录当前版本再存一个「检查更新」的端点脚本启动时比对本地版本和远端最新版本不一致就提示或自动拉取新驱动。具体实现上可以在 3.3 节的create_driver前面插一段版本校验import json import urllib.request def check_update(bundle_root): with open(f{bundle_root}/manifest.json) as f: local json.load(f) # 拉取远端最新稳定版信息 url https://googlechromelabs.github.io/chrome-for-testing/last-known-good-versions.json with urllib.request.urlopen(url) as resp: remote json.load(resp) latest remote[channels][Stable][version] if not latest.startswith(local[chrome_version].split(.)[0]): print(f检测到新主版本 {latest}当前整合包为 {local[chrome_version]}建议更新) return False return True这段逻辑的价值在于它只比对主版本号避免小版本频繁更新带来的无谓打扰。一旦主版本变了说明驱动必须换这时候再触发重新打包流程。参数上channels里除了Stable还有Beta、Dev、Canary生产环境只认Stable就行。再进一步可以把「重新打包」也脚本化——检测到新版本后自动调用第 3 章的build_bundle生成新的整合包目录旧包保留一份作为回滚点。这样整套流程就从「手动对版本」进化成了「版本自管理」。我自己的习惯是每次打包都带上日期后缀比如chrome-driver-bundle-20260115出问题时能立刻退回上一个可用版本这个后悔药比什么都实在。最后说个血泪经验整合包这东西最怕的不是做不出来而是做出来之后没人维护版本记录。manifest 一定要写、一定要随包走否则三个月后你自己都记不清这个包里到底是哪个版本。把版本自检做成启动时的默认动作比事后排查省事得多。希望帮到你。本文还有配套的精品资源点击获取
