立即停用废弃且存安全漏洞的 Composer 包，先确认风险等级与影响范围，通过 FriendsOfPHP 或 composer audit 检测漏洞；随后寻找高维护度替代包，优先选用主流框架依赖的活跃项目；若无合适替代，可临时 fork 维护或打补丁；迁移时需编写测试确保兼容性，逐步替换并更新文档，最终完成全面验证与安全扫描，杜绝长期使用不可维护依赖。
当项目依赖的 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 中的安全扫描。
基本上就这些。关键是主动监控依赖健康状况，别等到出事才处理。
