微软计划2026年9月底至10月初推出Windows 11 26H2更新,24H2/25H2设备可通过174KB启用包升级
本文是 24TopNews 对公开财经信息完成重复合并后的事件分析,不是原始采访或证券推荐。
与以往包含大量新功能、底层改动明显的年度功能更新不同,26H2将是一项相对平淡的版本迭代,重点并非大幅重构系统,而是延续现有代码分支,通过更轻量的方式启用已预置的功能,以降低兼容性风险并提升系统稳定性。过去多年中,Windows功能更新通常会一次性带来数十项新特性与改进,同时伴随底层系统版本变化。微软在2024年10月推出Windows 11 24H2后,系统一度出现多类问题,包括硬件兼容性故障、功能回归及稳定性异常,部分问题持续数月才得到解决,这促使微软调整策略,减少由年度大版本切换带来的风险。
Windows 10时代,微软曾将这种更新思路称为“Windows即服务”,即持续向系统推送新功能。不过,频繁更新并未完全解决底层代码分支变化所造成的兼容性问题。24H2是Windows 11最近一次基于全新服务分支打造的大型功能更新,而随后的25H2和即将到来的26H2,均建立在24H2的同一基础分支之上。微软采用“共享服务”模式,在这一模式下,使用相同代码库的Windows版本可以共享安全更新、非安全修复、兼容性验证以及发布前的回归测试。不同版本之间的核心差异,主要在于新版本额外启用了哪些功能。
从Windows 11 25H2升级至26H2,并不等同于切换至一个全新的系统分支。26H2与25H2使用相同的源代码,区别只是前者将更多功能开关设为启用状态。因此,如果某项问题会影响26H2,通常也会影响25H2;同样,针对该问题推出的修复更新也将适用于两个版本。对于企业用户而言,这并不意味着可以完全跳过部署前测试,但测试重点可集中于新启用的功能,无需再重复进行完整的应用兼容性、硬件兼容性及认证流程。这种机制有助于显著降低跨版本升级的测试与维护负担。
共享服务并非Windows 11才出现的新概念。微软在2019年推出Windows 10 1909时便采用过类似方案,当时1909的新代码会提前通过更新进入Windows 10 1903设备,但相关功能默认处于关闭状态,待正式发布后再统一启用。Windows 11 23H2相对于22H2,也使用了相近的更新逻辑;如今,24H2、25H2与26H2则构成了新的共享分支体系。由于采用同一服务分支,微软不必等到26H2正式发布才开始向用户分发相关代码,许多后续版本所需组件可以通过每月累计更新提前安装在设备中,但默认保持禁用。微软确认,在同一服务分支内,月度累计更新将覆盖不同Windows版本,而下一版本的新增功能载荷也会以禁用状态包含在更新中。
用户在版本更新时,主要获得的是功能启用以及新的支持生命周期,而非重新下载完整系统。这一机制也为不同需求的用户提供了更灵活的选择。重视稳定性的用户可以继续留在当前版本,等待新功能经过更长时间的验证;希望维持支持周期的用户,则可在临近版本终止支持时进行升级。以24H2为例,该版本的支持将于2026年10月结束,用户可先升级至25H2,随后再在适当时机转向26H2。
26H2正式推出后,用户可根据当前系统版本,通过ISO镜像、完整功能更新或启用包三种方式完成安装。ISO镜像对应完整的系统安装,而完整功能更新通常适用于需要更换底层服务分支的设备。对于已经具备所需代码的设备,微软则可提供体积更小的启用包,也就是eKB。微软表示,完成新版本后会同时为Windows Update提供完整功能更新和启用包。其中,完整功能更新用于底层系统分支发生变化的情况;启用包则可让已运行Windows 11 25H2的设备迅速切换至26H2。
相反,仍在Windows 11 22H2或23H2分支上的用户,则需要接收完整的功能更新。以Windows 11 23H2升级至26H2为例,由于23H2并不属于24H2、25H2和26H2所在的服务分支,系统必须完成一次较大规模的底层迁移。微软尚未公布从23H2直接升级至26H2的最终安装包大小,但此前公布的23H2升级至25H2案例可作参考:完整更新包含约5.3GB的Windows 11 24H2基础镜像,以及约887MB的累计更新包,整体体积接近6.5GB。
相比之下,从Windows 11 24H2或25H2升级至26H2的成本极低。此前信息显示,在已运行24H2或25H2的设备上,Windows 11 26H2的启用包仅约174KB。微软曾以类似升级情形说明,这一体积约为完整6.5GB功能更新的“万分之三”。其原因在于,下一版本所需的绝大多数代码早已通过此前的累计更新存放在电脑中,启用包主要负责激活新功能、重启系统,并更新Windows的内部版本号及支持生命周期。通过启用包安装Windows 11 26H2大致分为四个阶段:首先将新代码的功能标记从禁用改为启用;随后系统重启;重启后正式激活相应功能;最后更新Windows的内部版本号。
微软希望借此减少大版本升级引发的兼容性和稳定性问题,让Windows的功能演进从一次性的大规模切换,转向更平滑、更低风险的持续更新模式。