将原来的继承取代定义取消，改为：
2、官载取代：由微软官方在取代列表Package Details里面详细记载的取代关系。

外网有一种取代的定义：元数据取代metadata-supersedence。该取代类型由微软在服务器端更新补丁的元数据信息触发。当新补丁发布时，微软会通过元数据标记旧补丁为“被取代”，导致旧补丁从WU推送列表中移除。在此场景中，补丁B被标记为取代补丁A，因此安装B后，系统根据元数据判断B已覆盖A的功能，无需重复推送A，故A从列表中消失。所以，这种元数据取代跟我的推送取代就是一样的定义。

重新细分取代关系：
取代关系：
1、卸载取代：已知旧补丁A是新补丁B的子集，且打了旧补丁A，紧接着再打新补丁B，重启后旧补丁A从卸载更新列表（uninstall updates list）中消失。即可判断新补丁B卸载取代了旧补丁A。旧补丁A被完全卸载了，荡然无存‌、了无痕迹。此时可以选择跳过旧补丁A，只打新补丁B。
比如：KB5017361（2022年9月度汇总）是KB5044356（2024年10月度汇总）的子集，打了KB5017361，紧接着再打KB5044356，重启后作为旧补丁的KB5017361将从卸载更新列表中消失，这种就是卸载取代。可以选择跳过KB5017361，只打KB5044356。
注：卸载取代一般常见于月度汇总之间。服务堆栈之间并不存在卸载取代，打了A堆栈，再打B堆栈，两者并存，所以不符合卸载取代的判断条件，比如已知旧堆栈KB3020369（2015年05月12日服务堆栈）是新堆栈KB4490628（2019年03月服务堆栈）的子集，则可以跳过旧堆栈KB3020369，只打新堆栈KB4490628。
2、继承取代：已知旧补丁A与新补丁B相交，且打了旧补丁A，紧接着再打新补丁B，重启后旧补丁A从卸载更新列表中消失，旧补丁A不同于新补丁B的修复或影响被新补丁B继承了下去。即可判断新补丁B继承取代了旧补丁A。旧补丁A虽然从卸载更新列表中消失，但是它与新补丁B藕断丝连，打断骨头连着筋。
比如：KB3197868月度汇总与KB2631813是取代关系，前者取代后者，KB4534310月度汇总不取代KB2631813，且KB3197868月度汇总与KB4534310月度汇总相交。此时打了KB3197868，紧接着再打KB4534310，重启后作为旧补丁的KB3197868将从卸载更新列表中消失，新补丁KB4534310继承了旧补丁KB3197868对KB2631813的取代关系。这种就是继承取代。
注：继承取代一般常见于旧的月度汇总（2018年以前）与新的月度汇总（从2018年1月开始）之间。服务堆栈之间也不存在继承取代，已知旧堆栈A与新堆栈B相交，打了A堆栈，再打B堆栈，两者是并存关系。比如：旧堆栈KB4490628（2019年03月服务堆栈）与新堆栈KB5039339(2024年06月服务堆栈）相交。
3、推送取代：已知旧补丁A、新补丁B均为WU推送列表（WU push list）中的补丁，且仅仅打了新补丁B后，重新检查WU，旧补丁A从WU推送列表中消失。即可判断新补丁B推送取代了旧补丁A。很多时候，我们很难判断旧补丁A是否被新补丁B取代，直接交由Windows Update更新机制去判断是最简单的方法。倒序安装也是由此而来。
比如：KB2631813、KB3110329均为WU推送列表中的补丁，打了KB3110329后，重新检查WU，KB2631813已经从WU推送列表中消失，即可判断KB3110329取代了KB2631813，这种就是推送取代。
注：旧的定义是，打了A补丁，导致B补丁消失，称为A补丁取代了B补丁。就是指上面的推送取代，一般常见于补丁与补丁之间或月度汇总与补丁之间（除了月度汇总之间和服务堆栈更新之间的卸载取代和继承取代）。本帖大部分都是推送取代。推送取代命名还是有点不妥，但是暂时想不出更好的，再就是还有一种清理取代，也暂不进行定义，常见的也就这三种了。

@lanrsgwaijyut,@gwaijyut, 能否通过wu733交换个联系方式，我最近大半年也一直在研究这个，很想有共同兴趣者能沟通一下。无白痴问题，不无故骚扰。

声明：

由于BypassESU-vX采用的代理路线跟最新的ESU方案不一致，所以2023年1月10日以后，且Bypass后的WU的推送是假的，这时就不要开WU了，只能采用UpdatePack7R2去处理。也由于我未能及时发现其中的奥秘，导致了错误的推导，请大家原谅！！！

厉害了，谢谢分享

来顶个贴
以后在这边混了

顶顶顶，真正的技术贴

一、取代及衍生关系：
四）一些功能性补丁的取代及衍生情况
新增：
KB3110329（2015年12月09日多个远程漏洞）       取代了KB2631813（2011年11月3日远程漏洞）

wu733 发表于 2025-2-4 11:54
新增第三大点：
三、非ESU补丁方案与ESU补丁方案的怪异之处：
1、KB2631813（2011年11月3日远程漏洞）

KB2676562已经被取代了，无论是否ESU。建议再看看。
这边没法用短消息，那边处处受限，这环境真是没法愉快的玩耍啦！
KB2813347、KB3123479这两个我还没测试

感谢分享

lanrsgwaijyut 发表于 2025-2-11 13:05
是的，24.10.08版本不包含ESU补丁，更新线路已回归到非ESU方案的原始服务器。
BypassESU-v12/u使用esu.d ...

感谢你的告知，我还真没注意到这些

wu733 发表于 2025-2-11 12:58
“自20.5.20版起，Simplix使用了abbodi1406的ESU 补丁，23.3.15版(含)之后，移除了这个补丁”
意思是我 ...

是的，24.10.08版本不包含ESU补丁，更新线路回归到非ESU方案节点。
BypassESU-v12/u使用esu.dll(以及wuaueng.dll等其他库文件)将系统标记为ESU授权版本/或嵌入式ESU授权版本，绕开ESU检测，用以达成可联机更新的目的，
BypassESU-v13f也是一样的，与12/u的区别在于，批处理中加入了旁路的可选项，联机更新时，13f将系统标记为2008R2（或Windows Embedded Standard 7）.

lanrsgwaijyut 发表于 2025-2-11 12:53
隔壁那边已经没法正常交流了，这边重新写一遍吧
如果使用UpdatePack7R2做测试，建议使用23.1.11或23.2.4 ...

“自20.5.20版起，Simplix使用了abbodi1406的ESU 补丁，23.3.15版(含)之后，移除了这个补丁”
意思是我使用UpdatePack7R2-24.10.10版本就是未使用abbodi1406的BypassESU-v12，我的理解对不对？

wu733 发表于 2025-2-11 12:24
我改用UpdatePack7R2-24.10.10.exe（不采用BypassESU-v12）爆破非KB3125574方案镜像（2024.10.08），结果 ...

隔壁那边已经没法正常交流了，这边重新写一遍吧
如果使用UpdatePack7R2做测试，建议使用23.1.11或23.2.4版本。
原因是，自20.5.20版起，Simplix使用了abbodi1406的ESU补丁，23.3.15版(含)之后，移除了这个补丁。因为2023年1月，微软停止了对Win7的所有支持。
不使用ESU补丁的UpdatePack7R2版本，所集成的客户端WU默认使用“非ESU”更新节点(微软的“非ESU”WSUS)

lanrsgwaijyut 发表于 2025-2-11 11:14
KB2533552是一个必要的补丁，不可或缺。
如果不使用，在安装月度汇总之后，可能会因为无法验证winload.exe ...

我改用UpdatePack7R2-24.10.10.exe（不采用BypassESU-v12）爆破非KB3125574方案镜像（2024.10.08），结果推送也是9个补丁

不错。越方便越好。

KB2533552是一个必要的补丁，不可或缺。
如果不使用，在安装月度汇总之后，可能会因为无法验证winload.exe签名而无法开机。但又因为这个堆栈补丁不能倒序安装，微软在推送的时候干脆以SP1的编号（KB976932_9M+）命名，以绕开他自己的限制

感悟：

其实吧，补丁或月度汇总之间的取代、衍生关系从狭义上来说是正确的，但是从广义上来说，又不是正确的。比如说，非ESU补丁方案中，KB3110329取代了KB2631813，从狭义上（非ESU补丁方案）来说是对的，但是从广义上（ESU补丁方案）来说却是错的。也就是说，表面上打了A补丁，导致B补丁消失，A补丁取代了B补丁，这个A补丁只是诱因，决定权却在更新机制手上。换个角度解释就是：由于非ESU方案的月度汇总时间早，其它要打的补丁比ESU的要多，而ESU的月度汇总时间晚，其它要打的补丁比非ESU的要少。故判断，ESU方案的月度汇总在逐步取代旧补丁的过程似乎是掉了链子，所以更新机制到最后实在看不下去了，不得不强行进行干涉的结果。

新增第三大点：
三、非ESU补丁方案与ESU补丁方案的怪异之处：
1、KB2631813（2011年11月3日远程漏洞）
非ESU补丁方案中：KB2631813是冗余，KB3110329（2015年12月09日多个远程漏洞）取代了它
ESU补丁方案中：KB2631813不是冗余，KB3110329未取代它

2、KB2676562、KB2813347、KB3123479这三个补丁
非ESU补丁方案中：上面三个补丁是冗余
ESU补丁方案中：上面三个补丁不是冗余

感谢楼主分享

二、依存关系：
（一）升级Win7的RDP协议版本到8.1，解决win7连接不了win10远程桌面：
补充：KB2984972+KB2574819→又衍生了KB2984976，也即开始若不打KB2984972就不会推送KB2984976）

更正：KB2984972+KB2574819+KB2592687→又衍生了KB2984976，开始若不打KB2984972就不会推送KB2984976）

hiro2025 发表于 2024-12-11 17:09
我是通过dism最先集成KB2533552补丁的，最后安装测试时发现不存在这个补丁，是被替换了还是没安装上，最后 ...

那就是你集成KB2533552补丁未成功，离线集成需要换个方法，网盘里面有集成的方法

我是通过dism最先集成KB2533552补丁的，最后安装测试时发现不存在这个补丁，是被替换了还是没安装上，最后系统更新是还提示KB976932。

wu733 发表于 2024-12-7 19:58
不用集成补丁，直接用大佬们制作的PE系统代替微软自带的PE不香么？

有是考虑的是恢复环境，如果不给winre.wim集成补丁的话，会对恢复环境有影响吧

感谢分享

谢谢分享

fuyechun 发表于 2024-12-6 09:49
对于boot.wim和winre.wim这两个应该集成哪些补丁呢

不用集成补丁，直接用大佬们制作的PE系统代替微软自带的PE不香么？

谢谢一直更新这个帖子，我从这个帖子参考其他帖子自己研究离线集成了一个系统。

大神需要摩拜