简介谷歌浏览器105.0.5195.102稳定版与其对应版本的Chromedriver整合包专为Python Selenium自动化开发者设计用于解决浏览器与驱动版本不匹配、环境配置繁琐等常见问题。压缩包内已包含完整的浏览器组件及chromedriver.exe使用者只需将整个解压包放入项目目录通过相对路径在代码中指定chrome.exe与chromedriver.exe的位置即可直接启动浏览器执行自动化任务也便于后续项目打包交付。整份资源共103个文件以pak资源文件、dll动态库、exe程序文件为主辅以json配置、png图标等均为浏览器运行所必需的组件压缩包整体大小约152.05MB结构清晰可直接作为项目子目录引用。目前已有730人学习下载。对于需要快速搭建Selenium环境、或希望将浏览器内核随项目一并分发的开发者而言该整合包能显著降低配置成本让自动化脚本更轻便地运行在不同机器上。1. Chrome 与 Chromedriver 版本对不上自动化脚本还没启动就翻车做 selenium 自动化十个翻车九个是 chrome 和 chromedriver 版本对不上。浏览器哪天手一抖自动升了级驱动还留在旧版本python 脚本一执行就抛 SessionNotCreatedException有人为这句话折腾一整天最后发现只是版本号差了两位。chrome chromedriver python selenium 是当下最常用的自动化组合也是整个环境里最容易坏的一环浏览器更新太随意驱动又没人记得同步。这篇按真实部署顺序走一遍——先定版本匹配规则再装 chrome、布置 chromedriver、配环境变量最后用一个不依赖外网的最小脚本验证跑通。适合正在搭 selenium 环境、被版本报错卡住、或者刚接手一个别人留下的自动化项目打算重装干净的开发者。2. 版本匹配规则大版本一致小版本就高2.1 为什么版本必须对齐Chromedriver 本质上是一个独立的服务它负责把 selenium 的指令翻译成 chrome 能听懂的 DevTools 协议再通过调试端口发给浏览器。浏览器升了级内部调试接口的握手方式和参数格式都可能变旧驱动还在用老一套说辞跟新浏览器打招呼对方自然不回应于是启动阶段直接失败。这也是为什么版本问题会最先暴露而不是等到你跑业务逻辑时才出岔子。从某个大版本开始Chromedriver 的版本号改为和 chrome 同步发布每个浏览器版本都会对应一个同名驱动版本。这带来一条明确规则chrome 的三段式版本号取第一段作为主版本号chromedriver 的主版本号必须和它一致。比如浏览器是 120 开头那驱动就用 120.x浏览器升到 121驱动就必须跟着换 121.x。次版本号理论上可以不一致但实用经验是驱动的小版本尽量选新一点的避免错过修复补丁。注意这里说的主版本一致是底线不是充分条件。有些场景里驱动小版本太旧即使主版本相同也会出怪问题最好的做法是直接用整合包或发布页里对应的固定组合。2.2 两条命令读出版本号装环境第一件事不是安装是先看清两边现状。很多人直接跳过这一步装完才发现版本不对又花时间回退我在部署时习惯先执行两条命令# 查看 chromedriver 版本 chromedriver --version # 查看 chrome 版本 google-chrome --version # Windows 下的 chrome 在安装目录下执行或者直接看 chrome://versionchromedriver 的 --version 输出一般长这样ChromeDriver 120.0.6099.109 (…)第一串数字就是它的主版本号。chrome 的 --version 输出则是 Google Chrome 120.0.6099.130 之类同样取第一串数字。两边一对照版本匹配问题能在装环境前就暴露。Windows 上如果 chrome 没进 PATH可以打开一个浏览器标签页地址栏输入 chrome://version页面里的“版本号”字段就是当前浏览器版本。理解这两条命令的输出格式比记住任何一张对照表都重要因为浏览器版本每个月都在变死记对应关系不如掌握自查方法。2.3 整合包为什么能省这一步版本匹配的难点不在于“知道要匹配”而在于“每次都要记得手动去查”。我见过一个团队五六台机器上跑同一套 python 脚本每个人 chrome 版本都不一样驱动也是各自下载的最后联调时发现同一段代码在不同机器上表现完全不同排查了半天才发现是版本漂移导致的。整合包的思路就是把 chrome 和对应版本的 chromedriver 绑在一起固定组合、固定路径、固定配置。下载下来解压就能用不用自己去逐版本核对对应关系也避免了“一边装了新版一边还拖着旧驱动”的典型事故。虽然多花一点点下载体积但换来的是一个确定性的环境在部署阶段省下的时间远远大于传输成本。3. 部署 Chrome 本体装对位置比装最新更重要3.1 Windows 安装默认路径是省心路径在 Windows 上装 chrome默认路径是 C:\Program Files\Google\Chrome\Application\chrome.exe。很多人为了“保持 C 盘干净”把浏览器改到 D 盘自定义目录这本身没毛病但 chromedriver 默认去标准路径找浏览器自定路径后就必须在代码里手动指定 binary_location漏掉这一步就会报找不到浏览器。我一般建议自动化专用机器上的 chrome 直接走默认路径安装。自动化环境和日常上网的浏览器最好分开如果机器上已经有日常用的 chrome那确保它升级到目标主版本就行chromedriver 按当前版本去配如果是要打包分发的机器默认路径装好后后面所有脚本都能少写一个参数。安装过程本身没有太多可选项一路下一步就好唯一要注意的是安装时别勾选“将 chrome 设置为默认浏览器”免得影响机器上其他程序。装完后用下面的命令确认一下安装位置和版本# 检查默认安装目录是否存在且可执行 C:\Program Files\Google\Chrome\Application\chrome.exe --version # 如果上面没有输出检查注册表里的安装路径 reg query HKLM\SOFTWARE\Google\Chrome\BLBeacon /v Path3.2 Linux 服务器安装别忘依赖库Linux 服务器上跑 selenium 自动化很常见尤其是一些定时任务和巡检脚本。很多人在这一步翻车chrome 明明装好了一执行却报缺少动态库。常规做法是通过包管理器安装以常见的 Debian 系为例# 先更新索引再安装 chrome 及其依赖 sudo apt update sudo apt install -y wget curl unzip # 下载浏览器安装包之后交给包管理器处理依赖 wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb sudo apt install -y ./google-chrome-stable_current_amd64.deb.deb 包的好处是 apt 会自动拉取大部分依赖库比如 libnss3、libxss1、libasound2 这些常见依赖。如果是 .tar.gz 方式解压的绿色版那依赖就得自己补齐常见报错是 error while loading shared libraries: libnss3.so这就是典型的 NSS 库缺失。我一般会先跑一下ldd /opt/chrome/chrome | grep not found看缺什么缺哪个补哪个比盲猜效率高得多。服务器上装 chrome 还有个常被忽略的点它默认以 root 身份跑的时候会触发沙箱限制报错开头是 Running as root without --no-sandbox is not supported。生产环境我的习惯是创建一个普通系统用户来跑自动化而不是用 --no-sandbox 绕过但如果只是临时验证环境加个参数也不是不行。3.3 装完先做一次 headless 冒烟装好浏览器后别急着配驱动先验证浏览器本身能跑起来。服务器没有显示器可以用 headless 模式做一次快速冒烟这一步能在十分钟内区分“浏览器没装好”和“驱动版本不对”两类问题# 以无头模式启动 chrome直接输出页面 DOM 到标准输出 google-chrome --headless --disable-gpu --dump-dom data:text/html,titlesmoke/titleh1ok/h1 2/dev/null # 如果能看到 h1ok/h1 这样的 HTML 输出浏览器基本可用这里三个参数各有用途--headless 让浏览器不弹窗口服务器上必须加--disable-gpu 是避免在无显卡环境下 GPU 初始化报错--dump-dom 表示加载完页面后立即把 DOM 内容打印出来适合做一次性验证。输出里能看到 h1 标签内容说明浏览器内核能正常加载页面接下来配驱动的底气就足了很多。4. 布置 Chromedriver环境变量与 Python 初始化一起做4.1 驱动目录一个固定目录Chromedriver 在 Windows 下是一个 chromedriver.exe在 Linux 下是一个名为 chromedriver 的可执行文件。很多初学者把它随便丢在下载文件夹里写代码时还得写一长串绝对路径去引用换台机器就失灵。我的做法是在固定位置建一个驱动的专属目录然后通过环境变量或代码里的常量去引用它# Linux 下建议放 /opt/drivers sudo mkdir -p /opt/drivers sudo mv chromedriver /opt/drivers/ sudo chmod x /opt/drivers/chromedriver # Windows 下建议建一个 D:\tools\drivers 之类的目录把 chromedriver.exe 放进去Linux 下一个很容易遗漏的步骤是 chmod x很多部署事故是驱动文件没有可执行权限导致的报错还不够明显会显示 Permission denied 然后误以为是代码问题。Windows 下虽然没有执行权限概念但同样要注意杀毒软件可能把 chromedriver.exe 误删后面常见问题里会单独说。4.2 环境变量三个最容易写错的路径把驱动目录加进 PATH是让代码里写 chromedriver 就能直接被找到的前提。Linux 下改环境变量最常用的是写入用户级配置# 追加到 ~/.bashrc echo export PATH/opt/drivers:$PATH ~/.bashrc source ~/.bashrc # 验证 chromedriver --version这段配置里最容易写错的三个地方一是路径写成了绝对路径却漏了斜杠比如把 /opt/drivers 写成 opt/driverssource 时报错不明显但命令就是执行失败二是 source 之后没验证就关终端新开的终端重新加载配置如果 .bashrc 语法有误命令直接找不到三是同一个机器上装过多个版本的驱动PATH 里前面的目录和后面的目录各有一个 chromedriver系统找到的是前面那个版本对不上时排查半天才发现是 PATH 顺序问题。Windows 下的配置路径类似右键“此电脑”进系统属性→高级→环境变量在用户变量的 Path 里新增一行驱动目录。注意改完后要重新打开命令行窗口旧窗口不会刷新环境变量。4.3 Python 侧初始化写法Selenium 4 的初始化方式比老版本清爽了很多Service 对象把驱动路径和参数集中放在一起也不再建议用 executable_path 老参数直接传给 WebDriver。我一般这样写from selenium import webdriver from selenium.webdriver.chrome.service import Service # 如果 chromedriver 已经进入 PATH这里可以直接用 Service() # 如果没进 PATH就显式指定路径两种方式留一个即可 service Service(executable_path/opt/drivers/chromedriver) options webdriver.ChromeOptions() # 服务器上建议开启 headless options.add_argument(--headlessnew) options.add_argument(--disable-gpu) driver webdriver.Chrome(serviceservice, optionsoptions) driver.get(data:text/html,titlecheck/title) print(driver.title) driver.quit()这段代码要说明两个关键点。第一Service 对象里的 executable_path 指向 chromedriver 的实际位置环境变量没配好时这是最可靠的兜底方式第二options 中的 --headlessnew 是 chrome 更新的无头模式语法老写法 --headless 在新版本上虽然还能兼容但不推荐。如果机器上没有图形环境不加这个参数启动就会报错这也是服务器跑自动化最常见的启动失败原因。Selenium 4.6 之后引入了 Selenium Manager会在没有指定驱动时自动去下载匹配版本的 chromedriver听起来很方便但我实际部署时还是倾向显式指定驱动路径原因在于自动下载依赖外网且每次环境初始化都有不确定性在离线环境或内网环境里自动下载直接失效。固定路径指定驱动环境才有确定性。5. 常见问题排查五条踩坑记录5.1 SessionNotCreatedException版本不一致的经典症状现象脚本启动的一瞬间就报错错误信息里通常有一句 this version of ChromeDriver only supports Chrome version 120, but you have version 121。原因两边主版本号不一致。要么 chrome 升级了驱动没跟上要么驱动虽然是新的但浏览器还是旧的。解决分别跑chrome --version和chromedriver --version看两个主版本号把版本低的一方升级或回退到与另一方一致。如果不想手动处理直接换用整合包里的固定组合把两端版本绑定在同一套上。这个报错表面吓人实际上是最容易修的确认版本一致后基本能解决九成。5.2 驱动进程残留端口被占导致假死现象脚本第一次能跑第二次启动时卡住或者报错 DevToolsActivePort file doesnt exist查看进程列表发现一堆 chrome 和 chromedriver 还活着。原因上一次脚本异常退出driver.quit() 没执行到chromedriver 和 chrome 子进程成了孤儿进程占着调试端口不放。第二次启动时新驱动想用同一端口端口被占握手失败。解决手动清理残留进程再跑。Linux 下用pkill -f chromedriver和pkill -f chromeWindows 下在任务管理器里结束所有 chromedriver.exe 和 chrome.exe或者用taskkill /F /IM chromedriver.exe。处理好遗留问题后还要给代码加上 try/finally 或上下文管理器确保 driver.quit() 一定会执行这是根治手段。5.3 找不到 Chrome 可执行文件现象报错信息为 cannot find Chrome binary但明明浏览器图标还在桌面上。原因chromedriver 默认去系统标准路径找浏览器比如 Windows 的 Program Files 或 Linux 的 /usr/bin如果浏览器装在自定义位置找不到是必然的。解决在初始化时显式指定浏览器路径options.binary_location /opt/chrome/chrome # Windows 示例 # options.binary_location rD:\Program Files\Google\Chrome\Application\chrome.exebinary_location 是 ChromeOptions 里专门指定浏览器可执行文件位置的参数优先级高于驱动里的默认探测逻辑。自定义安装路径的场景下这个参数几乎是必写的。5.4 Linux 缺动态库和沙箱限制现象chrome 启动时报 error while loading shared libraries: libnss3.so或者报 Running as root without --no-sandbox is not supported。原因前者是缺依赖.tar.gz 绿色版常见后者是 root 用户跑 chrome 时沙箱机制拒绝启动。解决缺库就补库用ldd /path/to/chrome | grep not found列出所有缺失的库再通过包管理器逐个安装。沙箱问题在测试环境临时加 --no-sandbox 参数能过但生产环境建议创建一个普通用户去跑自动化而不是开着 no-sandbox。顺便说一句容器环境里也需要处理沙箱很多 docker 镜像直接给 CHROME_OPTS 加 no-sandbox原理就在这里。5.5 Windows 下驱动被安全软件拦截现象chromedriver.exe 双击后一闪而过日志写不出脚本启动时报“拒绝访问”或找不到驱动文件去看驱动目录发现文件不在了。原因Windows Defender 或第三方安全软件把 chromedriver.exe 当成风险文件隔离或直接删除。这个文件本质是一个可执行工具被误杀的概率确实不低。解决把驱动目录加入安全软件的信任列表或者解压后立刻给目录加白名单然后重新解压一次驱动。如果是在受管环境里装自动化环境这一步最好提前跟管理员确认策略免得环境跑着跑着驱动被杀了。6. 装完怎么验证跑通最小冒烟脚本环境装完不能只停留在“版本能查出来”我习惯跑一个完整的、不依赖外网的最小脚本把所有环节串起来验证一遍chrome 能启动、chromedriver 能握手、python 能拿到页面信息。这个脚本不访问任何外部网站所以网络不通、网站反爬、DNS 出错这些变量全都被排除在外。from pathlib import Path from selenium import webdriver from selenium.webdriver.chrome.service import Service # 构造一个本地空白页面避免依赖外网 html htmlheadtitleselenium-smoke/title/headbodyok/body/html page Path(smoke.html).resolve() page.write_text(html, encodingutf-8) options webdriver.ChromeOptions() options.add_argument(--headlessnew) options.add_argument(--disable-gpu) service Service(executable_path/opt/drivers/chromedriver) driver webdriver.Chrome(serviceservice, optionsoptions) try: driver.get(page.as_uri()) title driver.title assert title selenium-smoke, ftitle mismatch: {title} print(PASS:, title) finally: driver.quit()这段脚本用到了三个关键点。page.write_text 把一段小 HTML 写到本地文件再通过 page.as_uri() 转成 file:// 链接driver.get 加载的是本地文件而不是外网地址这样整个验证过程完全离线。断言 title 的内容能同时验证浏览器启动了、驱动传输正常了、页面渲染完成了。最后用 finally 块保证 driver.quit() 必执行避免留下残留进程。如果输出 PASS: selenium-smoke那就说明整条链路已经跑通可以放心进入业务代码的编写。从那以后我每装一台机器的自动化环境都会强制把这段冒烟脚本走一遍不通过就不往下做。比所谓的“环境应该没问题”靠谱得多——环境这种事玄学少一点验证多一点希望这个流程也能帮到你。本文还有配套的精品资源点击获取