当项目依赖的 Composer 包被废弃且存在安全漏洞时，不能继续使用，必须立即采取行动。重点是快速识别风险、寻找可靠替代方案，并确保代码平稳过渡。以下是具体策略。

1. 确认包的状态与漏洞严重性

不要仅凭“abandoned”标签就移除包，先验证实际风险：

• 查看 GitHub/GitLab 仓库 是否有归档标记或作者声明
• 在 PHP Security Advisories Database（如 FriendsOfPHP）中搜索该包，确认是否存在已知 CVE 漏洞
• 运行 composer audit（Composer 2.5+）自动检测项目中的安全问题
• 检查漏洞是否影响你使用的版本，有些仅存在于旧版本中

如果漏洞确实存在且无修复计划，必须替换或修复。

2. 寻找活跃维护的替代包

目标是找到功能相似、社区活跃、定期更新的替代品：

• 在 packagist.org 搜索同类功能关键词，按“最近更新”和“下载量”排序
• 查看推荐替代项：有些废弃包会在 README 中推荐迁移目标（如 guzzle/guzzle → guzzlehttp/guzzle）
• 优先选择被主流框架或大型项目使用的包（如 Laravel、Symfony 组件）
• 检查 GitHub 的 issue 和 PR 活跃度，避免“伪活跃”

例如，若使用废弃的 JWT 包，可迁移到 firebase/php-jwt 或 lexik/jwt-authentication-bundle（Symfony 场景）。

3. 考虑临时接管或打补丁

如果没有合适替代品，但又必须使用：

• 尝试联系原作者，看能否移交维护权到社区组织（如 php-loep）
• 在公司内部 fork 并发布私有版本（如 your-company/package-name），自行修复漏洞并持续维护
• 使用 composer-patches 插件为现有包打安全补丁，作为短期过渡

注意：这只是权宜之计，长期仍建议迁移至主流方案。

4. 安全迁移的最佳实践

替换包时要确保系统稳定：

• 写单元测试覆盖原包的核心调用逻辑，便于验证新包行为一致
• 逐步替换，避免一次性大规模修改
• 更新文档和团队成员，说明变更原因与使用方式
• 提交清晰的 commit message，注明安全风险与解决方案

完成后运行完整测试流程，包括 CI/CD 中的安全扫描。

基本上就这些。关键是主动监控依赖健康状况，别等到出事才处理。