composer clear-cache 只删除 Composer 元数据缓存（如 packages.json、dist 哈希），不删 vendor/、不卸载已安装包、不影响 composer.lock。
composer clear-cache 会删掉什么？
composer clear-cache 只清 Composer 自己的元数据缓存（比如从 Packagist 或私有仓库拉下来的 packages.json、dist 哈希信息），不碰 vendor/、不删已安装包、也不影响项目本地的 composer.lock。它解决的是“为什么 composer update 总说没新版本”这类问题，不是清理测试环境残留依赖的正确手段。
测试环境残留依赖的真实来源
测试环境（尤其是 CI 或临时 Docker 容器）里堆积的“用不到却还在 vendor/ 里的包”，通常来自以下几种情况：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行过
composer install --no-dev，但之前运行过composer require --dev phpunit，导致vendor/里混进了 dev 包，而--no-dev只跳过安装，不卸载已有包 - CI 脚本反复执行
composer install+composer require xxx，但没做composer remove，旧包越积越多 - 用了
composer create-project拉模板，模板自带一堆 dev 工具，后续又没清理 - 本地跑过
composer update，但没提交更新后的composer.lock，CI 拉的是旧 lock，实际vendor/却是新旧混合状态
真正有效的清理方式：重装 + 精确控制
别指望“一键清理”，测试环境要的是确定性。最可靠的做法是彻底重建 vendor/，并严格限定安装范围：
- 先删干净：
rm -rf vendor/ composer.lock（注意：仅限测试环境；生产或开发机千万别这么干） - 只装运行时依赖：
composer install --no-dev --prefer-dist --optimize-autoloader - 如果必须临时加某个 dev 工具（比如调试用的
psy/psysh），用composer require --dev --no-update psy/psysh，再单独composer update psy/psysh --with-dependencies，避免污染主依赖树 - CI 中建议加校验步骤：
composer show --direct | wc -l输出行数，和预期数量比对，防止意外多装
容易被忽略的“缓存”其实是 vendor/ 本身
很多人把 vendor/ 当成“可缓存目录”反复复用，但在测试场景下，它就是最大的不确定性来源。真正的缓存优化点在 Composer 的 dist 包下载层（比如用 COMPOSER_CACHE_DIR 指向共享缓存目录），而不是让 vendor/ 在不同构建间残留。每次测试都该从干净的 vendor/ 开始，否则你永远不知道哪个包是上次遗留的、哪个是这次真需要的。
