Composer update 默认走缓存是因为它会复用 ~/.composer/cache 中已下载的 dist 包，版本与校验和未变时直接解压，跳过网络请求；需用 composer clear-cache 等命令主动清理。
Composer update 为什么总走缓存？
因为 Composer 默认会把下载的包（尤其是 dist 包）缓存在 ~/.composer/cache 下，下次 composer update 时如果版本没变、checksum 没冲突，它就直接解压缓存，跳过网络拉取。这不是 bug，是设计行为——但当你遇到“明明改了 packagist 上的 zip，本地却没更新”或“怀疑缓存损坏导致安装失败”时，就得主动清。
清除缓存的三种有效方式
别用 rm -rf ~/.composer/cache 硬删（容易误删或权限问题），优先走 Composer 自带命令：
-
composer clear-cache：最常用，清空所有缓存（dist、source、metadata），输出清理路径和大小，安全可靠 -
composer clear-cache --no-interaction：适合 CI/CD 脚本，跳过确认提示 -
composer update --no-cache：本次 update 不读缓存（但不删除已有缓存），适合临时验证是否缓存导致异常
缓存位置和手动清理注意事项
默认缓存路径是 ~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）。如果你改过 COMPOSER_CACHE_DIR 环境变量，得先查真实路径：
composer config --global cache-dir
手动删前注意：
- 别只删
dist/子目录——clear-cache是全量清，部分删可能留脏 metadata - CI 环境中建议用
--no-cache而非清缓存，避免并发构建时互相干扰 - 某些私有仓库配置了自定义
cache-ttl，清缓存后首次 update 会明显变慢，属正常现象
缓存相关错误怎么快速判断？
遇到这些现象，大概率是缓存问题：
-
Failed to download vendor/package: The archive may contain identical file names with different capitalization：旧缓存里 zip 解压后文件名大小写冲突，清缓存再试 - 执行
composer update vendor/package却没拉新 tag：检查该包在缓存里的dist/sha256是否和 packagist 返回的不一致 -
Package operations: 0 installs, 0 updates, 0 removals但你知道有新版本：运行composer show vendor/package看 latest 版本号，再对比composer why-not vendor/package:new-version
缓存本身不记录依赖图谱，只存归档和元数据；真正影响解析逻辑的是 vendor/composer/installed.json 和 lock 文件，这两者不会被 clear-cache 碰到。
