vendor/composer/installed.json是Composer生成的关键元数据文件，记录所有已安装包的名称、版本及install-path等信息，供dump-autoload、show等命令依赖；删除后仅导致重建延迟，不破坏依赖结构。
Composer install 或 update 后的 vendor/composer/installed.json 是什么？
这个文件是 Composer 自己生成的运行时元数据，记录当前 vendor/ 下所有已安装包的名称、版本、安装路径等信息。它不是“残留临时文件”，而是后续执行 composer dump-autoload、composer show 甚至某些插件功能所依赖的关键缓存。删掉它会导致下次命令变慢（需重建），但不会破坏依赖结构。
哪些文件真该清理？看 composer clear-cache 实际清什么
composer clear-cache 只清理全局缓存目录（通常是 ~/.composer/cache/），包括下载的 ZIP 包、解压后的 dist 包、Git 克隆的 shallow repo 等。它**不碰**项目本地的 vendor/、composer.lock 或任何临时构建产物。真正可能残留的是：
-
vendor/bin/下由包自动生成的可执行脚本（比如phpunit链接），卸载包后有时不自动删除 -
vendor/composer/autoload_*.php—— 这些是dump-autoload生成的，删了会触发下一次 autoload 重建，但无害 -
vendor/composer/ClassLoader.php和InstalledVersions.php—— 同样是生成文件，非必须保留
手动清理 vendor/ 时最常踩的坑
直接 rm -rf vendor/ 看似彻底，但容易忽略两点：
- 有些包在
post-install-cmd或post-update-cmd中写死了生成路径（比如把 JS 构建产物放到vendor/myorg/ui/dist/），删vendor/后重装可能跳过这些步骤，导致功能异常 -
composer.lock里记录的哈希值与实际vendor/内容强绑定；若手动删部分子目录（如只删vendor/symfony/console/），再跑composer install可能因校验失败报错：Package operations: 0 installs, 0 updates, 0 removals却不还原缺失目录 - Windows 下用
del /s /q vendor有时因文件锁失败，建议先关 IDE、PHP 进程再删
推荐做法：用 Composer 命令控制清理边界
想最小化干扰又确保干净，优先走 Composer 原生流程：
- 删整个
vendor/→ 运行composer install（而非update），它会严格按composer.lock还原，避免意外升级 - 只清理缓存 →
composer clear-cache，然后加-v参数看它清了哪些路径（输出含具体目录） - 检查是否真有“残留” → 运行
composer show --installed，对比输出和vendor/目录结构，多出来的才值得查 - CI 场景下可加
--no-scripts避免执行 post-xxx 钩子带来的副作用，清理更可控
真正的“残留”往往不是 Composer 自己留下的，而是第三方包的 install 脚本或你自己的 scripts 段写的逻辑——得去 composer.json 里翻 scripts 和各包的 composer.json 才能找到源头。
