直接结论：用 composer update --refresh，它是 Composer ≥2.5 唯一支持的原子化刷新+更新操作，强制丢弃旧元数据、重拉完整索引并重算依赖，而非清缓存后更新。
直接结论：用 composer update --refresh，别试其他组合。 它不是“清缓存再更新”，而是强制丢弃旧元数据、重新拉取完整索引后立刻重算依赖——这是 Composer 官方唯一支持的原子化刷新+更新操作，且只在 ≥2.5 版本可用。
为什么 composer clear-cache && composer update 不可靠
这个组合看似合理，实则存在两个隐蔽断层：
- clear-cache 只删磁盘文件，但 Composer 进程内可能仍缓存着旧的
packages.json或 provider 数据（尤其在 CI 的复用容器或 PHP-FPM 持久化进程中） - 即使缓存目录为空，
composer update默认仍会尝试从vendor/composer/installed.json或composer.lock“启发式推导”该拉什么，不一定触发完整远程索引拉取
--refresh 强制绕过所有这些路径：它明确告诉 Composer “别猜，去镜像源拿最新 packages.json”，连 --no-cache 都做不到这点。
执行前必须确认的三件事
否则 --refresh 会白跑甚至出错：
- 运行
composer --version，确保 ≥ 2.5；若低于，先composer self-update - 检查当前镜像源：
composer config repo.packagist.org.url，配错会导致刷新一堆无用数据，甚至被限流 - 确认你真需要刷新——日常小修小补用
composer update vendor/package-name更安全；--refresh是为解决“明明有新包却检测不到”“锁文件和源索引严重脱节”这类场景准备的
--refresh 和 --no-cache 的本质区别
两者常被混淆，但行为完全不同：
-
--refresh：只刷新元数据（packages.json、provider-*.json），不重下 ZIP 包，快且安全；它重载索引后做全新依赖解析，完全无视composer.lock的旧约束 -
--no-cache：跳过所有缓存（包括已下载的包 ZIP），每次都要重新下载，流量大、耗时长；但它不刷新元数据，仍可能基于过期索引做错误判断 - 验证是否真刷新：加
-v参数运行，日志里必须出现Downloading https://mirrors.aliyun.com/composer/packages.json这一行
真正容易被忽略的是：刷新动作本身不保证升级成功。如果镜像源配置错误、PHP 版本不满足新包要求、或 composer.json 中的约束太松（比如 "^7.0" 允许升到 7.9），--refresh 后仍可能拉来不兼容版本——它只管“最新可用”，不管“是否适合你”。所以刷新之后，务必结合 composer outdated --direct 看哪些包动了、为什么动、有没有 [security] 标记。
