composer update --refresh是唯一可靠的元数据刷新方式，强制丢弃本地索引并从镜像源重拉packages.json等元数据，不重下ZIP包，要求Composer≥2.5，低于该版本会报错Unrecognized option: --refresh。
composer update --refresh 是唯一可靠的元数据刷新方式
低于 Composer 2.5 的版本不支持 --refresh，会直接报错 Unrecognized option: --refresh。运行 composer --version 确认版本，过旧就先执行 composer self-update。
该命令不是“预刷新缓存”，而是把元数据刷新和依赖解析合并为一次原子操作：它强制丢弃本地 ~/.composer/cache/repo/https---packagist.org/packages.json 和所有 provider-*.json，重新从镜像源拉取完整索引，再做解析。这意味着它不依赖 composer.lock 中的旧约束去“猜”该更新什么。
-
--refresh只刷新元数据，不重下 ZIP 包，所以快且安全 - 加
-v可验证是否真刷新：日志里必须出现Downloading https://mirrors.aliyun.com/composer/packages.json（地址取决于你当前配置的镜像） - 别在没配国内镜像时用
--refresh，否则刷新的是慢速源，反而更卡
别再无脑 clear-cache + update
composer clear-cache 只删磁盘文件，但 Composer 进程内可能仍持有旧元数据引用——尤其在 CI 环境或 PHP-FPM 复用场景下，clear-cache 后立即 update 仍可能走缓存路径。
更关键的是：clear-cache 不动 vendor/composer/installed.json 和 composer.lock，而 Composer 默认会基于这两个文件“启发式推导”该拉哪些包，不一定触发远程索引重载。
- 想彻底重来，得手动删掉
~/.composer/cache/repo/https---packagist.org/目录 - 同时删
vendor/composer/installed.json和composer.lock，否则update仍受锁定约束 - 验证是否成功：跑
composer update --dry-run -v，看到Downloading行才算真正刷新
加速 update 的实际可操作组合
单纯清缓存或换源都不够，要配合使用场景调整参数。以下组合经实测在 Laravel 或大型 Symfony 项目中效果明显：
- 生产环境部署：用
composer install --no-dev --prefer-dist --optimize-autoloader，跳过 dev 包、强制 dist、生成类映射 - 只想更新单个包：用
composer update vendor/package-name，不带--with-dependencies就不会递归更新其子依赖 - CI 流水线中避免缓存污染：加
--no-cache，但它会跳过所有缓存（包括已下载 ZIP），仅适合带高速缓存层的构建环境 - 长期未更新的老项目：先
composer update --dry-run看变更范围，再决定是否加--refresh
缓存配置不当反而拖慢速度
很多人以为缓存越大越好，其实 cache-files-maxsize 设太高（比如 2G+）会导致 Composer 垃圾回收变慢；cache-files-ttl 设太短（如 1 天）会让频繁使用的包反复重下。
推荐值（适用于大多数团队项目）：
-
cache-files-maxsize:"800MiB"—— 足够覆盖主流框架+生态包，又不至于 GC 卡顿 -
cache-files-ttl:604800（7 天）—— 平衡新鲜度与复用率，避免每周都重下 Laravel 主包 - 私有仓库务必单独配
repositories并设cache-ttl，否则默认沿用全局 TTL，容易错过内部发布的 hotfix
metadata 缓存的刷新时机和位置，比包文件缓存更难察觉也更容易出错——它不报错，只是默默给你旧版本。每次怀疑版本滞后，第一反应不该是删 vendor，而是确认 --refresh 是否生效、镜像源是否正确、packages.json 是否真被重拉。
