怎么在 Windows 与 macOS 上彻底停用 Chrome 后台更新？
彻底停用Chrome后台更新：Windows/macOS组策略、注册表、守护进程全关闭，附回退与审计方案。
功能定位：为什么企业必须锁死 Chrome 更新
Chrome 的“Silent Update”在 2026 版仍默认每 5 小时检查一次 Google Update 服务；一次全量推送即可覆盖 96% 桌面用户。对于需要冻结功能基线、做兼容性认证或留存取证镜像的政企场景，彻底停用 Chrome 后台更新是合规审计的第一道闸门。本文给出 Windows 与 macOS 两条官方可复现路径，全部基于 Google 公开文档，无第三方补丁。
前置概念：Google Update 与 Chrome 的耦合方式
Google Update（进程名 GoogleUpdate.exe / ksadmin）是独立守护进程，向注册表或 plist 写入 ap 字段控制更新通道。Chrome 本身不含更新代码，只会在启动时调用 Update API。因此“停用更新”= 让 Google Update 无法获取/应用差分包，而非简单删除 .exe。
必须区分的两条策略维度
- 更新频率：用
AutoUpdateCheckPeriodMinutes调整检查周期，设为 0 即完全禁用。 - 更新权限：用
UpdateDefault或InstallDefault控制是否允许安装已下载的更新包。
这两条策略正交：前者决定“是否找更新”，后者决定“找到后能否装”。只封其中一条，都可能留下唤醒日志或后台进程，审计时会被视为“未完全禁用”。
Windows 平台：组策略优先，注册表兜底
步骤 1 获取 ADMX 模板
1. 访问 https://support.google.com/chrome/a/answer/187202 下载「Google Update ADMX 最新版」。
2. 将 google.admx 与对应 .adml 放入 C:\Windows\PolicyDefinitions；如为域控，则复制到中央存储。
步骤 2 配置两条核心策略
├─ 更新策略覆盖 → 已启用 → 更新策略：更新已禁用
└─ 自动更新检查期限 → 已启用 → 检查间隔（分钟）：0
经验性观察：若仅禁用“更新”而未把间隔设为 0，GoogleUpdate.exe 仍会在后台唤醒，占用约 2-4 MB 内存，并在日志中留下 UpdateCheck 事件。
步骤 3 验证注册表落位
策略刷新后，打开 regedit，确认以下键值存在：
"UpdateDefault"=dword:00000000
"AutoUpdateCheckPeriodMinutes"=dword:00000000
若使用 32 位 Chrome 装在 64 位系统，路径相同；策略优先于 HKCU，避免用户自行改回。
macOS 平台：配置文件 + 守护进程双锁
步骤 1 创建 Chrome 更新配置 Profile
1. 用任一 MDM 或 profiles 命令下发以下 plist（示例文件名 com.google.Keystone.agent.plist）：
<integer>0</integer>
<key>autoupdatecheckperiodminutes</key>
<integer>0</integer>
2. 存放路径：/Library/Managed Preferences/com.google.Keystone.agent.plist；确保 root:wheel 644 权限，防止用户覆盖。
步骤 2 关闭 Keystone 守护进程
Keystone 是 Google Update 的 macOS 实现，常驻 /Library/Google/GoogleSoftwareUpdate。执行：
sudo rm -rf /Library/Google/GoogleSoftwareUpdate/*
警告：直接删除 Keystone 会导致「关于 Google Chrome」面板提示“无法检查更新”，这是预期行为，可视为审计证据。
回退方案：如何重新启用更新
1. 恢复策略：Windows 把组策略改回“未配置”；macOS 移除 profile 并 launchctl load -w 原守护进程。
2. 手动补齐差分：到 https://dl.google.com/chrome/install/latest/chrome_installer.exe 下载离线包，安装后版本号即回最新通道。
常见分支：离线安装包、绿色版、便携版是否还需再关？
- 离线安装包（
chrome_installer.exe）仍会在首次启动时拉取 Keystone，必须再走一次策略。 - 绿色版（解压缩
.7z）不含更新组件，但若系统里已有 Keystone，仍会被唤醒；建议同步锁策略。 - Chromium 社区构建不含 Google Update，但同步功能、Widevine 需手动补，适合纯内网开发机。
示例：某央企使用绿色版 Chrome 打开内网 OA，仍被审计发现 ksadmin 进程，原因是半年前装过 Google Earth 遗留 Keystone；统一卸载后日志归零。
不适用场景清单
| 场景 | 风险 | 建议 |
|---|---|---|
| 面向互联网 SaaS 的客服坐席 | 错过安全补丁，易遭钓鱼 | 改用 Extended Stable 通道 + 月度灰度 |
| 个人家庭版设备 | 失去零日漏洞修复 | 仅暂停 7 天，勿永久禁用 |
| VDI 黄金镜像 | 镜像重新封装时版本漂移 | 在快照前关闭更新，快照后走离线包统一升级 |
验证与观测方法
Windows 日志检查
打开「事件查看器」→「应用程序和服务日志」→「Google Update」；若策略生效，应仅看到 Service shutdown，无 UpdateCheck 成功记录。
macOS 日志检查
终端执行 log show --predicate 'subsystem == "com.google.Keystone"' --info --last 1d；若已禁用，则无 ksadmin: update available 字样。
最佳实践清单（可直接打印给运维）
- 域控优先下发 GPO，确保
UpdateDefault=0与AutoUpdateCheckPeriodMinutes=0同时存在。 - macOS 一律用 MDM 推送 profile，避免用户手动
defaults write被系统升级覆盖。 - 冻结前用
chrome://version截图留档，审计时比对数字签名时间戳。 - 每季度允许一次“离线差分升级窗口”，用离线包统一推送，升级后 24h 内完成回归测试并重新冻结。
- 禁止用户安装第三方 Chromium 分支，防止自带独立更新器绕过策略。
故障排查：更新仍偷偷发生？
可能原因：① 用户拥有本地管理员，手动运行了独立安装包；② 策略被后续域策略覆盖；③ 存在 Chrome Beta 并存，被另一通道拉走。
处置：检查
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Google\Update\Clients\{430FD4D0-B729-4F61-AA34-91526481799D} 下 pv 字段，若与策略不一致，立即用 chrome_installer.exe --system-level --force-install 降级回基线并重新锁策略。
FAQ（使用 FAQPage Schema）
禁用更新后，扩展商店还能用吗？
可以。扩展商店走 HTTPS 接口，与更新通道解耦；但 Manifest V3 强制策略仍随浏览器版本固化，若需保留 MV2 扩展，必须同时冻结 Chrome 版本在 131 之前。
关闭 Keystone 会导致 Google 地球/Drive 同步失效吗？
不会。Keystone 只负责 Google 系桌面应用的更新逻辑，不影响运行时 API；但 Drive for Desktop 未来若改用统一更新客户端，需重新评估。
如何证明审计期间未发生偷偷升级？
对比 chrome://version 中的「变体」与「命令行」字段，检查可执行文件数字签名时间戳；同时导出 Google Update 事件日志，确认无 UpdateSuccess 事件即可。
收尾结论与下一步行动
彻底停用 Chrome 后台更新并非“一键删除”那么简单，而是需要策略层 + 守护进程 + 审计证据三件套。Windows 侧以组策略为中心，macOS 侧以 MDM profile + Keystone 卸载为双保险，才能确保合规审计可追溯。
建议运维团队：
- 立即在测试 OU 验证本文步骤，确认无功能回退；
- 把「版本号截图 + 事件日志」纳入月度巡检清单；
- 每季度打开一次“离线升级窗口”，用离线包统一推进，再重新冻结，兼顾安全与合规。
如此即可在彻底停用 Chrome 后台更新的同时，保留对版本基线的绝对控制，为后续兼容性测试、取证留档和监管审计提供可复现的证据链。
📺 相关视频教程
How to change your default browser on a Mac computer - MacOS如何修改默认浏览器
