必须执行 composer clear-cache 后加 --no-cache 参数运行 composer install，因为仅清缓存不阻止后续复用旧记录，而 --no-cache 才强制跳过缓存逻辑实现彻底重装。
Composer 会默认复用本地缓存的包，想彻底重新安装（比如换镜像、修复损坏包、验证真实依赖行为），必须绕过缓存——不是 composer update 或删 vendor 就够的。
为什么 composer install 不重下包？
Composer 默认从 ~/.composer/cache（或 Windows 的 %LOCALAPPDATA%\Composer\Cache）读取已下载的 zip/tar 包，哪怕你删了 vendor 目录，它仍会解压缓存里的旧归档。这省时间，但掩盖了网络层或包源的真实状态。
常见错误现象：composer install 后发现某个包行为异常，但 git log 显示代码没变——其实是缓存里那个 zip 本身就有问题（比如镜像同步滞后、压缩损坏）。
- 使用场景：切换到官方源调试、CI 环境确保纯净构建、怀疑缓存污染时验证
- 性能影响：首次执行会明显变慢（全量重下载），但这是必要代价
- 兼容性：所有 Composer 2.x 版本均支持，1.x 需 ≥1.10.0
composer clear-cache 是第一步，但不够
清缓存只是删掉本地归档和元数据，不强制后续命令跳过缓存逻辑。如果不加控制，install 或 update 仍可能立刻重建缓存并复用旧记录。
- 先运行
composer clear-cache，确认输出包含Clearing cache (all) - 紧接着必须加
--no-cache参数启动安装，否则缓存机制会在下载前就命中旧哈希 - 注意：
--no-cache对composer require同样有效，但对composer create-project也需显式加上
真正生效的命令组合
最简且可靠的流程是三步：清缓存 + 强制无缓存安装 + 避免 lock 文件干扰。顺序不能错。
- 删掉
vendor目录：rm -rf vendor（Windows 用rmdir /s vendor） - 清除全部缓存：
composer clear-cache - 无缓存重装：
composer install --no-cache - 如果想确保 lock 文件也不被信任（比如怀疑 lock 生成时源已异常），加
--ignore-platform-reqs或干脆删掉composer.lock再跑composer update --no-cache
示例错误操作：composer install && composer clear-cache —— 缓存清理在安装之后，完全无效。
CI/CD 中更稳妥的做法
在 GitHub Actions、GitLab CI 等环境，光靠 --no-cache 不保险，因为 runner 可能挂载了持久化缓存目录。得双重拦截：
- 设置环境变量禁用缓存：
COMPOSER_CACHE_DIR=/dev/null - 再配合
composer install --no-cache - 或者直接用临时目录：
COMPOSER_CACHE_DIR=$(mktemp -d) composer install
容易被忽略的一点：某些私有仓库配置了 http-basic 凭据，若缓存里存了带认证头的响应，--no-cache 能绕过，但凭据本身仍要确保可用——否则会卡在 401 错误，而不是缓存问题。
