1. 为什么需要 Chromium 历史版本离线安装包做前端自动化、浏览器兼容性测试或者 Electron 桌面应用开发的朋友大概率都遇到过这样的场景某个线上问题只在特定版本的 Chromium 内核上复现新版本浏览器早就修掉了或者公司内网环境完全隔离根本没法在线下载浏览器又或者你需要给一批测试机统一部署某个固定版本的 Chromium保证测试基线一致。这时候一个干净的、可离线部署的 Chromium 历史版本安装包就成了刚需。Chromium 和 Chrome 不一样它没有自动更新服务也没有 Google 的私有编解码器和品牌定制本质上就是一个开源浏览器内核的完整构建产物。正因为如此Chromium 的版本迭代非常快几乎每天都有新的快照构建而官方并不提供一个历史版本下载中心这样的页面。很多人第一次去找旧版本时会发现Chrome 的下载地址有规律可循但 Chromium 的构建产物散落在各个快照目录里没有索引没有说明找起来相当费劲。这篇文章要解决的问题很具体如何稳定、可复现地获取 Chromium 任意历史版本的离线安装包包括 Windows、macOS、Linux 三个平台以及如何验证下载下来的包是完整可用的。适合的人群包括做浏览器兼容性测试的 QA、开发 Electron/CEF 应用的工程师、需要在隔离网络环境部署浏览器的运维人员以及单纯想研究某个旧版本内核行为的开发者。读完你至少能掌握两套可用的下载路径一套走官方快照存储一套走社区维护的镜像索引并且知道每一套的坑在哪里。2. Chromium 版本号体系与快照存储机制拆解2.1 四段式版本号到底怎么看Chromium 的版本号是四段式的比如109.0.5414.74。这四段分别代表第一段109主版本号通常和当时的 Chrome 稳定版对齐是兼容性判断的主要依据。第二段0次版本号在 Chromium 里几乎恒为 0可以忽略。第三段5414构建号build number这是最关键的一段它对应到具体的代码提交位置同一个主版本下会有很多个构建号。第四段74补丁号patch number针对同一个构建号的小修复。很多人找版本时只记得主版本号比如我要 109但实际下载时你会发现光 109 这个主版本下就有几十个构建号。真正决定你下载哪个包的是第三段构建号。如果你只是要109 大版本那选该主版本下最后一个稳定构建即可如果你要复现某个精确的 bug那就必须锁定到完整的四段版本号。2.2 快照存储的目录结构Chromium 官方把每个平台的构建产物放在独立的快照存储桶里路径规律大致是这样的https://storage.googleapis.com/chromium-browser-snapshots/ ├── Win_x64/ │ └── build_number/ │ ├── chrome-win.zip │ └── ... ├── Mac/ │ └── build_number/ │ └── chrome-mac.zip ├── Linux_x64/ │ └── build_number/ │ └── chrome-linux.zip └── ...注意这里用的是**构建号build number**作为目录名不是版本号。也就是说你想下载109.0.5414.74得先知道它对应的构建号是多少。这个映射关系官方不直接给需要靠一个叫LAST_CHANGE的文件或者社区维护的版本映射表来查。提示快照存储桶里的构建是持续集成产物不是正式发布版。绝大多数情况下可用但偶尔会遇到某个构建号目录存在却缺少完整压缩包的情况下载前最好先确认目录内容。2.3 为什么官方不提供历史版本下载页这一点值得说清楚避免你白费力气去找。Chromium 项目本身定位是开源浏览器项目它的构建产物是给开发者和测试者用的中间产物不是面向终端用户的产品。Google 的商业浏览器 Chrome 才有正式的发布渠道和版本归档。所以 Chromium 的历史版本获取本质上是在考古持续集成系统的历史快照这就决定了下载方法必须围绕快照存储来设计而不是找一个官方下载按钮。理解了这一层你就明白为什么下面要介绍的两套方法都是间接的一套直接拼快照 URL一套借助社区维护的版本索引来定位构建号。3. 方法一直接拼接官方快照 URL 下载3.1 核心思路与适用场景这套方法最直接你知道构建号就能拼出下载地址。适合的场景是——你已经通过某种方式确定了目标构建号或者你只是想下载某个主版本下最新的构建那可以直接去查该主版本对应的最新构建号。优点是不依赖任何第三方服务只要官方快照存储还在地址就有效。缺点是你得先解决版本号到构建号的映射问题这一步是整套流程里最容易卡住的地方。3.2 确定目标构建号有三种常见途径可以拿到构建号途径一查官方版本映射文件。Chromium 项目在源码仓库里维护了一个chromiumdash数据源里面有各平台的版本到构建号的对应关系。这个数据是 JSON 格式的可以直接拉取解析。不过它对普通用户不算友好需要你会看 JSON 结构。途径二用社区维护的版本索引站。有一些第三方站点专门做了 Chromium 版本查询输入版本号就能给出构建号和下载链接。这类站点更新及时用起来最省事但要注意甄别选那些长期维护、口碑稳定的。途径三从LAST_CHANGE反推。每个平台的快照目录下都有一个LAST_CHANGE文件里面记录的是当前最新构建号。如果你要的是最新直接读它就行如果你要的是历史某个版本就得结合版本映射表来定位。我个人的习惯是先用社区索引站快速定位构建号再用官方快照 URL 下载。这样既省了查映射的功夫又保证了下载源是官方的可靠性最高。3.3 拼接下载地址的实操假设你已经查到目标构建号是1070081平台是 Windows 64 位那么下载地址就是https://storage.googleapis.com/chromium-browser-snapshots/Win_x64/1070081/chrome-win.zipmacOS 对应https://storage.googleapis.com/chromium-browser-snapshots/Mac/1070081/chrome-mac.zipLinux 64 位对应https://storage.googleapis.com/chromium-browser-snapshots/Linux_x64/1070081/chrome-linux.zip用命令行下载的话curl或wget都行# 下载 Windows 64 位构建 curl -L -o chrome-win-1070081.zip \ https://storage.googleapis.com/chromium-browser-snapshots/Win_x64/1070081/chrome-win.zip # 下载 Linux 64 位构建 wget -O chrome-linux-1070081.zip \ https://storage.googleapis.com/chromium-browser-snapshots/Linux_x64/1070081/chrome-linux.zip-L参数是必须的因为快照存储会做一次重定向。下载完成后Windows 包解压出来是chrome-win目录里面直接就是可执行文件不需要安装绿色运行。3.4 平台与架构的对应关系不同平台的目录名容易搞混这里整理一张对照表平台架构快照目录名压缩包名Windows64 位Win_x64chrome-win.zipWindows32 位Winchrome-win32.zipmacOSIntel/ARM 通用Macchrome-mac.zipLinux64 位Linux_x64chrome-linux.zipLinuxARM64Linux_ARM_Cross-Compilechrome-linux.zip注意32 位 Windows 的目录名是Win不是Win_x86这个坑很多人踩过。另外 macOS 的快照包是通用二进制Intel 和 Apple Silicon 都能跑不用分开下。3.5 下载后的完整性校验快照存储里每个构建目录下通常还有一个chromium-browser-snapshots的校验文件或者你可以通过对比文件大小来初步判断。更稳妥的做法是解压后直接运行看版本号是否匹配# Linux 下查看版本 ./chrome-linux/chrome --version # Windows 下PowerShell .\chrome-win\chrome.exe --version如果输出的版本号和你预期的四段版本号一致说明包没问题。如果解压报错或者运行崩溃大概率是下载不完整重新下一遍即可。4. 方法二借助社区版本索引站定位4.1 为什么需要第二套方法方法一的前提是你已经知道构建号。但现实中更多的情况是你只知道我要 109 稳定版或者我要 2023 年 1 月左右的版本根本不知道构建号。这时候就需要一个能把版本号/日期翻译成构建号的工具社区版本索引站就是干这个的。这类站点的价值在于它们维护了完整的版本-构建号映射表并且提供搜索和筛选。你输入主版本号它列出该版本下所有构建你输入日期它给出那天的构建号。对于做兼容性测试的人来说这个能力比下载本身还重要。4.2 典型索引站的使用方式这类站点通常提供几种查询入口按版本号查输入109.0.5414.74直接给出构建号和下载链接。按主版本查输入109列出该主版本下所有构建号及对应日期。按日期查输入2023-01-15给出当天前后的构建号。按平台筛选限定 Windows/macOS/Linux避免拿到不相关的结果。使用时的关键动作是交叉验证索引站给出的构建号最好再用方法一的官方 URL 试一下确认目录真实存在。因为索引站的数据可能有延迟偶尔会出现索引里有但官方已清理的情况。4.3 版本号与构建号的映射逻辑这里补充一个背景知识帮你理解为什么映射会存在偏差。Chromium 的构建是持续集成的每天可能产生多个构建号。但版本号是在代码里定义的只有当代码里的版本号字段被更新时版本号才会跳变。所以会出现多个构建号对应同一个版本号或者某个版本号只在很短的构建区间内存在。这就解释了为什么你查109.0.5414.74时索引站可能给出好几个构建号——它们都是这个版本号的有效构建选哪个都行一般选最新的那个。而如果你要的是109 主版本那范围就大得多从 109 的第一个构建到最后一个构建都算。4.4 下载加速与镜像选择官方快照存储在国内访问速度不稳定这是实话。如果你需要批量下载或者下载大包可以考虑使用支持断点续传的下载工具避免中途断线重来。选择地理位置更近的镜像源部分社区镜像会同步官方快照速度会好一些。错峰下载快照存储的负载在不同时段差异明显。需要强调的是无论用哪个镜像下载后都要校验版本号确保拿到的包和你要的版本一致。镜像同步可能有延迟偶尔会拿到旧数据。5. 三大平台的部署与运行要点5.1 Windows 平台的绿色部署Windows 的 Chromium 快照包解压后就是一个完整目录双击chrome.exe即可运行。但有几个细节要注意不要放在带中文或空格的路径下某些旧版本对路径编码处理有问题可能导致启动失败。首次运行可能提示缺少 DLL这是因为快照包依赖系统的一些运行库装一下常见的运行库合集即可。多版本共存把不同版本的目录分别命名比如chromium-109、chromium-120各自独立互不干扰。测试时直接进对应目录启动。如果你要做自动化测试可以把chrome.exe的路径写进测试框架的配置里指定用哪个版本的 Chromium这样就能精确控制测试环境。5.2 macOS 平台的运行与签名问题macOS 的快照包解压后是Chromium.app直接拖到应用程序目录或者就地运行都行。但 macOS 的 Gatekeeper 会拦截未签名的应用第一次打开时可能提示无法验证开发者。解决办法右键点击应用选择打开在弹窗里确认一次之后就能正常启动了。或者在系统设置 - 隐私与安全性里允许该应用运行。另外macOS 上多版本共存时建议把不同版本的.app重命名比如Chromium-109.app避免 Launchpad 里混淆。5.3 Linux 平台的依赖处理Linux 快照包解压后是chrome-linux目录里面有个chrome可执行文件。直接运行可能报缺库常见的是缺libnss3、libatk、libgbm等。用包管理器补上即可# Debian/Ubuntu 系 sudo apt-get install -y libnss3 libatk1.0-0 libatk-bridge2.0-0 \ libcups2 libdrm2 libgbm1 libasound2 libxkbcommon0 libxcomposite1 \ libxdamage1 libxrandr2 libpango-1.0-0 libcairo2 # RHEL/CentOS 系 sudo yum install -y nss atk at-spi2-atk cups-libs libdrm mesa-libgbm \ alsa-lib libxkbcommon libXcomposite libXdamage libXrandr pango cairo如果是在无图形界面的服务器上跑还需要xvfb来做虚拟显示sudo apt-get install -y xvfb xvfb-run -a ./chrome-linux/chrome --headless --version提示Linux 下用--no-sandbox参数可以绕过沙箱但仅建议在受控的测试环境里用生产环境不要加这个参数。6. 常见问题与排查技巧实录6.1 下载地址 404 怎么办最常见的原因是构建号写错了或者该构建号在官方存储里已被清理。排查顺序确认构建号是否正确重新从索引站核对一遍。确认平台目录名是否正确参考 3.4 的对照表。如果确认无误还是 404说明该构建已被官方清理换一个相邻的构建号试试。官方快照存储会定期清理过旧的构建所以特别老的版本比如几年前的可能已经不在官方存储里了。这种情况下只能找社区备份或者用方法二里提到的镜像源。6.2 下载下来的包解压报错多半是下载不完整。快照包动辄上百 MB网络不稳时容易断。解决办法用curl -C -或wget -c断点续传。下载后对比文件大小和索引站标注的大小核对。用unzip -t测试压缩包完整性unzip -t chrome-win-1070081.zip如果测试报错重新下载。6.3 运行后版本号对不上这种情况通常是拿错了包。比如你要 Windows 64 位结果下成了 32 位的Win目录。或者索引站数据有误给出的构建号对应的实际版本和你预期不符。解决办法就是运行--version确认对不上就重新定位构建号。6.4 多版本共存时的配置隔离做兼容性测试时经常需要同时装好几个版本。除了目录分开还要注意用户数据目录隔离。Chromium 默认会把用户数据存在系统目录里多版本共用会互相污染。启动时加参数指定独立的数据目录./chrome --user-data-dir/tmp/chromium-109-profile这样每个版本用各自的 profile测试结果才干净。6.5 常见问题速查表问题现象可能原因解决方向下载 404构建号错误/已被清理核对构建号换相邻版本解压报错下载不完整断点续传重下校验大小启动缺 DLL/so系统运行库缺失补装运行库版本号对不上平台/架构拿错核对目录名重下多版本互相影响用户数据目录共用加 --user-data-dir 隔离macOS 无法打开Gatekeeper 拦截右键打开或放行6.6 几个我踩过的坑第一个坑是把构建号当成版本号。刚开始我以为目录名就是版本号结果拼出来的 URL 全是 404。后来才明白目录名是构建号得先做映射。第二个坑是忽略了 32 位和 64 位的目录名差异。Windows 32 位的目录叫Win我一开始按Win_x86拼怎么都不对。第三个坑是在无图形界面的 Linux 上直接跑报了一堆显示相关的错。后来加了xvfb-run和--headless才正常。第四个坑是多版本共用 profile导致测试结果不稳定排查了半天才发现是数据目录污染。加上--user-data-dir之后问题消失。7. 批量获取与自动化脚本思路7.1 用脚本批量下载多个版本如果你需要一次性准备多个版本的测试环境手动一个个下太慢。可以写个简单的 shell 脚本把构建号列表读进来循环下载#!/bin/bash # 批量下载 Chromium 快照包 PLATFORMWin_x64 PACKAGEchrome-win.zip BUILDS(1070081 1080000 1090000) for build in ${BUILDS[]}; do urlhttps://storage.googleapis.com/chromium-browser-snapshots/${PLATFORM}/${build}/${PACKAGE} outchromium-${build}.zip echo Downloading build ${build}... curl -L -C - -o ${out} ${url} if [ $? -eq 0 ]; then echo OK: ${out} else echo FAILED: ${build} fi done这个脚本的关键点是-C -断点续传以及失败后不中断整个循环方便你事后补下失败的。7.2 自动校验下载结果下载完自动校验版本号能省不少事。思路是解压后运行--version把输出和预期版本比对#!/bin/bash # 校验已下载的 Chromium 版本 EXPECTED109.0.5414.74 ACTUAL$(./chrome-linux/chrome --version | awk {print $2}) if [ $ACTUAL $EXPECTED ]; then echo 版本匹配: $ACTUAL else echo 版本不匹配: 期望 $EXPECTED, 实际 $ACTUAL fiWindows 下可以用 PowerShell 做类似的事思路一样。7.3 版本清单的维护建议做兼容性测试的团队建议维护一份自己的版本清单记录每个测试基线对应的构建号、下载日期、校验结果。这样下次要复现同样的环境直接照单下载即可不用重新查映射。清单可以用简单的 CSV 或 Markdown 表格维护字段包括版本号、构建号、平台、下载日期、校验状态。这份清单的价值在于可复现性。浏览器兼容性测试最怕的就是上次能复现这次环境变了复现不了有了清单环境就能精确重建。8. 关于版本选择的一点个人经验最后聊点实际的。很多人找历史版本时容易陷入越精确越好的误区非要找到某个四段版本号完全一致的构建。但实际上对于大多数兼容性测试场景锁定到主版本就足够了。比如你要测109 内核的行为那 109 主版本下任意一个稳定构建都能满足没必要纠结补丁号。真正需要精确到四段版本号的场景其实很少主要是两类一是复现某个已知的、和特定补丁相关的 bug二是你的应用对内核版本有硬性依赖差一个补丁号就出问题。除此之外主版本对齐即可。另外下载历史版本时优先选该主版本下较新的构建因为越新的构建修复的已知问题越多测试时遇到的内核自身 bug干扰越少。除非你的目的就是复现旧 bug否则没必要用该主版本最早的构建。还有一点Chromium 快照包是未签名的开发构建不适合直接分发给终端用户使用只适合开发、测试、研究场景。如果你是要给用户部署浏览器应该用正式发布的浏览器产品而不是 Chromium 快照。这个边界要分清楚避免用错场景。我在实际项目里的做法是维护一个常用测试基线清单每个基线对应一个主版本记录该主版本下我验证过可用的构建号。新项目需要测试时直接从清单里挑不临时去找。这样既省时间又保证了团队内环境一致。清单大概长这样主版本构建号平台用途验证日期1091070081Win_x64旧内核兼容测试2024-011201180000Win_x64当前基线2024-061091070081Linux_x64CI 环境2024-01这份清单不需要多复杂关键是团队共享、定期更新。每次有人验证了一个新版本可用就加一行进去。时间长了这就是团队最宝贵的环境资产。