企业官网建设流程全解析

简介：面向前端开发、浏览器兼容性测试及软件运维等场景，资源提供Chrome与Chromium历史版本的查询和下载导航，解决新版本更新后旧安装包难找、或在特定版本下复现问题等实际痛点。压缩包共14个文件、约450KB，主体为6个JSON数据文件，用于记录版本号、操作系统与下载位置的映射关系；另含2个SVG图标、HTML/CSS/JS查询页面和README说明文档，结构简洁，打开主页面即可直接浏览使用。已有9420人学习/下载。读者可按版本号快速检索不同操作系统的下载位置，理解Chromium开源与Chrome闭源组件的差异；对于需要回滚版本、在旧版浏览器中验证HTML5特性或排查兼容性问题的开发测试人员，是一个小巧实用的历史版本速查工具。

1. Chrome 自动更新又作妖：为什么你需要学会下载历史版本

Chrome 的自动更新对多数用户是省心，但对特定场景是负担。你正开着浏览器准备演示，某个依赖旧内核的页面突然变成空白；自动化测试脚本昨天还全绿，今天凌晨 Chrome 悄悄升级后，WebDriver 报出版本不匹配；公司里几十台老电脑本来跑得好好的，一次大版本更新后卡得像幻灯机。这时候，你需要的不是等 Google 推下一个修复版本，而是能立刻拿回机器上的上一个版本。学会下载 Chrome 历史版本，就是给自己留一份升级后悔药：知道从哪里拿到干净的原版安装包，精确到四段版本号，安装时不触发新版回写，最后把更新彻底关掉。这篇内容写给被版本问题折腾过的运维和测试工程师，也写给电脑配置不够、还想让浏览器保持流畅的普通用户。我会按实际使用顺序，把能直接抄的命令和参数放在后面。

2. 历史版本从哪里来：官方渠道、社区镜像与版本命名规则

2.1 版本号四段结构：Chrome 109 和 109.0.5414.75 是一回事吗

Chrome 的完整版本号由四段数字组成，常见写法是 A.B.C.D，例如 109.0.5414.75。其中 A 是主版本号，也就是大家挂在嘴边的“Chrome 109”；B 通常为 0，是保留段；C 是构建号，由开发分支的提交编号产生；D 是补丁号，同一个大版本会因为在不同时间发布的修复而拥有不同 D。举例来说，Chrome 109 可能同时存在 109.0.5414.74、109.0.5414.75 等好几个小版本，它们都属于用户所说的“Chrome 109”，但安装包的下载链接必须区分到 D 这一位，因为安装包的文件名、大小和校验值都是以完整四段为准。

为什么开头就要讲这个？因为很多人在搜索“Chrome 浏览器下载历史版本”时，看到的网页大标题只有“Chrome 109”，实际文件可能是 .74 或 .75，下载后 chrome://version 显示的数字和自己预期不一致。如果你只是为了用旧版浏览器，差一两个补丁问题不大；但如果你在配合 chromedriver 做自动化，driver 与 Chrome 的版本必须严格匹配，差一个补丁号都可能启动失败。因此我建议在记录需求时，至少写下大版本号加平台和位数，等到确定下载源后，再在最终链接里同步确认完整的四段版本号。

另一件容易被忽略的事：同样是 109 大版本，Windows 和 macOS 的补丁号并不是同一时间发布。Chrome 的大版本节奏是每四周左右一个 Milestone，但平台修复的推送会错开。因此，某天你在一个下载站看到“Chrome 109 下载”，它的实际版本可能是 Windows 的 109.0.5414.75，也可能 Linux 的 109.0.5414.119。你在 Linux 下拿到 .75，同事在 macOS 拿到 .76，两者功能上没有本质差别，但在脚本和自动化里，请始终记录完整版本号。还有一个容易混淆的点：Chrome for Testing 使用与官方发布一致的版本号，但它的构建文件是单独编译的，不能拿正式版安装包去对应。你需要用 JSON 接口里的字段，而不是自己拼 URL。这一点在第三章的脚本里会体现得更清楚。

2.2 官方优先：Chrome for Testing 和 Chrome 企业版哪个更省心

