Laminas已进入维护模式，官方停止功能更新，仅修复严重安全漏洞；核心组件不兼容PHP 8.2+，laminas-form在PHP 8.3报Deprecated错误，新项目不推荐使用。
为什么现在不推荐用 Laminas 构建新项目
直接说结论：Laminas（原 Zend Framework）已进入维护模式，官方明确不接受新特性，只修严重安全漏洞。2023 年起，laminas-mvc 和 laminas-console 等核心组件已停止功能更新；PHP 8.2+ 兼容性靠社区补丁勉强维持，但 laminas-form 在 PHP 8.3 下会触发 Deprecated: Creation of dynamic property 错误。
这不是“能不能用”的问题，而是“值不值得投入”的问题——你花三天调通 laminas-authentication 的 session 存储适配器，可能不如用 league/oauth2-server + symfony/http-foundation 两小时搭好更健壮的认证层。
如果必须维护老 Laminas 项目，关键兼容点在哪
老项目升级 PHP 版本时，最容易崩在三个地方：
-
laminas-servicemanagerv3.x 不支持 PHP 8.1 的readonly属性语法，需升到 v4.9+，但 v4.x 要求laminas-eventmanager≥ v3.6 —— 这个依赖链得手动对齐，不能全靠composer update -
laminas-db的Pdo\Mysql适配器在 PHP 8.2+ 默认开启strict_types=1后，execute()返回bool|ResultInterface类型冲突，得在调用前加类型断言：if ($result instanceof ResultInterface) { ... } - 模板层若还在用
laminas-view+Zend\Expressive\Template混合，$this->escapeHtmlAttr()在 PHP 8.3 会因内部反射调用失败而抛出ReflectionException，临时解法是改用htmlspecialchars()手动转义
替代方案怎么平滑过渡
不是推倒重来，而是分层替换：
立即学习“PHP免费学习笔记（深入）”；
- 路由和中间件层：保留
laminas-mvc的Application实例，但把控制器逻辑抽成独立服务类，用psr/container注册，后续可无缝接入nyholm/psr7+relay/relay - 数据库层：停用
laminas-db的 TableGateway 模式，改用doctrine/dbal直接操作，写个薄封装适配器，让旧代码调用$table->select()->where(...)仍能工作，底层走 DBAL - 表单验证：弃用
laminas-form的InputFilter，改用symfony/validator，定义#[Assert\NotBlank]注解，再写个LaminasFormBridge类把旧的getInputFilterSpec()映射过去
别踩的坑：Laminas 的“企业级”幻觉
很多人选 Laminas 是因为“它适合大型应用”，但实际卡点往往不在框架本身：
-
laminas-config的PhpArray加载器在生产环境没开 OPcache 时，每次请求都include数十个配置文件，IO 开销比 JSON/YAML 高 3 倍 —— 这种性能陷阱不会报错，只会让 TTFB 慢得莫名其妙 -
laminas-i18n的Translator默认用Gettext，但 PHP 的gettext扩展在 Alpine Linux（Docker 常用）里默认不装，docker-php-ext-install gettext还得额外装libintl，CI 里容易漏掉 - 所谓“模块化”其实是靠
ModuleManager扫描目录，一旦模块数超 20 个，getAutoloaderConfig()的返回数组嵌套层级太深，PHP 8.1 的 GC 会反复触发，内存占用翻倍
真正影响扩展性的，从来不是框架名字里有没有“Enterprise”，而是你敢不敢删掉 vendor/laminas/laminas-modulemanager 里那 37 行没注释的 foreach 嵌套循环。
