Composer如何使用脚本清理缓存_Composer脚本清理缓存步骤-composer-PHP中文网

composer clear-cache 有时不生效是因为只清了全局缓存（~/.composer/cache），未清理项目级 vendor/composer/archives/ 等残留文件，且在 ci/cd 中需加 --no-interaction 参数并配合删除 vendor 目录及校验 lock 文件与 platform 配置。

composer如何使用脚本清理缓存_composer脚本清理缓存步骤

composer clear-cache 命令为什么有时不生效

直接运行 composer clear-cache 确实能清掉全局缓存，但如果你在 CI/CD 流程或 Docker 构建中反复遇到“缓存没清干净”“依然拉旧包”，大概率是因为：Composer 同时维护两层缓存——全局缓存（~/.composer/cache）和项目级 vendor 缓存（如 vendor/composer/archives/ 或 vendor/composer/installed.json 的残留）。前者清了，后者可能还留着旧的 dist 包或 lock 文件快照。

在 composer.json 中定义清理脚本的正确写法

想让 composer install 或 composer update 前自动清缓存，不能只写 "clear-cache" ——这个命令本身不支持 --no-interaction，在非交互环境会卡住。必须显式加参数，并用 shell 封装：

{
    "scripts": {
        "clean-cache": "composer clear-cache --no-interaction && rm -rf vendor/composer/archives/*",
        "post-install-cmd": "@clean-cache",
        "post-update-cmd": "@clean-cache"
    }
}

composer clear-cache --no-interaction 是必须的，否则在 GitHub Actions、GitLab CI 里会 hang 住
rm -rf vendor/composer/archives/* 清的是已解压/已下载的 zip/tar 包副本，不删它，下次 install 可能跳过重新下载
Windows 用户需改用 del /q vendor\composer\archives\*，且注意 Composer 脚本在 Windows 下默认走 cmd，不是 PowerShell

CI 场景下更稳妥的清理方式

GitHub Actions 或 Jenkins 中，别依赖 post-install-cmd —— 它只在本地执行成功后触发，而 CI 往往用 --no-scripts 跳过所有脚本。直接在 workflow 步骤里分步清理：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

- name: Clear Composer cache
  run: composer clear-cache --no-interaction

name: Remove vendor dir completely run: rm -rf vendor
name: Install dependencies run: composer install --no-interaction --prefer-dist
- 先清全局缓存，再删整个 vendor 目录，比只清 archives 更彻底
- 加上 --prefer-dist 强制走压缩包安装，避免因源码 clone 缓存导致行为不一致
- 如果用了 COMPOSER_CACHE_DIR 自定义缓存路径，记得在 CI 中也设好该环境变量，否则 clear-cache 会清错地方

清理后仍加载旧版本？检查 lock 文件和平台配置

缓存清得再干净，composer.lock 里锁死的版本号和 platform 配置（比如 "ext-zip": "0"）也会导致 Composer 回退到兼容旧版的包。常见表现是：composer install 明明没报错，但 vendor/autoload.php 加载的却是上一版类。

确认 composer.lock 是否被 git 忽略或未提交 —— 它才是实际安装依据
运行 composer show vendor/package 查看当前加载的精确版本，对比 composer.lock 里对应条目
如果项目声明了 "platform": {"php": "8.1"}，但 CI 环境实际是 PHP 8.2，Composer 可能悄悄降级选包，此时要同步 platform 配置或删掉它

缓存只是表象，真正决定装什么的，永远是 lock 文件 + 当前环境能力 + 平台约束三者的交集。