先说结论：如果要下载“某一个版本”并且要求来源干净，Chrome for Testing（CfT）是首选。CfT 是 Google 为自动化测试提供的官方构建，最大的特点是它不会自动更新，你可以长期固定在某一个版本上。它还提供了一个 JSON 接口，把所有已知版本和下载地址直接暴露出来，机器可读，不需要在网页上层层点击。Chrome 企业版是面向企业 IT 统一管理的系统级安装版本，可以使用组策略关闭自动更新、设置更新周期。但企业版页面并不会把所有历史版本都罗列出来，通常只保留当前大版本和上一个主要版本。所以它适合“全公司统一用一个版本并锁住”的管理需求，不适合“我想要去年七月的某个精确版本”的时间线找回需求。Canary 是金丝雀版，版本号比正式版高一两个世代，是内部的每日构建，离线安装包可以在官网找到，但它是独立安装、不会覆盖正式版。不要把 Canary 当成“历史版本”来用，因为它的版本号一路向前，不会回退。

我自己的选择习惯是：要我固定版本时，去 CfT 找；要批量给同事机器统一时，用企业版加管理策略；要验证新功能可能产生的兼容性影响时，才考虑 Canary。三种渠道分工明确，不互相替代。为了看起来更直观，我常给团队看下面这张对比表：

为什么默认优先 CfT？因为企业版虽然自带更新策略，但它的历史版本下载入口不提供按 Milestone 选择的能力，通常只看到当前版本和上一个版本。对于想回退到更早版本的用户，CfT 的 JSON 列表是唯一能直接拿到“明确版本号+官方直链”的地方。即使你的目的不是自动化测试，也可以把 CfT 的安装包当作干净的历史版本来使用。CfT 没有自动更新，意味着它不会在后台偷偷升级，这正是固定版本时最需要的特性。

2.3 第三方下载站和 APK 镜像：什么时候值得用，什么时候必须躲

官方渠道不会永远保留所有历史版本。当你要的版本已经被 CfT 清理掉，或者你要的是安卓 APK 而官方没有对应的历史 APK 下载页时，第三方是唯一的路。常见的有 OldVersion、FilePuma、APKMirror，以及一些以“chrome 各版本安卓版”为关键词的第三方更新库。这些站点的价值是补齐长尾版本，但也混杂了风险。我给自己定了一条规则：第三方站点下载之前必须能看到明确的校验值，比如 SHA256 或与官方一致的文件大小。APKMirror 会给出每个 APK 的签名指纹和校验值，这类站点可以信任；如果一个站点用“压缩包”“万能安装包”作噱头，连文件大小都不标，那就要绕开。因为历史版本本身就容易被注入问题，一旦装上带后门的旧版 Chrome，损失比升级带来的麻烦更大。

有些第三方站还会用“高速下载”引导你装他们的下载器，这是典型的捆绑渠道。我的做法是找到直链后用 Chrome 自带的下载功能或 wget 拉取，不安装任何下载器。下载后的安装包尽量在虚拟机或临时目录里先跑一遍，确认没有弹出额外安装项再分发到工作机器。如果站点提供了 SHA256，怎么用？Windows 下在 PowerShell 里执行：

Get-FileHash .\chrome-109.0.5414.75-win64.zip -Algorithm SHA256

把这个输出值和下载页面的值比对，一致再安装。Linux 下用sha256sum。这一步能挡住大多数篡改包。如果页面没有校验值，那就用 VirusTotal 上传扫描，或者干脆放弃，换一个能找到校验值的镜像。第三方镜像只是在官方后退时的一张底牌，不是首选。

3. 用 Chrome for Testing 的 JSON 接口做精准下载：脚本与参数

3.1 两个 JSON 文件先看清楚：known-good-versions 和 latest-versions-per-milestone

CfT 的下载地址托管在 GitHub Pages 的chrome-for-testing目录下，其中有几个 JSON 文件。我最常用的是latest-versions-per-milestone-with-downloads.json，它按大版本分组，每个大版本只保留最新的补丁号，适合下载“某一个大版本的最后版本”。另一个是known-good-versions.json，它列出所有还活着的完整版本，适合在自动化脚本里做“精确版本号存在性判断”。先把数据拉下来看一眼：

curl -L https://googlechromelabs.github.io/chrome-for-testing/latest-versions-per-milestone-with-downloads.json -o chrome-versions.json

用任意文本编辑器打开，或直接用jq查看结构：

jq '.versions[] | {milestone, version, downloads}' chrome-versions.json

返回结构里，downloads下有一个chrome数组，数组里每一项包含os、architecture、url三个字段。比如os可能是win64、linux64、mac-arm64；architecture是x64或arm64。注意这里的os已经包含了位数信息，比如win64，所以architecture通常是x64。如果os是mac-arm64，architecture则是arm64。写脚本时不要自己把os和architecture拼错。这两个 JSON 文件是官方提供的，不依赖任何第三方页面，因此是批量下载和自动化集成时的可靠数据源。

