Composer 会警告但不阻止安装废弃包，提示中含替代建议；废弃包未必有漏洞但通常无安全更新，需结合 composer audit 和 roave/security-advisories 等工具主动响应。
Composer 会明确标记并警告被废弃（abandoned）的包，但默认不会自动阻止安装或升级——它把决定权留给开发者，同时提供清晰提示和替代建议。
废弃包的识别与警告机制
当一个包在 Packagist 上被其维护者标记为 abandoned（例如通过 composer abandon 或手动在 Packagist 后台设置），Composer 在以下场景会输出黄色警告：
- 运行
composer install或composer update时，若锁文件或依赖图中包含该包 - 执行
composer show vendor/package查看包信息时 - 运行
composer outdated时，废弃包会额外标注(abandoned)
警告中通常包含推荐的替代包（如 vendor/package is abandoned, you should avoid using it. Use vendor/alternative instead.），前提是原作者设置了 replacement 字段。
安全风险不能仅靠“废弃”判断
被废弃 ≠ 有漏洞，但往往意味着：
- 不再接收安全补丁或 CVE 修复
- 不兼容新 PHP 版本或依赖项（间接引发运行时问题）
- 已知漏洞可能长期悬而未决
因此 Composer 的警告本质是风险提示而非安全拦截。是否构成实际威胁，需结合 composer audit（需 Composer 2.5+）、security-advisories 数据库或第三方工具（如 SensioLabs Security Checker 已停用，推荐使用 roave/security-advisories 约束）进一步验证。
主动应对废弃包的实用做法
不要只忽略警告。可采取这些具体动作：
- 检查
composer.json中是否直接 require 了该包；如有，优先寻找官方推荐替代品并迁移 - 若它是某依赖的子依赖（transitive dependency），用
composer depends vendor/package定位源头，再考虑升级或替换上游包 - 临时压制警告（不推荐）：加
--no-abandoned参数，但会掩盖风险 - 长期策略：在
composer.json中添加"abandoned": true到config段可让废弃包触发错误而非警告（需 Composer 2.4+）
配合安全审计形成闭环
单靠废弃警告不够。建议组合使用：
-
composer audit --format=summary：列出含已知漏洞的包（依赖 GitHub Security Advisory Database） - 在
composer.json中引入roave/security-advisories（空包，仅声明冲突）：能强制 Composer 拒绝安装带已知高危漏洞的版本 - CI 流程中加入
composer audit --no-dev并设为失败项，防止带风险依赖上线
基本上就这些。Composer 把废弃包当作“技术债务信号”，真正落地防护，还得靠开发者主动响应和工具链配合。
