最权威判断依据是packagist页面右上角「abandoned?」字段，由作者手动设置；若显示“this package is abandoned...”并注明替代包，则确认弃用；仅abandoned: true无replacement时需查github仓库活跃度或文档。
怎么看 Packagist 上的 abandoned 标识
最权威的判断依据是 Packagist 页面右上角的「Abandoned?」字段——它由包作者手动设置，不是 Composer 自动推断的。打开 https://packagist.org/packages/vendor/package-name，如果显示 This package is abandoned and no longer maintained. The author suggests using other-vendor/other-package instead，说明作者已明确弃用并推荐了替代项。
注意：composer show vendor/package-name 输出里若带 abandoned : true 或 replaced by : new/package 行，才是可信信号；仅显示 abandoned : true 而无 replacement，就得自己查 GitHub 或文档。
怎么查 GitHub 仓库的真实活跃度
Packagist 的「Last update」可能滞后几小时，但 GitHub 的「Updated X days ago」和「Latest commit」时间戳更准。执行 composer show vendor/package-name，从 source 或 homepage 字段拿到仓库地址，直接打开看：
- 超过 12 个月没
security、fix、chore(deps)类提交，基本可判停更 - 别只盯
main分支——有些项目把开发切到dev或next，得点进去确认 - Issues 长期无人回复、PR 堆积不合并、CI 工作流（
.github/workflows）近两年没跑过，都是静默停更的典型迹象
为什么 composer outdated 找不出废弃包
composer outdated 只比对版本约束是否可升，不管维护状态。一个包哪怕三年没更新，只要最新稳定版仍满足你 composer.json 里的 ^1.2 这类约束，它就不会出现在结果里。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
更麻烦的是：很多废弃包最后提交在 dev-main 分支，没打 tag，outdated 默认忽略非稳定版，根本“看不见”它已死。
所以必须主动查：
– composer show vendor/package-name 看更新时间与依赖层级
– composer depends vendor/old-package 定位谁在偷偷拉它进来
– composer outdated --direct 优先筛出你直连的废弃依赖
如何交叉验证替代方案是否靠谱
作者标了 replaced by 不等于能直接换。常见断裂点包括：
- 命名空间全变了（比如
Monolog\Logger→PhpLogging\Logger），得全局搜use Monolog\替换 - 构造函数签名不兼容（如
GuzzleHttp\Clientv6 到 v7，array $config变成HandlerStack $handler） - autoload 映射没覆盖原路径，类自动加载失败
- dev-dependency 里还引用着旧包的测试类（如
Monolog\Test\TestCase），导致 PHPUnit 直接报错
替换后必须跑一遍测试，尤其关注缓存、日志、HTTP 客户端这类高频路径——代码能跑通 ≠ 接口语义没变。
