历史方法分析。 本文说明删除 Chrome 更新服务、计划任务和目录的局限，并介绍受管 Windows 设备的官方更新策略。不同安装形态的更新组件不同，不能套用固定删除清单。
一、删除更新组件的局限
旧脚本按固定路径判断 Chrome，然后结束进程，删除 gupdate/gupdatem、计划任务和 Google Update 目录，最后直接打印成功。这些步骤存在几个具体问题：
- Chrome 有系统级与用户级安装，路径和更新程序随版本变化，单个固定目录不能代表全部安装。
- 更新服务与计划任务的名称会变化，删除旧名称不证明现在已停止更新。
GoogleChromeElevationService不是可随意当作自动更新服务删除的同义项；强制关闭浏览器还可能丢失未保存工作。- Google 更新器可能服务多个产品，删除共享目录会影响其他软件；更新、修复安装或组织策略也可能恢复组件。
- 脚本中的“成功”文字没有验证每一步退出状态、当前版本和真实更新行为。
这张截图只记录了当时的命令输出，不能证明更新被长期禁用。服务和目录还可能被安装器恢复，删除它们也可能影响其他 Google 产品。
二、受管设备使用官方策略
对于加入 Windows/Entra 域或受 MDM 管理的设备，管理员可按Google 官方更新管理文档安装 Google Update 的 ADMX/ADML 模板。该文档明确说明电脑级组策略的管理前提；普通未受管的个人电脑不能仅凭写入注册表或打开 gpedit 就保证政策生效。
需要控制 Chrome 的更新时，进入计算机配置中的 Google Update → Applications → Google Chrome，设置 Update policy override，按目的选择允许、仅手动或禁用更新。只管理 Chrome 时不要修改所有 Google 应用的默认覆盖策略。菜单翻译和组织管理方式可能不同，以所用模板和当前控制台为准。
如果只是安排维护窗口，优先使用更新时间限制或版本目标等支持的策略，确认相应限制和恢复计划。固定旧版本会阻止后续安全修复，应由管理员建立测试、补丁分发和重新启用更新的流程，不无限期停留在一个版本。
浏览器更新、组件更新与更新器自身更新是不同机制：停止浏览器版本更新不保证所有组件和更新器停止变化。不要通过继续删文件来“补齐”这种差异。
三、验证实际应用状态
策略部署后，在受管设备上打开 chrome://policy，重新加载并检查 Google Update Policies 的值与状态，再打开“关于 Chrome”确认实际更新行为和版本。chrome://version 可核对当前执行文件路径与版本；只有注册表里出现一个键，不代表更新器接受了策略。
以下 PowerShell 查询仅用于查看相关服务，不修改服务状态：
Get-CimInstance Win32_Service |
Where-Object {
$_.Name -match 'Google|gupdate' -or
$_.DisplayName -match 'Google'
} |
Select-Object Name, DisplayName, State, StartMode, PathName
这个查询可能同时包含其他 Google 产品，不能按匹配结果批量删除。根据准确路径和厂商日志判断；系统级与用户级更新器日志位置以官方文档为准。
四、恢复更新
受管设备将 Chrome 的覆盖策略恢复为允许更新或按组织基线取消覆盖，刷新策略、重启浏览器并在“关于 Chrome”验收。组织策略可能再次下发，应从管理源修改。
如果过去已经删除更新器目录或服务，先保留浏览器资料和组织设置，再使用官方安装器/管理员分发机制修复安装；不要凭旧服务名称手工创建一个路径未知的服务。恢复后核对更新日志、版本与策略状态，确认浏览器重新获得更新。
评论区