Chrome历史版本下载全攻略：官方接口+脚本实操+避坑指南-开发者社区

简介：这是一份面向开发者和测试人员的Chrome/Chromium历史版本归档资源，解决因兼容性测试、功能验证或版本回滚需要下载旧版浏览器的问题。压缩包共450KB，包含14个文件，其中6个JSON记录版本、操作系统与位置等元数据，另有SVG图标、CSS样式、JavaScript脚本、HTML页面及说明文档，整体呈现一个可直接运行的版本查询工具或静态站点。已有9570人学习下载。通过该资源可快速检索特定Chrome/Chromium历史版本对应的下载入口，了解版本号与操作系统的匹配关系，同时熟悉以HTML+CSS+JS构建轻量级查询工具的思路；配有的README和版本映射JSON，便于二次开发时扩展数据或调整展示逻辑。适合需要批量比对历史版本、搭建内部下载索引或研究Chromium发布规律的技术人员。

1. 下载-Chrome的历史版本：为什么“装个旧版”会变成一项工程

做前端兼容测试、给老机器装浏览器、复现用户那边独有的白屏问题，你会很快撞上一个矛盾：Chrome 默认只会悄无声息地更新到最新版，官方首页也只给当前版本。想拿到“某个具体历史版本”的安装包，很多人第一反应是去第三方网站搜，结果不是下到捆绑 installer，就是装完发现版本根本不是自己要的那个。这篇笔记就用一条完整的实操路径说清楚：去哪儿找、怎么精准命中、装完怎么防它被自动升级覆盖。

要说明的是，这里讨论的都是正规下载与离线安装手段，不涉及任何规避网络限制的工具或插件。适合开发测试、企业内网基线部署、老设备兼容性验证这几类场景。

2. 从哪找历史版本：官方通道与第三方存档的取舍

2.1 Chrome 的发布节奏和自动更新机制，决定了旧版本“天生难找”

Chrome 的分发方式和其他软件不太一样。它不是一个“你下载了就一直用这个文件”的软件，而是一个带强自动更新策略的浏览器。官方分 Stable、Beta、Dev、Canary 四个渠道，其中 Stable 就是绝大多数人日常使用的渠道，每隔几周就会推出一个新的大版本；Beta 和 Dev 是预发布渠道，Canary 则是几乎每日更新的实验渠道。

由于自动更新默认开启，普通人装上 Chrome 之后根本感觉不到“版本”这个概念，它永远在后台默默换新。而对企业或开发者来说，这恰恰是最麻烦的一点：你的自动化测试脚本、企业内部的 Web 应用、某些只兼容旧内核的网页系统，往往只在一段特定版本区间内表现正常。你不可能跟用户说“请你在设置里关掉自动更新”，因为大多数人不会，也找不到那个入口。

这就引出一个核心结论：下载历史版本的刚需是真实存在的，但 Chrome 官方并没有把“历史版本下载页”做成一个公开的常驻页面。它更希望你始终用最新版。所以做这件事的正路，是利用官方提供的版本历史查询接口，拿到准确的版本号和官方下载地址，再配合离线安装包完成部署。第三方存档站只是退而求其次的备选，且风险不小。

这里先说清楚一个容易被混淆的点：历史版本不等于“所有老版本都能直接覆盖安装”。Chrome 安装包本身是支持完整离线安装的，但版本之间有明显的前后关系约束，你没法用一个老版本直接盖在一个新版本之上。这个约束后面会专门讲，先记住“下载”只是第一步，装得上、装完不被更新，才是完整闭环。

2.2 正路：官方版本历史接口与官方下载节点的组合

我一般会先打开 Chrome 官方提供的版本历史接口拿数据。这个接口的域名形如versionhistory.googleapis.com，根路径下按platform / channel / version的层级组织数据。官方用它来同步各渠道、各平台、各版本对应的版本号与发布时间，数据是公开的，不需要任何登录凭据。

常见的做法是分三步走：

先确定你要哪个平台：Windows、Mac、Linux，或者 Android。接口里的平台标识是win、mac、linux、android这类短名称。
再确定渠道：stable、beta、dev、canary四选一。日常测试绝大多数用stable。
最后从返回的列表里挑版本号。列表顺序一般按发布时间从近到远排列，最顶部是当前最新，往后翻就是历史版本。

