什么是 CBS.log？它为什么会膨胀到几个 GB

一段话讲清 Component-Based Servicing

CBS 是 Component-Based Servicing 的缩写——它是 Windows Update、可选功能和 DISM 修复背后的机器。它从 WinSxS 存储准备组件，在 TrustedInstaller 所属的事务中应用包，步骤失败就全部回滚；这些步骤每一个都逐行写进 CBS.log，附有时间戳和错误代码。系统文件检查器的报告也落在同一个文件里——sfc /scannow 留下的 [SR] 行，需要细节时用 findstr /c:"[SR]" 捞出来。健康的机器几个月也只积累几十 MB 的日记；没什么可清理的，因为没什么坏掉。

所以这个日志是诊断仪器，不是垃圾。它正是为出事的那天而存在：当更新卡在 87%，或某项功能安装死活不肯提交时，CBS.log 里记录的才是真正的错误——而不是设置应用给你看的那个笼统说法。

是什么把它吹到 GB 级

GB 级膨胀有一个压倒性原因：重试循环。更新在同一步骤失败，Windows 安排重试，重试以同样方式失败，而每次尝试都写进几千行。典型触发因素包括组件存储损坏（0x80073712 和 0x800f081f 家族）、永远无法提交的挂起包，或让 TrustedInstaller 的事务中途失败的磁盘错误。陷在这种循环里的机器一天能增加几百 MB——此时日志已不是问题本身，而是症状计数器。

如果你的 CBS.log 很大，请忍住直接删掉了事的冲动。文件受 TrustedInstaller 所有权限保护，普通删除根本弹回来；改名需要先夺取所有权，而等你折腾完，你也恰好毁掉了那个点名失败包和错误代码的记录。

CBS.log 以每天几十 MB 或更多的速度增长
更新历史里同一个 KB 反复失败
每次开机后 TrustedInstaller 连续占用 CPU 数小时
DISM /CheckHealth 或 /ScanHealth 报告存储损坏
0x80073712、0x800f081f 之类的错误在日志里反复出现
机器在“正在处理更新”界面停留异常久

修循环，不是修文件

真正有效的顺序是：先运行 DISM /Online /Cleanup-Image /RestoreHealth 修复组件存储，再跑 sfc /scannow，然后重启并让 Windows Update 再试一次——按这个顺序，因为 DISM 修的是 SFC 要踩的地基。之后检查更新历史：如果某个具体的 KB 仍在失败，就暂停更新，等下一个累积版本，而不是放任循环空转。循环一死，CBS.log 就回到正常的几十 MB，并保持在那里。

宣传能“缩小 CBS.log”的清理工具，治的是收据而不是那笔交易。删除日志不会改变更新失败的原因，只会拿走证据。改名的适用场景是极端情况——循环解决之后，小硬盘上仍躺着多 GB 的日志——而且只有那时才做，带着 TrustedInstaller 权限，并清楚自己正在抹掉这本日记。