3.2 Python 脚本：按大版本号下载对应的 Chrome ZIP

我一般不会直接在网页上找下载按钮，而是用一段 Python 脚本把下载流程固化。下面这个脚本读取 JSON，传入三个参数：大版本号、平台、架构，自动匹配并下载。

import json import sys import urllib.request DATA_URL = ( "https://googlechromelabs.github.io/chrome-for-testing/" "latest-versions-per-milestone-with-downloads.json" ) def find_chrome_download(milestone, os_name, arch): with urllib.request.urlopen(DATA_URL, timeout=30) as resp: data = json.loads(resp.read().decode("utf-8")) for item in data["versions"]: if item.get("milestone") != milestone: continue for entry in item.get("downloads", {}).get("chrome", []): if entry.get("os") == os_name and entry.get("architecture") == arch: return item["version"], entry["url"] return None, None if __name__ == "__main__": milestone = sys.argv[1] # 例如 109 os_name = sys.argv[2] # 例如 win64 / linux64 / mac-arm64 arch = sys.argv[3] # 例如 x64 / arm64 version, url = find_chrome_download(milestone, os_name, arch) if not url: print(f"没有找到 {milestone} 在 {os_name}/{arch} 的下载记录") sys.exit(1) filename = f"chrome-{version}-{os_name}-{arch}.zip" print(f"匹配版本: {version}") print(f"开始下载: {filename}") urllib.request.urlretrieve(url, filename) print("下载完成")

用法：

python download_chrome.py 109 win64 x64

逻辑说明：脚本先请求 JSON 并解析成字典；然后遍历版本列表，找到milestone为109的项；最后在downloads.chrome数组里匹配os和architecture。一旦找到，就用完整版本号作为文件名，调用urlretrieve下载到当前目录。参数说明：第一个参数必须是字符串，比如109；第二个参数win64对应 Windows 64 位，linux64对应 Linux 64 位；第三个参数x64是大多数桌面 CPU 的架构。如果是 Apple Silicon 的 Mac，参数应该是mac-arm64和arm64。如果你的网络对大文件下载不友好，建议把它换成 wget/curl 方式，见下一节。

3.3 用 wget/curl 下载大文件：超时重试和断点续传怎么配

Python 的urlretrieve不擅长断点续传，下载到一半断网就要从头再来。所以我实际工作中更常用curl直接下载。确定 URL 后，用下面的命令：