这一步不需要任何特殊工具，浏览器直接访问接口地址就能看到 JSON 返回。比如你想看 Windows 平台 Stable 渠道有哪些版本，接口路径大致是/v1/chrome/platforms/win/channels/stable/versions，返回的versions数组里每一项都带version和release_time字段。我通常只关心这两个字段，一个用来对版本号，一个用来判断这个版本是不是接近我要的时间点。

真正的下载文件，则统一存放在官方下载节点（域名形如dl.google.com）下。不同平台的安装包命名和路径有规律，Windows 的安装包常见名字里带chrome_installer.exe或类似特征，macOS 则是.dmg或.pkg后缀。这里有个关键点：官方下载节点只保留近期版本的直链，更老的版本文件不一定还在原路径上。所以我对“官方历史版本”这件事的理解是：版本信息是完整的，文件本身则有时效性。

把这两点连起来，就是完整方案：先用官方接口确定版本号，再向官方下载节点发起请求。全程不经过第三方，文件来源可控，校验也简单。

2.3 备用路：第三方归档站与自建存档的适用范围

第三方 Chrome 历史版本站是真实存在的，做这件事的人也确实是出于方便开发者的目的。这类站点的价值在于：它们把各平台的安装包按版本号整理成了列表页，省去了你自己拼接口的步骤。对只想要一个特定版本、且只需要下载一次的人来说，这看起来确实更省事。

但你得清楚第三方站点的三个风险。第一，文件来源不可控。站点管理员从哪拿的安装包、有没有被二次打包，你无法验证。第二，捆绑风险。部分站点会在安装包里塞推广组件或改写安装逻辑，装完浏览器之后系统里多出几个“全家桶”是很常见的事。第三，版本陈旧。很多归档站更新到某一年就不再维护了，找新版本还得回官方接口。

我自己的习惯是这样的：优先官方接口取版本号，优先官方下载节点取文件；官方节点已经没有旧文件时，再去第三方站，但下载后必须做两步校验——看文件数字签名是否有效，以及安装包的 SHA256 是否与官方渠道记录的数值一致（如果能找到对照）。自建存档是团队级做法：公司内部搭一个共享目录，把经校验的历史安装包按版本号归档，之后新同事做兼容测试时不用再全网找，直接内网取。这属于一劳永逸的投入，建议测试团队或经常要处置老系统兼容问题的部门做一次。

为方便决策，下面是一个简短的渠道对比：

渠道	可信度	版本覆盖	典型风险	适合场景
官方版本历史接口 + 官方下载节点	高	近期版本齐全，较老版本文件可能下架	接口返回英文数据，需自己解析	开发、测试、企业部署的默认首选
第三方归档站	中	覆盖年份范围大，老版本相对齐全	二次打包、捆绑安装、签名损坏	官方文件已下架时的备选，下载后必须校验
团队内网自建存档	高	取决于内部维护范围	需人工维护，版本滞后	反复用同一批旧版本的团队

3. 用脚本直接命中指定版本：命令行下载的完整流程

3.1 先读懂版本号：四位段号与你的真实诉求怎么对应

Chrome 版本号是典型的四段主版本格式，比如116.0.5845.188。这四段分别是：大版本号、分支基准号、构建号、补丁号。对大多数场景来说，你只需要关注第一段，也就是“大版本”。但真正下载的时候，接口返回的是完整四段号，你要找的是“这个大版本号里官方发布的最后一个或某一个具体小版本”。

常见的一个误区是：把大版本号当成完整版本来下载。比如你说“我要 120 版本”，实际在接口里 120 这个大版本对应着好几个小版本（120.0.xxxx.xx这种），它们之间还有 bug 修复差异。是否需要指定到小版本，取决于你的场景。如果是复现用户报的 bug，用户会给你完整的“关于”页面显示的版本号，那就必须精确到四位段；如果只是要一个“大版本区间”，选该大版本中最新的小版本就行。

用接口确认小版本列表的方法也很直白：请求对应平台和渠道的 versions 接口，然后在返回数组里筛出你要的大版本段，取发布时间最新的那一条。这一步用任何语言写都行，但命令行里最顺手的是curl加 JSON 解析工具。你不需要装额外的软件，curl是大多数系统自带的，JSON 解析可以用python3一段脚本完成。

这个“先查后下载”的顺序很重要。很多人图省事，直接拿网上搜到的下载链接开下，结果文件名是旧版的、下回来装完版本不对。用接口先确认版本号，再拼下载地址，问题就能从根上避免。

3.2 最小化 bash 脚本：按平台与渠道拉取对应安装包

