Composer无自动清理“不再需要”依赖功能，需手动处理。1. 使用composer remove卸载指定包可安全移除并更新锁定文件；2. 删除vendor目录后执行composer install可彻底重置依赖，仅保留composer.json声明的包；3. 通过对比vendor/目录与composer.json的require及require-dev列表，可识别潜在残留包，但需注意间接依赖不可误删；4. 运行composer outdated有助于审查已安装依赖状态。保持依赖整洁需规范操作，避免残留。
Composer 本身没有像 Linux 系统中 apt autoremove 那样自动移除“不再需要”的依赖包的命令，但你可以通过手动方式或组合命令来清理那些已安装但当前 composer.json 中未声明的旧依赖包。
理解问题：什么是“不再需要”的依赖？
当你运行 composer require some/package 后，该包及其依赖会被安装到 vendor/ 目录。之后如果你从 composer.json 中删除了这个包，但没有运行 composer remove，它的文件可能仍然留在 vendor/ 中。这些就是所谓的“残留”或“不再需要”的包。
方法一：使用 composer remove 显式卸载
这是最安全、推荐的做法。如果你明确知道某个包不再需要，直接卸载：
composer remove vendor/package-name这会从 composer.json 中移除该条目，并删除 vendor/ 中对应的文件，同时更新 composer.lock。
方法二：删除 vendor 目录并重新安装（彻底重置）
如果你想确保所有内容都与当前 composer.json 完全一致，可以：
- 删除整个
vendor/目录 - 重新运行
composer install
composer install
这样只会安装 composer.json 中声明的依赖，任何“残留”包都会被清除。适合部署环境或修复混乱的依赖状态。
方法三：分析并识别未声明的包（进阶清理）
如果你想找出哪些包在 vendor/ 中存在，但不在 composer.json 中声明，可以用以下脚本思路：
列出 vendor/ 下的所有包目录：
再对比 composer.json 中的 require 和 require-dev 列表。不在其中但存在于 vendor/ 的，可能是残留包。
注意：某些包是其他依赖的子依赖（间接依赖），即使没直接写在 composer.json 中也是必要的，不能随意删除。
小技巧：利用 composer outdated 检查状态
运行：
composer outdated可以查看哪些依赖有新版本可用，也能帮助你审查当前项目到底有哪些包被安装，辅助判断是否合理。
基本上就这些。Composer 不会自动清理“孤儿”包，保持整洁靠的是规范操作：用 remove 卸载，定期检查依赖，必要时重装 vendor。不复杂，但容易忽略。
