Composer 会通过 Packagist 元数据在 install/update 时警告 abandoned 包，如“Package monolog/monolog is abandoned”，该状态源自作者在 composer.json 中设置的 "abandoned" 字段，仅提示不阻止安装。
怎么一眼识别出包已被弃用（abandoned）
Composer 本身不会主动“标记”一个包为废弃，但当你运行 composer install 或 composer update 时，只要依赖树里包含被 Packagist 主动标记为 abandoned 的包，就会在终端打出明确警告，例如：
Package monolog/monolog is abandoned, you should avoid using it. Use graylog2/gelf-php instead.
这个提示不是你本地配置出来的，而是来自 Packagist 的元数据——原作者在自己的 composer.json 里写了 "abandoned": true 或 "abandoned": "new-vendor/new-package"。
- 它不会阻止安装，也不会自动替换，纯属“善意提醒”
- 警告只在安装/更新时出现，
composer show或outdated默认不显示该状态 - 如果你没看到警告，不代表没被弃用——可能你根本没触发安装流程（比如只改了代码没跑
update），或该包是间接依赖且未被重新解析
用命令行快速筛查所有已弃用包
没有单条命令能“直接列出全部 abandoned 包”，但你可以组合两个动作完成筛查：
- 先执行
composer show -a vendor/package-name查某个具体包——如果它在 Packagist 页面顶部显示“abandoned”，那show -a输出末尾通常会带一行abandoned: true或abandoned: other/package - 更实用的是：在项目根目录运行
composer outdated --all --format=json | jq 'select(.packages[].abandoned != null)'（需装jq），可筛出所有带abandoned字段的包（注意：此字段仅在 JSON 输出中由 Composer 2.5+ 注入，非所有版本都支持） - 若不想装
jq，可用composer show --all | grep -A5 -B5 abandoned手动扫屏，虽然土但有效
关键点：Packagist 网页是最权威来源，命令只是辅助。别信本地缓存——有时 clear-cache 后再 show -a 才能看到最新废弃状态。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
为什么 composer outdated 不显示 abandoned 包？
outdated 只关心“版本是否可升”，不关心“维护是否停止”。一个包哪怕已被弃用三年，只要它的最新稳定版仍满足你 composer.json 里的版本约束（比如你锁着 ^1.2，而它最后发布的是 1.2.5），outdated 就认为“无更新”，压根不会列出来。
- 它默认忽略
dev-分支、RC、beta等非稳定版，而很多废弃包的最后提交就在dev-main上，连“最新版”都算不出来 -
--all参数也不解决这个问题——它只是把间接依赖也拉出来比版本，不是加一层“废弃检测” - 真正要捕获“停更但版本没变”的风险，得靠人工交叉验证：
show -a看最后发布时间 + GitHub 仓库是否归档 + issue 是否半年无人回复
发现 abandoned 后，下一步该做什么？
别急着删。先确认它是不是真在用——搜项目代码里有没有 use、new、class_exists 或配置文件里的引用。有些包只是被其他依赖带进来的“幽灵依赖”，实际没调用。
- 如果提示里有明确替代包（如
abandoned: symfony/cache），优先看它的迁移文档，注意 API 是否兼容（比如CacheItemInterface和旧包的CacheInterface完全不同） - 如果没推荐，去 Packagist 搜同类关键词，按“Last updated”倒序排，避开“Updated 3 years ago”的高亮结果
- 切忌直接
composer remove—— 很多废弃包是底层组件（如psr/log的某个实现），删了会导致其他包报Class not found - 临时方案：用
repositories指向你 fork 的镜像，并打上私有 tag，至少保证构建不崩、漏洞可修
最常被忽略的一点：abandoned 不等于 insecure，但意味着没人修 CVE。所以即使暂时无法迁移，也要用 composer audit 单独扫一遍那个包，确认当前版本有没有已知漏洞。