我平时在 Linux 或 macOS 终端里会直接跑一段 bash 脚本完成“查询最新小版本号 + 拼接官方下载地址 + 下载”的整条链路。下面这个脚本可以照抄，参数只有三个：平台、渠道、大版本号。

#!/usr/bin/env bash # 用法: ./fetch-chrome.sh [win|mac|linux] [stable|beta|dev|canary] [大版本号] set -euo pipefail PLATFORM="${1:-win}" # 平台：win / mac / linux CHANNEL="${2:-stable}" # 渠道：stable / beta / dev / canary MAJOR_VERSION="${3:-116}" # 目标大版本号 # 1. 拿到该平台该渠道的全部版本列表 VERSIONS_JSON=$(curl -s "https://versionhistory.googleapis.com/v1/chrome/platforms/${PLATFORM}/channels/${CHANNEL}/versions") # 2. 用 python3 解析，筛出目标大版本下最新的一条完整版本号 FULL_VERSION=$(echo "$VERSIONS_JSON" | python3 -c " import json, sys data = json.load(sys.stdin) major = int('${MAJOR_VERSION}') picked = None for item in data.get('versions', []): v = item.get('version', '') try: if int(v.split('.')[0]) == major: picked = v break except ValueError: continue print(picked if picked else '') ") if [ -z "$FULL_VERSION" ]; then echo "未找到大版本 ${MAJOR_VERSION} 对应的版本，请确认版本号或平台参数" exit 1 fi echo "命中版本: ${FULL_VERSION}" # 3. 按官方下载节点规则拼接直链 # 注意：不同平台的路径段不同，下面按平台做分支 case "$PLATFORM" in win) URL="https://dl.google.com/chrome/install/${FULL_VERSION}/chrome_installer.exe" ;; mac) URL="https://dl.google.com/chrome/install/${FULL_VERSION}/GoogleChrome.dmg" ;; linux) URL="https://dl.google.com/chrome/install/${FULL_VERSION}/google-chrome-stable_current_amd64.deb" ;; esac echo "下载地址: ${URL}" curl -L -o "chrome-${FULL_VERSION}.${PLATFORM}" "$URL"

脚本逻辑上做了三件事：先请求官方版本历史接口拿全量列表，再过滤出你要的大版本号并取最新一条完整版本号，最后按平台拼出官方下载节点的直链并用curl拉下来。参数设计上，平台和渠道都给了默认值，命令行的习惯是默认参数尽量可用，只把“大版本号”作为必填语义暴露出来。你把它改成 Windows 上跑的话，curl用 Git Bash 或 WSL 里的即可，Windows 自带的certutil也可以下载，但脚本可读性还是curl最好。

需要注意两点。第一，接口返回的列表顺序不是绝对稳定，脚本里取的是“第一个匹配到大版本的条目”，这是按官方“新版本排前面”的惯例写的。如果哪天返回顺序变了，可以把逻辑改成按release_time字段排序再取最新。第二，Linux 的 deb 包路径带stable字样是因为官方对 Linux 的 Stable 渠道安装包就是这样命名的，如果你在跑beta或dev，需要把包名里的stable换成对应渠道名，否则 404。

3.3 进阶：用 Python 脚本一次性拉取多个版本并记录元信息

做兼容性测试的时候，往往不是一个版本够用的。你可能需要连续跑 116、117、118 三个大版本，每个版本都要下载安装并跑一遍回归用例。这时逐个跑 bash 脚本有点低效，我会写一个只依赖标准库的 Python 脚本，把“查询版本号”和“下载文件”合并成一个循环，最后把结果写进一个 CSV 文件留档。

