Laminas MVC 已于 2021 年终止维护，不再接收任何更新；其最后稳定版为 v3.10.0（2022年6月），核心依赖已升级但框架未跟进，与 PHP 8.2+ 存在兼容风险，社区活跃度归零，新项目使用将面临无支持、难调试、生态停滞等问题。
Laminas（原 Zend Framework）MVC 已于 2021 年正式进入维护终止（EOL）状态，laminas-mvc 不再接收新功能、安全补丁或 bug 修复。现在用它启动新项目，等于主动选择一条没有官方支持、生态停滞、依赖链脆弱的路径。
为什么 laminas-mvc 不该用于新项目
这不是“不推荐”，而是有明确事实支撑的决策依据：
-
laminas-mvc的最后一个稳定版本是 v3.10.0（2022 年 6 月），此后所有 issue 和 PR 都被标记为wontfix - 其核心依赖如
laminas-eventmanager、laminas-servicemanager已转向 PSR-14/PSR-11 兼容模式，但laminas-mvc本身未跟进重构，导致与现代 PHP 8.2+ 的类型推导、只读类等特性存在隐性冲突 - 社区实际活跃度归零：Packagist 下载量年降幅超 75%，Stack Overflow 上近 18 个月无有效问答，GitHub Discussions 关闭
- 你遇到的任何问题——比如
ServiceManager在模块加载时循环依赖、RouteStack解析失败却静默吞掉异常、Console命令无法注入EventManager——都只能靠翻 2019 年的 commit 记录硬猜
如果必须维护老项目，怎么最小化踩坑
仅限已有生产系统升级或紧急修 bug 场景。重点不是“怎么用”，而是“怎么别崩”：
- 锁定依赖：在
composer.json中强制指定"laminas/laminas-mvc": "3.10.0"，禁用^或~版本约束，否则 Composer 可能拉取到带破坏性变更的预发布版 - 关闭开发模式自动重载：删除或注释
config/development.config.php中的'laminas-development-mode'模块，避免ModuleManager在热更时重复注册ConfigProvider导致ServiceManager实例错乱 - 路由调试加钩子：在
module/Application/src/Module.php的onBootstrap()里插入$e->getApplication()->getMvcEvent()->getRouter()->match($e->getApplication()->getRequest())并var_dump，绕过框架默认静默失败机制 - 避免在
Factory中调用$container->get()获取自身服务：这会触发ServiceManager递归解析，PHP 8.1+ 直接抛Fatal error: Uncaught RuntimeException: Maximum function nesting level reached
替代方案不是“选哪个框架”，而是“选什么架构”
真正要解决的从来不是“怎么写 Controller”，而是“如何让业务逻辑可测、可替换、不绑定 HTTP 层”。可行路径很窄，但清晰：
立即学习“PHP免费学习笔记（深入）”；
- 保留现有路由和控制器外壳，把业务逻辑全抽成独立
class，用psr/container接口注入，彻底解耦laminas-servicemanager - 用
league/route替换laminas-router，它轻量、无状态、兼容 PSR-7，且仍在维护；配合nyholm/psr7构建请求响应，去掉整个laminas-http依赖树 - 若需完整 MVC 体验，直接迁移到
mezzio（Laminas 官方推荐的后继者）：它基于 PSR-15 中间件，模块可插拔，mezzio-skeleton默认已弃用laminas-mvc，且支持平滑过渡——比如复用原有ServiceManager配置，只需改几行工厂定义
最常被忽略的一点：Laminas MVC 的模块自动发现机制（Module::getConfig() + ConfigProvider）在 PHP 8.1 后因 ReflectionClass::getConstructor() 返回 null 而偶发失败，错误不报在日志里，只表现为某个模块配置没加载。查这个得翻 vendor/laminas/laminas-modulemanager/src/Listener/ConfigListener.php 第 237 行，而不是看自己的代码。
