CI中不应手动删除vendor目录或执行composer clear-cache，而应缓存~/.composer/cache/files/、仅清理临时文件如composer.lock~和*.dist，并禁用dev脚本与update操作以保障复现性。
CI 环境中 composer install 生成的临时文件（如 vendor/composer/installed.json、vendor/autoload.php 的中间缓存、未清理的 .lock 冗余副本）不是“垃圾”，但若不控制其生命周期，会污染构建缓存、拖慢后续 job、甚至导致依赖解析错误。关键不是“清不清”，而是“何时清、清哪些、是否影响复现性”。
CI 中不该手动删 vendor 目录本身
很多脚本在 CI 前加 rm -rf vendor 或 composer clear-cache，这看似干净，实则破坏了 Composer 的增量优化机制。尤其在启用 --prefer-dist 和构建缓存（如 GitHub Actions 的 actions/cache）时：
-
vendor/是安装结果，不是缓存 —— 删它等于强制全量重装，失去composer.lock锁定意义 -
composer clear-cache清的是全局下载包缓存（~/.composer/cache），CI runner 通常是干净容器，该缓存本就为空，执行它纯属冗余 - 真正该复用的是
~/.composer/cache/files/下已下载的 zip 包，删了反而触发重复下载
只清理 build 过程中产生的非必需中间产物
Composer 在安装过程中可能留下调试痕迹或临时写入失败的残留，这些才需要针对性清理：
- 检查是否存在未提交的
composer.lock临时文件：如composer.lock~、.composer.lock.swp—— 它们不会被composer install使用，但可能被 git 意外提交，建议在 CI 前加git clean -f -d -X（仅清理 .gitignore 中的文件） - 禁用 dev-only 脚本生成的临时输出：
composer install --no-dev --no-scripts可跳过post-install-cmd类命令，避免它们写日志或生成调试文件到vendor/外 - 如果用了
composer dump-autoload --optimize，它会在vendor/composer/下生成autoload_static.php等优化文件 —— 这些是有效产物，不应清理；但若 CI 同时跑多个 PHP 版本测试，需确保每次dump-autoload前先rm -f vendor/composer/autoload_static.php，避免跨版本混用
GitHub Actions / GitLab CI 中推荐的最小清理步骤
以 GitHub Actions 为例，一个安全、高效、可复现的流程应聚焦于隔离和裁剪，而非暴力清空：
- 用
actions/cache缓存~/.composer/cache/files/，键值含php-version和composer-lock-hash，避免缓存污染 - 运行
composer install --no-dev --no-progress --optimize-autoloader --ignore-platform-reqs（最后这个参数仅当 CI PHP 版本与composer.json中require.php不完全匹配时才加） - CI job 结束前，只清理明确不需要的产物：
find vendor/ -name "*.dist" -delete（某些包自带模板文件）、rm -f composer.phar（若本地下载了 phar） - 禁止在 CI 中运行
composer update—— 它会改写composer.lock，破坏可重现性；所有版本变更必须由开发者本地触发并提交 lock 文件
最容易被忽略的一点：CI 中的“清理”动作本身，如果没被纳入缓存键计算或没做幂等处理，反而会成为构建不一致的源头。比起删什么，更该盯住 composer.lock 是否被提交、vendor/ 是否被误加入 gitignore、以及 --no-dev 是否在所有生产环境路径中被统一应用。