#!/usr/bin/env python3 import csv import json import subprocess import sys import urllib.request def fetch_versions(platform: str, channel: str) -> dict: url = ( "https://versionhistory.googleapis.com/v1/chrome/" f"platforms/{platform}/channels/{channel}/versions" ) with urllib.request.urlopen(url) as resp: return json.load(resp) def find_latest_for_major(versions: dict, major: int) -> str: for item in versions.get("versions", []): v = item.get("version", "") try: if int(v.split(".")[0]) == major: return v except ValueError: continue return "" def build_url(platform: str, full_version: str) -> str: if platform == "win": return f"https://dl.google.com/chrome/install/{full_version}/chrome_installer.exe" if platform == "mac": return f"https://dl.google.com/chrome/install/{full_version}/GoogleChrome.dmg" if platform == "linux": return ( f"https://dl.google.com/chrome/install/{full_version}/" "google-chrome-stable_current_amd64.deb" ) raise ValueError(f"unsupported platform: {platform}") def main() -> None: platform = sys.argv[1] if len(sys.argv) > 1 else "win" channel = sys.argv[2] if len(sys.argv) > 2 else "stable" majors = [int(x) for x in sys.argv[3:]] or [116, 117, 118] versions_data = fetch_versions(platform, channel) records = [] for major in majors: full_version = find_latest_for_major(versions_data, major) if not full_version: print(f"major {major}: not found", file=sys.stderr) continue url = build_url(platform, full_version) output_name = f"chrome-{full_version}.{platform}" print(f"downloading {full_version} -> {output_name}") subprocess.run(["curl", "-L", "-o", output_name, url], check=True) records.append({ "major": major, "full_version": full_version, "url": url, "local_file": output_name, }) with open("chrome-downloads.csv", "w", newline="") as f: writer = csv.DictWriter(f, fieldnames=["major", "full_version", "url", "local_file"]) writer.writeheader() writer.writerows(records) print("done, saved to chrome-downloads.csv") if __name__ == "__main__": main()

逻辑上这个脚本有两个设计点值得说明。第一个是“BS 式容错”：如果某个大版本号在接口里查不到（比如输错了数字或老版本被官方下架），脚本不会中断整批流程，只会把错误打到标准错误输出，继续处理下一个版本。第二个是把下载记录写成 CSV，这在你后续做回归测试时非常有用——哪个版本对应哪个本地文件名、URL 是什么，全都留了底，不用靠脑袋记。

subprocess.run调curl而不是直接用urllib下载，是刻意为之：curl对重定向、断点续传和 TLS 证书链的处理比标准库更稳，在脚本语言里作为一个外部调用是常见做法。如果你在 Windows 上跑这个 Python 脚本，需要确保curl在 PATH 里，否则会报FileNotFoundError。

3.4 下载失败时先看三处：返回码、文件名、文件大小

脚本下载不比人工点击，失败时信息是直接露出来的。最典型的三类异常，排障路径几乎固定。

第一类是 HTTP 404，原因通常是拼接的下载路径不存在。官方下载节点对老版本的保留是有时间窗口的，我在 2023 年还见过 110 大版本的安装包能下载，但更早就已经 404。遇到这种情况不要反复试官方路径，直接转第三方校验后拉取，或者调整目标版本号到官方仍保留的范围内。

第二类是下载下来的文件很小，只有几十 KB。这往往不是真的安装包，而是下载节点返回的一个错误页或提示页。curl默认不会因为这种情况爆错，只有你检查文件大小或文件头才能发现问题。所以脚本里如果加上“下载后检查文件大于 20MB”的判断会更稳，Windows 的离线安装包通常上百 MB。

第三类是证书校验失败。curl会报SSL certificate problem，原因可能是系统 CA 证书过期，也可能是当前网络环境对 HTTPS 连接做了改写。常规解决手段是更新系统证书库，不要直接加-k跳过校验——那是把安全防线拆了，下载一个浏览器却跳过证书校验，怎么想都划不来。

4. 下载Chrome历史版本避坑：从翻车现场整理的 5 条清单

4.1 现象：装完确实是旧版，过几天又自己变回新版

我遇到过某公司测试环境里，A 工程师花了一下午下载安装好 116 版本，第三天再开浏览器发现又变回最新版了。原因几乎可以断定：Chrome 自带的自动更新服务默认是开着的，旧版装好后，更新服务会在后台检测并拉取新版本，安装包本身无法阻止这个过程。

解决方法是装完立刻处理更新通道。Windows 上可以禁用 Google Update 服务（服务名形如gupdate和gupdatem），或者通过组策略配置自动更新策略，让浏览器保持在一个固定版本。个人开发者图省事的话，装完后把安装目录改名或者把更新程序重命名也能临时挡一阵子，但这不是正规做法，系统重启后更新服务可能自我修复。测试机建议直接用一个脚本在安装后统一停止相关服务。

4.2 现象：从第三方站下载的安装包，双击后报证书无效或被系统拦截

有一次我在一个第三方归档站下载 Chrome 118 的 Windows 安装包，下载倒是顺利，安装时系统直接弹“无法验证发布者”。原因就是文件被重新打包过，数字签名已经失效。这类文件即便侥幸装上，里面被塞了什么组件你也无从得知。

解决方法是回到官方节点下载，并养成校验签名的习惯。Windows 上右键安装包看“数字签名”页签，确认签名有效和签名主体信息完整；macOS 上用spctl --assess验证 Gatekeeper 评估结果。第三方站不是完全不能用，而是用了之后必须做这两步检查，缺一步都不建议装机。

