Composer无法自动检测无维护包，需结合Packagist页面（Last update、abandoned标识、源码仓库活跃度）、composer show（查本地安装信息但不含维护状态）、composer prohibits（暴露与新环境冲突）等交叉验证。
Composer 本身不提供“自动检测无维护仓库”的功能，也没有内置命令能判断一个包是否已废弃、长期未更新或作者失联。所谓“检测”，实际是组合外部信息源 + 本地命令 + 人工判断的过程。
packagist.org 页面是唯一可信的维护状态参考
所有 Packagist 上注册的公开包，其主页会明确显示最后更新时间、版本发布频率、GitHub/GitLab 仓库链接、以及是否标记为 abandoned（已废弃）。这是最直接、最权威的依据。
- 打开
https://packagist.org/packages/vendor/package-name，重点看右上角的 Last update 和下方的 Abandoned? 标识 - 点击跳转到源码仓库（如 GitHub），检查
main或master分支最近一次 commit 时间、issue 是否积压、PR 是否无人合并 - 若页面显示
abandoned: "vendor/alternative"，说明原作者已主动弃用，并推荐了替代包 —— 这比任何工具扫描都可靠
composer show 只能查本地安装状态，不能反映维护活跃度
运行 composer show vendor/package-name 能看到已安装版本、依赖、描述等元信息，但它完全不包含“项目是否还在维护”这类语义数据。它甚至不会报错，哪怕该包最后一次发布是 2018 年。
- 输出里的
source字段只记录仓库地址，不校验可访问性或更新状态 -
time字段是 packagist 元数据发布时间，不是代码仓库 commit 时间 —— 两者可能差数月 - 不要依赖
composer outdated判断是否“被放弃”：它只比对当前composer.lock版本和 Packagist 上最新稳定版，而一个彻底停更的包可能仍存在v1.0.0的“最新版”
用 composer prohibits 发现隐性风险更有效
真正影响项目可持续性的，往往不是“包老”，而是“老包与新环境冲突”。composer prohibits 能暴露这类问题，比盯着更新时间更有实操价值。
- 执行
composer prohibits php:8.3，可列出所有因 PHP 版本限制而无法升级的包 - 运行
composer prohibits ext-gd，能发现哪些包硬依赖已被现代 PHP 移除的扩展 - 若某个包反复出现在多个
prohibits结果中，且作者未响应 issue，基本可判定它已事实性停止维护
别把“最后更新时间”当绝对标准 —— 有些稳定库（如 psr/log）三年没更新反而是好事；而有些高频发版的包，可能只是在修自己引入的新 bug。关键看它是否还能融入你的技术栈演进节奏，而不是它有没有在 GitHub 上“打卡”。
