升级到 Adobe Commerce 2.4.8：真正会坏掉的是什么

Adobe Commerce 2.4.8 的系统要求页面（在新标签页中打开）会告诉您该跑在哪些版本上。它不会告诉您，这些版本变动里哪一个会悄无声息地吃掉您一周的工期。后面这半边，只有真正做过几次这类迁移之后才会浮现出来。以下是我们为客户从 2.4.6 迁移过来时所积累的经验。

环境概览

底层还有几项，分量远比一个版本号看起来要重。PHP 8.1 的支持不是被标记为弃用，而是直接移除，所以这里没有渐进的缓冲期。Elasticsearch 也是同一回事：OpenSearch 现在是唯一受支持的搜索引擎，而不是可选项之一。几个核心的第三方库同样被抬高了版本（Monolog 到 3.x、PHPUnit 到 10、Composer 到 2.8 以上）。此外，Adobe 把新装与升级时的默认索引器模式（在新标签页中打开）从「Update on Save」改成了「Update by Schedule」，目的正是降低日常运行中的负载与性能瓶颈。

真正吃掉工期的是哪一段

上面这些版本号，没有一个是难点。难点始终如一，是第三方模块与扩展的兼容性崩掉。

PHP 8.3/8.4 的类型处理比 8.1 严格得多，Monolog 3.x 改动了接口，方式是旧代码根本没有预期到的；在 PHP 8.1 下只是写得随便一点的代码，到了 8.3/8.4 会直接抛致命错误，而不再只是一条警告。那些从未针对严格类型更新过的旧定制模块与市场扩展，在我们做过的几乎每一次升级里，都是最大的时间黑洞。修法通常是三选一：等厂商发补丁、自己分叉一份扩展代码来维护，或者最糟的情况下整个换掉。而您通常要等到真的跑起来，才知道自己落在哪一种上。

我们的建议很直白：在动其他任何东西之前，先把每一个第三方扩展按 PHP 8.3/8.4 兼容性盘一遍。这件事要放在最前面，不是最后。它最有可能把工期炸掉，同时它也是在整套环境都还没就绪时就能先开工的一步。

4 次升级实际发生了什么

这不是纸面上的风险。我们目前已经做过 4 次到 2.4.8 的升级，规律每一次都成立：平均而言，已安装扩展里每 10 个就有 9 个，需要打完补丁店铺才重新正常工作。来自 Firebear、Amasty 这类知名且成熟的供应商的扩展，在这些项目里是持续出问题，而不是某一个环境上的偶发倒霉。这一点值得清醒看待：口碑好、维护活跃的厂商，也不代表第一天就一定兼容。而且问题不止在第三方代码。我们自己写、自己维护的内部定制扩展，同样需要打补丁才能跑在 2.4.8 上。在这次升级面前，没有谁的代码能豁免。

版本变动里潜藏的其他坑

有三个，值得在它们于升级途中给您来一下之前先知道：

• MySQL 8.4 的外键校验默认更严格。 restrict_fk_on_non_standard_key 现在开箱即开启，会让那些建立在非标准键上的定制数据表或老模块直接崩掉，而 MySQL 8.0 从来没为此吭过声。
• PHP 对 null 参数的处理同样收紧了。 在 PHP 8.1 下悄悄通过的、把 null 传进不接受 null 的内部函数参数的写法，轻则抛出弃用通知，重则直接抛类型错误。
• 从 Elasticsearch 换到 OpenSearch 不是改个配置开关。 它需要真正的服务器部署、索引映射的改造，以及上线前的测试；否则商品搜索出问题这件事，您会从客户那里得知，而不是从 QA 流程里。

如果您正在规划这次升级

从扩展盘点开始，并且给它留够预算。如果「每 10 个有 9 个需要补丁」大致就是可以预期的量，那么「确认兼容性」就不是出发前的快速检查，而是一个独立的项目阶段，有它自己的排期，也有它自己的风险——厂商那边的延误，不在您的掌控之内。

还有一件事，值得早点写进日历：把 Adobe 的支持预约排在您实际打算开始升级的至少 7 天之前。迁移途中真出岔子的时候，Adobe 的支持团队是能帮上大忙的；但您不会希望在最需要他们的那一刻，还在等一个排期名额。

升级本身做完之后，也别当成结束。每一项功能、每一处对接，都需要在新环境下重新测过，而不只是您预期会受影响的那些。这么大跨度的版本跳跃，牵动的底层依赖足够多，「部署很干净，所以应该没事」这种想法，正是问题绕过 QA 直接流到生产环境的常见路径。

我们为企业级 Adobe Commerce 客户做过这套迁移，面对的正是这种定制模块加历史数据库结构的组合。如果您正在规划 Adobe Commerce 升级，欢迎与我们聊聊。

---

资料来源：Adobe Commerce 系统要求（在新标签页中打开）与 2.4.8 版本发行说明（在新标签页中打开）（Adobe Experience League），以及我们自己在 4 次升级中积累的经验。