微软面临的问题其实并不完全是由它自己造成的——问题在于：在系统长时间处于“休眠”状态（即未进行任何更新）之后，将其恢复到最新状态所需的时间实在太长了。微软总是极力强调自己计划让 Windows 系统变得更加高效；几乎每天都有微软的代表或粉丝坚称 Windows 11 比过去快了很多。不过他们往往避而不谈一个令人遗憾的事实：与如今的软件相比，过去的 Windows 系统在现代硬件上运行得反而更加流畅。最近，微软声称正在努力缩小 Windows 系统对系统资源的需求，甚至声称只需 8GB 的内存就足以让系统正常运行。我们只能寄希望于：在当前内存短缺和价格不断上涨的严峻形势下，开发者能够优先考虑提高软件对内存的利用效率；或者至少增加一些用户并不真正需要的新功能。然而，本周我的实际使用体验表明，还有另一个亟待解决的问题：那就是各类软件更新的数量——这个问题不仅存在于微软的产品中，其他软件供应商也同样存在。几天前，我写了一篇关于如何在 Windows 11 家庭版安装过程中跳过微软账户验证步骤的文章。作为媒体，我们总是会对这些宣称进行彻底的测试；于是我拿了一台搭载 x64 处理器的笔记本电脑来在实际硬件环境下验证这些说法。结果问题立刻出现了……我们之前就多次提到过软件更新的“诅咒”（即更新带来的各种麻烦）；但这台笔记本电脑虽然运行的是 Windows 11，而且更新也才进行了一年多时间，却仍然需要花费长达约七个小时才能成功启动系统（期间系统会不断提示有未安装的补丁需要下载）。除了大量的 Windows 组件更新外，系统还强制要求用户安装新的操作系统版本，同时还需要更新各种固件和驱动程序，导致系统不得不多次重启。更糟糕的是，整个更新过程充满了虚假的提示和误导用户的信息（比如所谓的“进度条”和“完成百分比”等）。

自从微软首次在 Windows 系统中引入进度条以来，这些进度条就一直无法准确反映软件的实际运行进度。比如：“软件的进度显示为 65%，然后突然在 30 秒内跳升到 98%，之后又停滞不前、无法继续运行……”这种糟糕的显示效果竟然持续了数十年，实在令人失望至极。虽然微软并非唯一犯这种错误的厂商，但由于 Windows 的普及程度极高，这个问题显得尤为突出。需要强调的是：这只是一台普通的 Windows 设备，运行的是该操作系统的正式版本；而且这台设备其实才刚刚被使用了几个月而已。这种现象凸显了一个亟待解决的问题：微软及其合作伙伴必须改进软件的运行效率。值得庆幸的是，如今人们终于开始重视代码的优化，而不再只是通过增加硬件资源来勉强让那些编写质量低下的应用程序正常运行。不过，我们也必须关注那些频繁发布的更新——这些更新往往源于科技行业普遍存在的“反正我们总能在产品发布后修复问题”的心态。几年前，当我询问一位 DevOps 项目负责人关于软件发布前的测试与验证流程时，他感到十分困惑：难道单元测试还不够吗？现代软件开发模式认为，一旦出现问题，就可以立即通过更新来解决问题。然而，这种做法的前提是用户愿意忍受频繁的更新，以及可能长达数小时的等待时间（尤其是当用户选择在两次更新之间间隔数月时）。科技行业终于意识到了提高效率的必要性（至少微软已经意识到了这一点）；同时，微软也必须解决那些频繁发布的更新所带来的问题。虽然宣称自己的软件能在资源有限的环境下正常运行固然值得自豪，但如果更新过程耗时过长（甚至需要用户等待数小时），那么这些自豪感就会化为泡影。毕竟，设备上的各种组件在更新时仍会持续占用大量系统资源。如果只是稍微缩短了软件的启动时间，却还要让用户面对大量等待更新的麻烦，那这一切也就毫无意义了。