简介：这份整合包面向使用 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 = r'reg query "HKCU\Software\Google\Chrome\BLBeacon" /v version' out = subprocess.check_output(cmd, shell=True).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, platform="win64"): 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_ok=True) # 分别下载浏览器和驱动 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, indent=2) 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_path=driver_path) return webdriver.Chrome(service=service, options=options) 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 一定要写、一定要随包走，否则三个月后你自己都记不清这个包里到底是哪个版本。把版本自检做成启动时的默认动作，比事后排查省事得多。希望帮到你。
本文还有配套的精品资源，点击获取
