必须同步清理三处：先 composer clear-cache，再删 ~/.composer/cache/repo/https---packagist.org/、vendor/composer/installed.json 和 composer.lock；否则 update 仍复用旧元数据与版本锁定。
直接删三处，composer clear-cache只是第一步，不删完根本没用。
为什么composer clear-cache后update还是拉不到新版本
它只清~/.composer/cache/files/（ZIP包）和部分repo/子目录，但真正决定“有哪些新版本”的元数据——比如packages.json和provider-*.json——全存在~/.composer/cache/repo/https---packagist.org/里，这个目录clear-cache默认跳过。
更麻烦的是，vendor/composer/installed.json记录着当前已装包的精确版本，composer.lock则硬编码了每个包的dist.sha256和source.reference。只要它们还在，update就认为“状态一致”，压根不会去查远端。
- Linux/macOS：运行
composer clear-cache→rm -rf $(composer config --global cache-dir)/repo/https---packagist.org/→rm -f vendor/composer/installed.json composer.lock - Windows（PowerShell）：先
composer clear-cache，再Remove-Item -Recurse -Force "$env:APPDATA\Composer\Cache\repo\https---packagist.org\"，最后删vendor\composer\installed.json和composer.lock - 删
composer.lock后必须跑composer update，不能直接install，否则会按composer.json重新解析，可能引入意外升版
删完怎么确认元数据真刷新了
别信“执行完就 OK”，要亲眼看到 Composer 重走网络请求。最可靠的方式是：
运行composer update --dry-run -v，盯紧输出里有没有Downloading https://packagist.org/packages.json。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
如果只看到Reading /path/to/cache//packages.json，说明https---packagist.org/目录没删干净，得重来。
- 私有仓库或镜像失效时，也要同步删对应目录，比如
https---mirrors.aliyun.com---composer/或https---my-private-repo.com/（注意/被转义为-） - 若项目设了
"minimum-stability": "stable"，而目标包只发了dev或beta，那即使元数据刷新了也看不到——这不是缓存问题，是约束本身在过滤
要不要顺手清vcs/目录
要，而且建议优先清——它不参与update的元数据解析，但单个 Git 裸仓库常占 300–800 MB，还容易耗尽 inode。删了下次需要时自动重建，完全安全。
composer clear-cache默认跳过vcs/，所以得手动补一刀：
- Linux/macOS：
rm -rf $(composer config --global cache-dir)/vcs - Windows（CMD）：
rd /s /q "%APPDATA%\Composer\Cache\vcs" - CI 或小磁盘机器可永久禁用：
composer config --global cache-vcs false，后续 Git 包全走--prefer-dist安装
最容易被忽略的是composer.lock。很多人删了缓存、删了installed.json，却留着它，结果update依然原地不动——因为 Composer 认为“锁文件没变，就不需要动版本”。
