如何通过Composer命令检查项目中所有依赖包的官方维护状态-composer-PHP中文网

不能，composer show仅显示已安装包的版本、描述和依赖关系，不包含是否弃用、移交或归档等官方维护状态，需结合packagist api的abandoned字段、github仓库commit时间及issues响应情况综合判断。

如何通过composer命令检查项目中所有依赖包的官方维护状态

composer show 命令能查到维护状态吗

不能。composer show 只显示已安装包的版本、描述和依赖关系，不包含官方维护状态（比如是否弃用、是否移交、是否归档）。它甚至不会告诉你 symfony/console 已经从“maintained”变成由 Symfony 团队统一维护——这种信息不在 Composer 的本地元数据里。

真正有用的线索藏在包的 composer.json 元数据中，尤其是 abandoned 字段和 homepage/source 链接指向的仓库状态。但这些字段必须通过远程 API 或实际访问源码仓库才能验证。

用 composer outdated --direct + packagist API 查废弃包

最接近“检查维护状态”的可行路径是组合使用命令和外部数据源。核心思路：先找出直接依赖，再逐个查 Packagist 的元数据接口，看是否有 abandoned 标记或推荐替代包。

composer outdated --direct --format=json 输出 JSON 列表，含所有直接依赖及其最新可用版本
对每个包，调用 Packagist API：https://packagist.org/packages/{vendor}/{package}/json
检查返回 JSON 中的 abandoned 字段：true、false，或字符串（如 "laravel/framework" 表示推荐迁移）
注意：API 有速率限制（未登录约 60 次/小时），批量查时加 sleep 0.1 避免被 429 拒绝

示例片段（bash）：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

composer outdated --direct --format=json | jq -r '.installed[] | "\(.name)"' | while read pkg; do
  vendor=$(echo $pkg | cut -d'/' -f1)
  name=$(echo $pkg | cut -d'/' -f2)
  curl -s "https://packagist.org/packages/$vendor/$name/json" | jq -r '.package.abandoned'
done

GitHub/GitLab 仓库页面才是最终判断依据

即使 Packagist 显示 "abandoned": false，也不能代表当前仍在活跃维护。真实状态得看源码托管平台：

打开 source 字段指向的 GitHub URL（通常在 composer.json 的 source 或 Packagist API 的 repository 字段里）
检查最近一次 commit 时间（>1 年无更新大概率已停滞）
看 Issues 和 PR 是否长期无人处理；是否有 pinned issue 写着 “This package is no longer maintained”
特别注意：有些包标记为 abandoned 但只是移交给了新组织（如 monolog/monolog → php-fig/log），这时要确认新包是否真在维护