url=$(curl -s https://googlechromelabs.github.io/chrome-for-testing/latest-versions-per-milestone-with-downloads.json | \ jq -r '.versions[] | select(.milestone=="109") | .downloads.chrome[] | select(.os=="win64" and .architecture=="x64") | .url') curl -L -C - --retry 5 --retry-delay 3 -o chrome-109-win64-x64.zip "$url"

第一行用 jq 从 JSON 中提取 URL，第二行开始下载。-L表示跟随重定向，因为 CfT 的实际文件放在 Google 的 CDN 域名，需要重定向；-C -是断点续传，下载中断后再次执行会从上次的位置继续；--retry 5是失败后重试 5 次；--retry-delay 3是每次重试间隔 3 秒。这几个参数几乎是下载历史版本的固定套餐。如果环境里没有 jq，可以退回 Python 脚本只打印 URL，然后在 shell 里读取。我日常会把脚本里print("下载完成")改成print(url)，然后直接用 curl 下载，这样既保留 JSON 解析的灵活性，又不丢断点续传能力。

下载目录最好选在 D 盘或 /data 下，避免系统盘空间不足。历史版本 zip 解压后通常占用 1GB 以上，留足空间。下载完成后不要着急解压，先比对文件大小和官方发布的一致性；CfT 的 JSON 没有直接给 SHA256，你可以去 Google 的下载页面确认文件名中的版本号，至少保证 URL 开头是chrome-for-testing域名。

4. 安装与降级：三个平台的正确姿势和用户数据迁移

4.1 Windows：优先用 ZIP 绿色版，别急着卸载正式 Chrome

我下载到 Windows 上的 CfT 包通常是 zip，解压后直接是一个chrome-win64文件夹，里面是chrome.exe。这种绿色版的最大好处是不用卸掉正式版，两者可以并存。跑自动化时，用chrome.exe --user-data-dir=D:\temp-profile指定一个临时配置文件目录，就不会污染日常使用的正式配置。但如果你需要把整个系统里的 Chrome 换回旧版本，不要直接双击旧版安装包，而是先把正式版停掉。常见步骤是：先配置好关闭 Chrome 自动更新的策略，再卸载现有 Chrome，重启系统，最后运行旧版安装程序。这里提醒一点：卸载时如果选择“同时删除浏览数据”，你原来的书签、历史记录、密码就都没了。一定要先备份用户数据目录。默认位置是：

%LOCALAPPDATA%\Google\Chrome\User Data

把整个目录复制一份到移动硬盘，后续即便降级翻车也能找回书签和历史。如果你想用旧版 Chrome 打开这个备份的配置，建议复制到新的本机路径，再用下面的命令启动，而不是覆盖当前正在用的目录：

"C:\Users\你的用户名\Downloads\chrome-win64\chrome.exe" --user-data-dir="D:\chrome-profile-109"

参数说明：--user-data-dir是 Chrome 的命令行启动参数，指定用户数据目录。这样旧版浏览器会在这个目录下新建一套配置，不会动正式版的个人数据。第一次启动可能有点慢，因为要重新生成缓存，但至少安全。另外，解压路径不要带中文和空格，Chrome 对路径符号敏感，直接用D:\chrome-win64最省事。

4.2 macOS：从 dmg 拖到应用程序，处理签名和权限问题

macOS 上 CfT 提供 zip 或 dmg。dmg 拖进 Applications 的步骤没什么好说的，关键是启动时可能遇到“无法打开，因为 Apple 无法检查其是否包含恶意软件”或“已损坏”。这不是真损坏，多数是因为旧版签名用的证书被系统不再信任，解决办法是清除隔离属性：

sudo xattr -rd com.apple.quarantine "/Applications/Google Chrome for Testing.app"

如果仍然打不开，可以右键选择“打开”再确认一次。macOS 的 Chrome 自动更新由~/Library/Google/GoogleSoftwareUpdate下的程序负责，旧版 Chrome 首次启动时还可能弹窗提示更新。我的习惯是直接把 Google 软件更新目录权限改掉，或者用系统推荐的自创 plist 锁策略，这部分放到最后一章专门说。用户数据备份路径在~/Library/Application Support/Google/Chrome/。降级前把整个目录复制为Chrome-109-profile，然后用--user-data-dir="/Users/xxx/Chrome-109-profile"启动旧版。Mac 版的--user-data-dir与 Windows 行为一致，只是路径写法不同。

如果你用的是 Apple Silicon 的 Mac，下载时优先选mac-arm64。但一些较早的历史版本可能没有 ARM64 构建，只有 x64 版，这时需要依靠 Rosetta 2 转译，首次启动会比较慢，而且不能通过--version看到arm64字样。这不算安装失败，但要注意别把慢启动误判成卡死。

4.3 Linux：deb/rpm 先卸载再装，然后立刻锁版本

Linux 上想用旧版，最省事的是从 CfT 的 JSON 里下载 deb 或 rpm。CfT 在downloads.chrome里对os: linux64的条目通常会给两个 URL，一个是 zip，一个是 deb 或 rpm，文件名里会带google-chrome-stable-current之类的标识。下载后用dpkg -i安装：

sudo dpkg -i ./google-chrome-stable_current_amd64.deb

如果系统里已经有新版的 Chrome，dpkg 会报错，提示需要先卸载：

sudo dpkg -r google-chrome-stable sudo dpkg -i ./google-chrome-stable_current_amd64.deb

安装完成后立刻锁住版本，不让 apt 在后续升级时把它换掉：

sudo apt-mark hold google-chrome-stable

参数说明：apt-mark hold会阻止该包被自动升级、手动升级和依赖升级。如果想解除锁定，用sudo apt-mark unhold google-chrome-stable。Linux 上还要留意系统仓库里可能有一个google-chrome-stable的源，即使apt-mark hold，某些apt upgrade操作仍然会提示“升级被阻止”，这说明锁生效了。不要顺手把提示里的警告当成错误。如果是 rpm 系的系统，用rpm -ivh ./google-chrome-stable_current_x86_64.rpm，安装前也建议先卸载旧包，避免 rpm 的版本回退校验失败。锁版本方面，rpm 系可以用yum versionlock google-chrome-stable，但实际效果因系统版本而不同，Debian 系的apt-mark hold更直接。

4.4 安卓 Chrome 和麒麟版：历史 APK 的架构选择与卸载逻辑

安卓版 Chrome 的历史版本通常要到 APKMirror 这类镜像站找，因为官方 Play 商店不会提供回退。下载时注意看两个字段：CPU 架构和 Android 版本要求。包名里有arm64-v8a、armeabi-v7a之类标识，如果你手机是 ARM64，就选arm64-v8a；如果选错，安装时会提示“解析包时出现问题”或直接安装失败。Android 9 以下的设备千万别装为 Android 12+ 编译的最新 APK，老系统上会闪退。安装前要确认手机上是否已经安装了 Chrome。一般历史 APK 签名和正式版相同，但版本号更低时，安装程序会拒绝覆盖安装，显示“应用未安装”。解决方法只有两个：卸载现有的 Chrome 再安装旧 APK，或者用双开/多开容器创建一个独立空间来装旧版。我一般用后者，保留日常使用的 Chrome，另开一个测试环境来跑旧版本，这样不用清空手机数据。

如果你用的是国产服务器上的麒麟版 Chrome，也就是某些 Linux 系统预装的 Chrome for 麒麟，那它是官方针对国产 CPU 和 OS 做的适配分支，版本号往往落后于国际版，不能直接拿国际版安装包覆盖。遇到升级需求时，找发行方提供的渠道，不要硬装，否则依赖库会不兼容，连图形界面都起不来。最简单的判断方法是运行chrome --version，输出里如果带 Kylin 或麒麟字样，就说明这是适配版，别动它。

5. 避坑手册：版本号、安装包、网络策略的五个常见翻车现场

5.1 现象：明明下载的是 109，安装后 chrome://version 里还是 144

这是个高发问题。原因是正式版 Chrome 的自动更新机制很顽强，在你执行安装时，系统内的 GoogleUpdate 服务已经把最新版下载好并写入 Program Files 目录，你的旧版安装包根本无法覆盖它。另外，很多安装程序为了防降级，会直接拒绝安装比现有版本更旧的 Chrome，导致安装过程看起来成功，实际打开的还是新版本。解决方法：安装旧版之前先关掉 Google 更新服务。Windows 上以管理员身份执行：

sc config "GoogleUpdate" start= disabled sc stop "GoogleUpdate"

如果是企业环境，再配合组策略里的“关闭自动更新”一起使用。然后卸载现有 Chrome，重启后再安装旧版。装完立刻打开chrome://version页面看第一行版本号，不要只看桌面快捷方式图标的版本信息。还有一种情况是电脑里有多套 Chrome 目录，正式版被装在Program Files，你的旧版绿色版却放在Downloads，双击桌面快捷方式仍然指向正式版。这时要看快捷方式的“目标”路径是否指向你刚解压的chrome.exe，路径不对的话，一切努力都白费。

5.2 现象：下载链接 404，或者解压到一半提示文件损坏

这种问题多出现在版本太老或下载过程被中断。CfT 的 JSON 列表是滚动保留的，比如你现在查 known-good-versions，里面可能只保留最近 20 个大版本，更早的已经被移除。第三方站则可能出现“文件不存在或已移动”，因为它们的直链会定期清理。解决方法：先用known-good-versions.json查一下目标大版本是否还存在，如果目标大版本已经全部下架，就退而求其次选择同一个大版本的最后一个小版本。下载时一定要用带断点续传的命令，比如上一章的curl -L -C -。解压之后先对一下文件大小，跟页面上给出的 bytes 数一致再继续。如果文件大小对不上，删掉重新下载，不要用“修复压缩包”之类的工具硬解压。更隐蔽的情况是 ZIP 在下载过程中被 Windows Defender 扫描锁定，解压时提示“文件正在被占用”。这时关掉安全软件的实时监控，或者把文件移到排除目录后再解压。

5.3 现象：旧版 Chrome 启动后弹窗“配置文件版本由较新版创建”

这是降级时最经典的数据兼容问题。新版 Chrome 会修改用户数据目录里的 Preferences、History、Cookies 等文件的字段格式，旧版读取不了时不会直接崩溃，而是弹窗提示并使用新的空配置。很多人在这一步以为旧版坏了，其实只是配置目录不兼容。解决方法：备份后指定一个全新的工作目录，不要直接打开旧的 User Data 目录。命令里带--user-data-dir就能让旧版从头开始建立一个新配置。如果非要保留原来的书签和密码，先把原配置里Default/Bookmarks、Default/Login Data等文件复制到新配置目录，但不要在旧配置目录上直接启动旧版 Chrome。这样做的好处是，即使文件复制不完整，日常使用的正式 Chrome 还能正常工作。另外，降级前最好看一眼旧版浏览器支持的最低 profile 版本，如果新旧之间跨了十几个大版本，直接复制 Login Data 和 Cookies 往往无效，因为加密方式也变了。密码库在新旧版本间可能无法迁移，最保险的做法是导出为 CSV 或使用浏览器的密码管理器。

5.4 现象：明明关闭了自动更新，第二天又更新回去了

关闭 Chrome 自动更新是个系统工程，只改一个地方往往被“复活”。比如你只禁用了 GoogleUpdate 服务，但 Chrome 自带的任务计划或登录项又把它启动；或者你只用了旧版安装包，但企业组策略里的更新策略优先级更高，直接把版本推到最新。解决方法：从三个层面同时处理。第一，在管理模板中启用“Chrome 更新”策略并设置为“禁止更新”；第二，用sc config禁用服务；第三，删除或重命名 GoogleUpdate 相关的计划任务。Linux 上用apt-mark hold锁住包；macOS 上移除GoogleSoftwareUpdate目录或修改启动项。处理后重启，连续观察两三天，再确认版本号没有变化，这才算真正关闭。不要期待一条命令解决所有系统状态。尤其是 Windows 上有多个用户账户时，每个账户的登录启动项里都可能有一个 GoogleUpdate 触发器，只关当前账户不够，要用任务计划程序查看全局任务，把 GoogleUpdateTaskMachine 和 GoogleUpdateTaskUser 相关的任务全部禁用或删除。

5.5 现象：下载安装包被杀毒软件拦截，装完主页被改

历史版本的安装包是安全重灾区。第三方站给出的安装包经常被加壳，杀毒软件会报木马；有的甚至用真实的旧 Chrome 做个安装器，里面塞一个 DLL 劫持你的浏览器主页。如果你遇到“安装包杀毒拦截”和“装完浏览器主页变成导航站”这两件事，大概率是包被改动过。解决方法：只信任有校验值的原始包。CfT 的 zip 从官方域名下载，不会报毒；第三方站至少要求提供 SHA256 并与社区公布的比对。安装时选择自定义安装，取消所有附加的“默认搜索引擎”“主页”选项。装好后立刻到chrome://version页面看“命令行”一栏，有没有被添加--disable-web-security或者--load-extension之类的可疑参数，有的话直接清理重装。这条经验来自一次帮同事处理“Chrome 打不开，主页全是广告”的血泪教训，后来查下来是下载站捆绑了一个浏览器扩展。扩展的入口一般在chrome://extensions/，里面多出的陌生扩展就是线索。如果你在历史版本里需要迁移旧插件，注意插件格式也要匹配，新版插件迁到旧版会提示“该扩展程序未列在 Chrome 应用商店中”，需要在扩展管理页开启开发者模式，再加载已解压的扩展目录。

6. 锁死版本的最后一招：关闭自动更新并用命令行验证

如果你已经按照前面的步骤安装好了历史版本，最后一步是让它不再被升级悄悄带走。Windows 下最常见的做法是两条注册表策略加一个服务禁用，以管理员身份运行：

reg add "HKLM\SOFTWARE\Policies\Google\Update" /v AutoUpdateCheckPeriodMinutes /t REG_DWORD /d 0 /f reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v AutoUpdateEnabled /t REG_DWORD /d 0 /f sc config "GoogleUpdate" start= disabled

第一条让更新服务不再按周期检查，第二条是 Chrome 程序层面的关闭更新策略，第三条把服务禁用。Linux 上锁定更简单，sudo apt-mark hold google-chrome-stable就够了；macOS 上可以把~/Library/Google/GoogleSoftwareUpdate目录移走。

验证版本是否真的锁住，两种方法配合用。一是打开chrome://version看第一行的完整版本号；二是在安装目录执行命令行，Windows 是chrome.exe --version，Linux 是google-chrome --version，输出会显示Google Chrome 109.0.5414.75这样的四段号。

我现在的习惯是，每次固定版本时都顺手把下载 URL、文件校验值和版本号记到项目仓库里。以前图省事一直用最新版，一次升级后自动化用例全挂了，排查半天才找到浏览器版本被后台换掉。后来用这套下载历史版本、锁更新、命令行验证的流程，十分钟就能恢复现场。希望帮到你。

本文还有配套的精品资源，点击获取