4.3 现象：覆盖安装旧版时报错“已安装更高版本”，旧版装不上来

Chrome 的安装器不允许在同一目录下用旧版本覆盖新版本。某同事在复现老 bug 时想直接把 116 盖在 120 上，安装器直接退出了。这是设计如此，不是下载的包有问题。

解决方法是先卸载当前版本，再安装旧版。更稳妥的做法是备份用户数据目录再卸载，因为 Chrome 的配置文件（书签、密码、历史记录）默认跟随用户目录，卸载浏览器不会删配置，但为了保险还是手动复制一份。如果你要并行保留多个版本做回归测试，不要用覆盖安装的思路，应该用独立目录的方式跑旧版，这个技巧最后章会展开。

4.4 现象：明明下了 Windows 的包，安装界面却跑到另一个体系去了

这个坑更多发生在 Windows 平台内部的细分场景。Chrome 的 Windows 安装包有在线安装器和离线完整安装包之分，还有 32 位和 64 位差异。官方下载节点路径里如果没明确区分，很容易在搜索结果里下到在线安装器——它的体积只有 1~2MB，运行后才开始拉取完整文件。你以为下载了历史版本的安装包，结果运行后拉回来的又是当前最新版，等于白忙。

解决方法是下载后先看文件大小。离线完整安装包体积在 100MB 量级，在线安装器则极小。如果你用接口拼 URL，优先确认路径段里带完整版本号的那一类，那通常是直链离线包。另外 Windows 平台上安装器有两种体系（系统级安装与用户级安装），部分企业环境使用系统级安装包，这个体系差异也会影响覆盖逻辑，遇到问题先确认你拿到的安装包属于哪一种。

4.5 现象：macOS 下载完成后提示“镜像已损坏”，但我校验了 SHA 是对的

macOS 对下载文件的隔离属性很敏感。浏览器下载的文件默认带com.apple.quarantine属性，如果系统认为文件来源不明，会拒绝打开或提示“已损坏”。这不一定意味着文件被篡改，有时只是隔离属性和应用签名之间的校验流程被触发。

解决方法是先跑xattr -dr com.apple.quarantine /path/to/file.dmg，清除隔离属性后再打开。如果清除后仍然提示签名无效，说明文件本身真的有问题，回去检查下载来源。这一条能帮你区分“系统误报”和“文件确实被改过”，避免在错误的方向上反复折腾。

提示：以上操作都是在正常下载和安装软件的范畴内，不会触及任何系统安全限制的绕过。

5. 把版本“锁死”并验证：安装与日常使用的落地技巧

5.1 多版本并存：用独立 user-data-dir 让旧版和现有浏览器互不干扰

如果你需要同时保留新版和旧版，不要玩覆盖安装。Chrome 支持通过启动参数指定独立的用户数据目录，两个实例可以并行存在。以 Windows 为例，下载并解压或安装好旧版后，用下面的方式启动它能避免与你日常用的 Chrome 打架。

chrome.exe --user-data-dir="D:\chrome_profiles\v116" --disable-auto-update

这个参数的含义是：所有书签、扩展、登录态都写到D:\chrome_profiles\v116下，与默认配置隔离；--disable-auto-update是禁用更新检查（注意这个参数在新版本中的支持程度有变化，要确认当前版本是否响应它）。配合前面改更新服务的操作，旧版本就能长期留在一个固定状态，不会因为重新启动而被悄悄换掉。

macOS 和 Linux 同理，--user-data-dir参数通用，路径换成对应系统的写权限目录即可。这个技巧是我做兼容测试时最常用的一招，一次配好多个 profile，后续反复用。

5.2 日常维护习惯：把下载记录和校验值存进同一条文档

版本下载这件事有个特点：你很少只下载一次，但隔几个月再要同一版本时，全网资源可能已经变了。我自己的做法是建一个内部表格，列名固定为：日期、版本号、平台、渠道、来源 URL、本地文件名、SHA256、签名校验结果。每次下载完成就顺手记录，下次要用直接查表。

校验 SHA256 的命令在 Windows 上是certutil -hashfile file SHA256，在 macOS 和 Linux 上是shasum -a 256 file。不要只看文件能装就入库，记下校验值，之后任何人拿到这个文件都能从你的记录里验证它有没有被动过。这比“我上次下载的时候是好的”这种经验主义靠谱得多。