1. 为什么"禁止更新"这件事值得认真对待
Windows 的自动更新机制，从 Windows 10 开始就变得非常"强势"。它会在后台静默下载、在你不注意的时候重启、甚至在你正开着会议共享屏幕时弹出全屏提示。很多人第一反应是去"服务"里把 Windows Update 停掉，结果重启之后发现它又自己活过来了。这不是你操作错了，而是微软在这套机制里埋了好几层"复活"逻辑。
我自己在几台长期跑数据采集和工控软件的机器上，跟这个更新机制周旋了好几年。最夸张的一次是一台跑自动化测试的机器，凌晨三点自动重启，第二天早上整个测试队列全废。从那之后我就下定决心，要把"禁止更新"这件事彻底搞明白，而不是每次靠运气。
这篇内容适合三类人看：第一类是手里有必须长期稳定运行的 Windows 机器（比如跑数据库、跑采集、跑工控上位机）的人；第二类是被更新反复打断工作、想彻底关掉的人；第三类是想理解 Windows 更新底层机制、不想只会"点按钮"的人。我会从注册表、服务、计划任务、组策略几个层面，把"禁止更新"和"延长更新时间"这两件事讲透，并且给出可以直接抄的配置。
需要先说明一个前提：完全、永久地禁止更新是有代价的。你会错过安全补丁，系统长期暴露在已知漏洞下。所以我的建议一直是——在能联网的生产机器上，用"延长"而不是"永久禁止"；只有在隔离环境、专用设备上，才考虑彻底关闭。这个取舍后面会详细讲。
2. Windows 更新到底是怎么被"唤醒"的
很多人以为更新只靠一个wuauserv服务，把它停了就万事大吉。实际上 Windows 更新是一套多组件协同的系统，你停掉一个，另一个会把它拉起来。理解这套机制，是后面所有操作的基础。
2.1 更新相关的核心组件清单
先看一张表，把跟更新相关的关键组件列清楚，后面操作会反复用到：
| 组件名称 | 类型 | 作用 | 停掉后是否会被复活 |
|---|---|---|---|
| wuauserv | 服务 | Windows Update 主服务 | 会被触发启动 |
| UsoSvc | 服务 | Update Orchestrator，负责调度 | 会被触发启动 |
| WaaSMedicSvc | 服务 | 更新"医生"，负责修复更新组件 | 受保护，需特殊处理 |
| BITS | 服务 | 后台智能传输，负责下载 | 会被触发启动 |
| DoSvc | 服务 | 传递优化，P2P 分发更新 | 会被触发启动 |
| Scheduled Start | 计划任务 | 定时触发更新扫描 | 需单独禁用 |
| UpdateOrchestrator | 计划任务组 | 编排更新流程 | 需逐个禁用 |
这张表是我踩了无数次坑之后整理出来的。你会发现，光停wuauserv根本不够，因为UsoSvc和WaaSMedicSvc会在后台把它重新拉起来。尤其是WaaSMedicSvc，它的设计目的就是"修复被用户破坏的更新功能"，所以它天然就是你的对手。
2.2 为什么停服务之后更新还会回来
这里要讲清楚一个关键机制：Windows 的更新触发是多路径的。服务只是执行者，真正的"发令者"是计划任务和 Orchestrator。你停掉服务，计划任务到点还是会尝试启动它；而WaaSMedicSvc会定期检查更新组件是否"健康"，一旦发现异常就自动修复——包括把你禁用的服务重新启用。
所以正确的思路不是"停一个服务"，而是从触发源头到执行末端，整条链路一起处理。这也是为什么网上很多"停服务教程"对你没用，因为它们只处理了链路中间的一环。
提示：在动手之前，建议先创建一个系统还原点。注册表操作一旦出错，可能导致系统无法正常启动，有还原点能省很多事。
2.3 延长更新时间的官方思路
除了"禁止"，Windows 其实提供了"暂停更新"的官方入口，在设置里可以暂停最多 35 天（不同版本略有差异）。但这个入口有个问题：到期后它会自动恢复，而且暂停期间某些安全更新仍可能被推送。
真正意义上的"延长"，是通过注册表去修改更新的"目标版本"和"功能更新延迟天数"。比如把功能更新推迟 365 天、质量更新推迟 30 天，这样系统在很长一段时间内都不会主动升级大版本。这个思路比"硬禁止"温和，适合生产环境。后面第 4 节会给出具体键值。
3. 用注册表从源头掐断更新触发
注册表是这套操作的核心战场。相比组策略（家庭版没有）和服务管理，注册表在几乎所有 Windows 版本上都可用，而且能触及到组策略覆盖不到的角落。
3.1 关键注册表路径与作用
先把要动的几个路径列出来，每一个都对应一个具体的"开关"：
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU这是更新策略的主控位置。NoAutoUpdate设为 1 表示关闭自动更新，AUOptions设为 2 表示"通知下载但不自动安装"。HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate这里控制功能更新和质量更新的延迟。DeferFeatureUpdates设为 1 并配合DeferFeatureUpdatesPeriodInDays可以推迟大版本更新。HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings这里存放"暂停更新"的截止时间。PauseUpdatesExpiryTime是一个时间戳，改大它就能延长暂停期。HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wuauserv服务的启动类型。Start值 4 表示禁用，但前面说过，光改这个不够。
我一般会把这几个路径的修改写成一个.reg文件，双击导入，省得每次手动找。下面给一个可以直接用的模板。
3.2 一份可直接导入的注册表模板
把下面内容保存为disable_update.reg，注意编码要用 ANSI 或 UTF-16 LE，否则中文注释可能乱码：
Windows Registry Editor Version 5.00 ; 关闭自动更新 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] "NoAutoUpdate"=dword:00000001 "AUOptions"=dword:00000002 ; 推迟功能更新 365 天 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate] "DeferFeatureUpdates"=dword:00000001 "DeferFeatureUpdatesPeriodInDays"=dword:0000016d "DeferQualityUpdates"=dword:00000001 "DeferQualityUpdatesPeriodInDays"=dword:0000001e ; 延长暂停更新到期时间（示例时间戳，需按需调整） [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings] "PauseUpdatesExpiryTime"="2099-12-31T00:00:00Z"这里0000016d是十六进制的 365，0000001e是十六进制的 30。注册表里 dword 用十六进制表示，很多人直接填十进制会出错，这是第一个坑。
3.3 导入之后为什么还是没生效
导入注册表后，很多人发现更新照样跑。原因通常有三个：
第一，没有重启相关服务或系统。注册表策略需要wuauserv重新读取才生效，最稳妥的是重启一次。
第二，被组策略或 MDM 覆盖。如果你的机器加入了域或者被移动设备管理接管，本地注册表可能被更高优先级的策略覆盖。这时候要看gpresult /h report.html的输出，确认实际生效的策略来源。
第三，WaaSMedicSvc 把改动"修复"了。这个服务会定期扫描并还原它认为"异常"的更新配置。所以改完注册表后，还要处理这个服务，方法见下一节。
注意：
PauseUpdatesExpiryTime这个键在不同 Windows 版本里行为不一致，有的版本会校验时间戳格式，格式不对会被忽略。建议用 ISO 8601 格式，并且不要设置得过于离谱（比如超过几十年），否则可能被判定为无效。
4. 服务、计划任务与"更新医生"的联合处理
注册表是"立法"，服务和计划任务是"执法"。只立法不执法，政策就是一张废纸。这一节讲怎么把执行层也管住。
4.1 禁用服务时绕开"受保护"限制
普通服务可以在services.msc里直接改启动类型，但WaaSMedicSvc是受保护的，图形界面改不了。这时候要用命令行：
sc config WaaSMedicSvc start= disabled sc stop WaaSMedicSvc注意start=后面必须有一个空格，这是sc命令的语法要求，写成start=disabled会报错。这个细节坑过很多人。
对于wuauserv、UsoSvc、BITS、DoSvc，同样处理：
sc config wuauserv start= disabled sc config UsoSvc start= disabled sc config BITS start= disabled sc config DoSvc start= disabled但这里有个反直觉的点：BITS 不建议彻底禁用。因为很多正常软件（比如某些下载工具、系统组件）也依赖 BITS。如果你把 BITS 禁了，可能会出现一些莫名其妙的下载失败。我的做法是把 BITS 设为"手动"，而不是"禁用"，这样更新不会主动用它，但其他程序需要时还能启动。
4.2 计划任务才是真正的"发令枪"
服务停掉之后，计划任务到点还是会尝试启动它们。所以要进taskschd.msc，找到下面这些任务并禁用：
Microsoft\Windows\UpdateOrchestrator下的所有任务Microsoft\Windows\WindowsUpdate下的所有任务Microsoft\Windows\InstallService下的相关任务Microsoft\Windows\WaaSMedic下的任务
手动一个个点太累，可以用命令行批量禁用：
schtasks /Change /TN "\Microsoft\Windows\UpdateOrchestrator\Schedule Scan" /Disable schtasks /Change /TN "\Microsoft\Windows\UpdateOrchestrator\Schedule Scan Static Task" /Disable schtasks /Change /TN "\Microsoft\Windows\WindowsUpdate\Scheduled Start" /DisableUpdateOrchestrator下的任务名字在不同版本里略有差异，建议先用schtasks /Query /TN "\Microsoft\Windows\UpdateOrchestrator"列出实际任务名，再逐个禁用。
4.3 处理"更新医生"的复活逻辑
WaaSMedicSvc是最难缠的一个。即使你禁用了它，某些版本的系统在检测到更新组件异常时，会通过一个受保护的计划任务把它重新启用。彻底的处理方式是同时做三件事：
- 禁用
WaaSMedicSvc服务（前面已讲）。 - 禁用
Microsoft\Windows\WaaSMedic下的计划任务。 - 修改
WaaSMedicSvc对应的注册表项，把它的启动类型锁死。
对应的注册表路径是：
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WaaSMedicSvc] "Start"=dword:00000004Start值 4 就是禁用。改完之后重启，这个服务就不会再自动起来了。
提示：这一套操作做完之后，Windows 安全中心可能会提示"更新服务异常"。这是正常现象，不用管它。如果你在意这个提示，可以在安全中心里把相关通知关掉。
5. "延长 100 年"这种说法背后的真实操作
标题里提到"可选延长 100 年"，这其实是一种夸张说法，指的是把更新的暂停到期时间设置到一个极远的未来。但这里有几个技术细节必须讲清楚，否则你设了也没用。
5.1 暂停时间的存储格式与上限
Windows 把"暂停更新"的到期时间存在PauseUpdatesExpiryTime这个字符串值里，格式是 ISO 8601。理论上你可以填9999-12-31T23:59:59Z，但实测中，某些版本的系统会对这个值做范围校验，超出合理范围会被忽略或重置。
我实测下来，填到 2099 年是稳的，再往后就看你系统版本了。所以"100 年"更多是个说法，实际操作中填个几十年足够覆盖设备生命周期。
5.2 为什么单纯改时间不够
即使你把暂停时间改到 2099 年，系统在以下几种情况下仍可能恢复更新：
- 手动点击"检查更新"按钮
- 某些安全软件或系统维护任务触发更新扫描
- 系统检测到关键安全漏洞，强制推送补丁
- 大版本升级的强制推送（比如 Windows 10 到 11 的升级引导）
所以"延长"必须配合前面讲的注册表策略和服务禁用一起用，单靠改时间是不牢靠的。
5.3 一个更稳妥的组合方案
我目前在生产机器上用的组合是这样的，实测稳定运行超过两年没有意外更新：
| 层面 | 操作 | 目的 |
|---|---|---|
| 注册表策略 | NoAutoUpdate=1，推迟功能更新 365 天 | 从策略层关闭自动更新 |
| 暂停时间 | PauseUpdatesExpiryTime 设为远期 | 延长官方暂停入口 |
| 服务 | 禁用 wuauserv、UsoSvc、WaaSMedicSvc | 切断执行层 |
| 计划任务 | 禁用 UpdateOrchestrator 全部任务 | 切断触发层 |
| BITS | 设为手动 | 保留其他程序依赖 |
这套组合的逻辑是"层层设防"，任何一层被绕过，还有其他层兜底。比只改一个地方可靠得多。
6. 实操中踩过的坑与验证方法
前面讲的都是"应该怎么做"，这一节讲"实际做的时候会出什么问题"。这些坑网上教程基本不会提，但每一个都能让你白忙半天。
6.1 注册表导入后中文乱码
用记事本保存.reg文件时，默认编码可能是 UTF-8。如果文件里有中文注释，导入时可能报错或乱码。解决办法是保存时选择"ANSI"编码，或者干脆去掉所有中文注释。我现在的习惯是.reg文件里只写英文注释，避免编码问题。
6.2 权限不足导致修改失败
修改HKEY_LOCAL_MACHINE下的某些键需要管理员权限，而且部分键的属主是TrustedInstaller，连管理员都改不了。这时候要右键键值 → 权限 → 高级 → 更改所有者，把所有者改成 Administrators，再赋予完全控制权限。
这个过程比较繁琐，建议只对确实改不动的键做这个操作，不要全局改，否则可能影响系统稳定性。
6.3 怎么验证更新真的被禁用了
改完之后不能只看设置界面，因为界面可能显示"已暂停"但后台仍在活动。可靠的验证方法是看日志：
wevtutil qe "Microsoft-Windows-WindowsUpdateClient/Operational" /c:20 /rd:true /f:text这条命令会列出最近的更新客户端事件。如果禁用成功，你应该看不到新的"开始下载""开始安装"事件。如果还在出现，说明某一层没处理干净，回去检查计划任务和服务。
另一个验证点是看C:\Windows\SoftwareDistribution\Download目录。如果这个目录持续有新文件产生，说明更新还在下载。禁用成功后，这个目录应该保持静止。
6.4 更新被禁后出现的"副作用"
有几个副作用要有心理准备：
- Windows 安全中心的"病毒和威胁防护"定义更新也会被一起禁掉。如果你需要这个，得单独放行定义更新。
- 某些依赖最新运行库的软件可能装不上，因为系统组件版本偏旧。
- 微软商店的部分应用更新会失败。
我的处理方式是：对必须联网的生产机器，只做"延长"不做"禁止"，并且定期手动打一次累积更新；对完全隔离的机器，才彻底禁止。这个取舍要根据你的实际场景来定。
7. 不同 Windows 版本的差异与适配
这套操作在 Windows 10 和 Windows 11 上大体通用，但有几个版本差异必须注意，否则你会遇到"照着教程做但没效果"的情况。
7.1 Windows 10 与 Windows 11 的机制差异
Windows 11 在更新调度上比 Windows 10 更激进，主要体现在两点：一是UsoSvc的触发频率更高，二是WaaSMedicSvc的自我修复更主动。所以在 Windows 11 上，计划任务的禁用要更彻底，UpdateOrchestrator下的任务一个都不能漏。
另外 Windows 11 引入了"更新完成后自动重启"的默认行为，即使你禁用了自动下载，已经下载的更新仍可能在重启时安装。这时候要额外检查ActiveHours设置，把活动时间设得宽一些，减少意外重启。
7.2 家庭版与专业版的策略差异
专业版有组策略编辑器（gpedit.msc），可以直接在"计算机配置 → 管理模板 → Windows 组件 → Windows 更新"里配置，比改注册表直观。家庭版没有组策略，只能走注册表。
但要注意，组策略本质上也是写注册表，只是写到了Policies路径下。所以专业版用组策略配置后，注册表里对应的键值会自动生成，两者不冲突。
7.3 长期服务版（LTSC）的特殊性
如果你用的是 LTSC 版本，恭喜你，它本身就不带应用商店和大部分 UWP 组件，更新频率低很多。但 LTSC 仍会有安全更新推送，所以前面讲的服务和计划任务处理依然适用。LTSC 的优势是功能更新少，你基本不用担心大版本升级打断工作。
8. 一套可复用的自动化脚本思路
手动操作一次两次还行，机器多了就受不了。我后来把整套流程写成了一个 PowerShell 脚本，新机器部署时跑一遍就行。这里给出核心思路，你可以根据自己的环境调整。
8.1 脚本的整体结构
脚本分四段：第一段备份当前配置，第二段改注册表，第三段禁用服务和计划任务，第四段输出验证结果。备份很重要，出问题能快速回滚。
# 第一段：备份关键注册表项 reg export "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" "$env:USERPROFILE\wu_backup.reg" /y # 第二段：写入策略 $auPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" New-Item -Path $auPath -Force | Out-Null Set-ItemProperty -Path $auPath -Name "NoAutoUpdate" -Value 1 -Type DWord # 第三段：禁用服务 $services = @("wuauserv","UsoSvc","WaaSMedicSvc") foreach ($svc in $services) { sc.exe config $svc start= disabled sc.exe stop $svc } # 第四段：验证 Get-Service wuauserv, UsoSvc, WaaSMedicSvc | Select-Object Name, Status, StartType这个脚本要在管理员权限的 PowerShell 里跑。注意sc.exe而不是sc，因为在 PowerShell 里sc是Set-Content的别名，直接写sc会调用错命令。这是 PowerShell 里非常经典的一个坑。
8.2 脚本执行后的检查清单
跑完脚本后，按这个清单逐项确认：
Get-Service输出里三个服务都是Stopped且StartType为Disabledtaskschd.msc里UpdateOrchestrator下任务全部为"已禁用"- 注册表
AU路径下NoAutoUpdate值为 1 - 事件日志里不再出现新的更新下载事件
任何一项不通过，就回到对应章节排查。这套流程我用了两年多，新机器部署基本十分钟搞定，比手动点来点去快得多，也不容易漏。
最后说一句个人体会：禁止更新这件事，技术本身不难，难的是"想清楚为什么要禁"以及"禁了之后怎么补安全"。我见过太多人一上来就把更新彻底关死，结果半年后系统被已知漏洞打穿。所以我的建议始终是——能延长就别禁止，能定期手动打补丁就别完全放任。工具是死的，判断是活的。
