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/ 看似彻底，但容易忽略两点：

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

• 有些包在 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 才能找到源头。