Apigility 已于 2017 年停止维护，因其依赖已 EOL 的 Zend Framework 2，在 PHP 7.4+ 和 Composer 2.x 下存在组件冲突、Admin UI 构建失效及文档归档等问题；应迁移到 Laminas API Tools 或采用 Mezzio + Laminas API Tools 组件构建轻量现代 REST API。
Apigility 已于 2017 年正式停止维护，Zend Framework 3 之后的生态中不再支持它；当前用 PHP 构建 REST API，应直接使用 Laminas API Tools（Apigility 的官方继任者），或更轻量、现代的方案如 Mezzio（原 Expressive）+ Laminas MVC 组件。
为什么不能继续用 Apigility？
Apigility 依赖 Zend Framework 2 的核心组件（如 Zend\Mvc、Zend\Router），而 ZF2 在 2016 年已 EOL，其 Composer 包（如 zfcampus/zf-apigility）在 PHP 7.4+ 和 Composer 2.x 下普遍出现兼容性问题：
-
zfcampus/zf-apigility-admin会因zendframework/zend-servicemanager版本冲突报错：Class 'Zend\ServiceManager\Config' not found - 前端 Admin UI 依赖已下线的 Bower，构建脚本失效
- 所有官方文档和 GitHub issues 已归档为
read-only
迁移到 Laminas API Tools 的关键步骤
Laminas API Tools 是 Apigility 的直接升级版，保留了 Admin UI 和模块化结构，但底层切换为 Laminas（ZF3+ 的新命名）组件。迁移不是“升级命令”，而是重建：
- 用
composer create-project laminas-api-tools/api-tools-skeleton初始化新项目 - 手动将 Apigility 的
config/autoload/development.config.php中的'zf-apigility'配置块，改为'laminas-api-tools'对应键名（例如'api-tools-content-negotiation'→'api-tools-content-negotiation'保持一致，但服务名前缀从zf变laminas） - 原
module/V1/Module.php中的getAutoloaderConfig()必须删除——Laminas 使用 Composer 自动加载，不再需要该方法 - Admin UI 访问路径从
/apigility/documentation变为/api-tools，且需启用laminas-api-tools/admin-ui并运行php public/index.php development enable
更推荐：用 Mezzio + Laminas API Tools 组件手写 API
如果你不需要 Admin UI 这类“低代码”界面，而追求可控性、性能与长期可维护性，直接组合 mezzio（PSR-15 中间件框架）和 laminas-api-tools/provider 更合适：
立即学习“PHP免费学习笔记（深入）”；
-
mezzio不带 MVC 拦截器链，路由和错误处理更透明，适合微服务场景 - 用
laminas-api-tools/provider提供的ApiProblemResponse和ContentNegotiation能复用 Apigility 的标准响应格式（如application/problem+json） - 示例中间件中返回错误时：
return new ApiProblemResponse(new ApiProblem(400, 'Invalid input'));
- 避免
laminas-api-tools/admin带来的臃肿依赖（如 jQuery、RequireJS），PHP 内存占用下降约 30%
真正卡住人的往往不是“怎么写一个接口”，而是配置层隐式依赖和版本锁死——Apigility 的 zf-apigility-provider 在 Composer 中会强制拉取旧版 zendframework/zend-http，导致无法与其他现代库共存。动手前先 composer show laminas/* | grep api-tools 确认实际可用的包名和版本范围，比照着改配置更稳妥。
