直接结论：不是缓存没清干净，而是只清了composer clear-cache能碰的基础层，真正卡住更新的是packages.json索引、composer.lock和installed.json三处未同步刷新。
直接结论：不是缓存没清干净，而是你只清了composer clear-cache能碰的那一层——真正卡住更新的，是packages.json索引、composer.lock和installed.json这三处没同步刷新。
为什么composer clear-cache后还是拉不到新版包
Composer 的依赖信息分四层：远程元数据 → 本地 repo 缓存 → composer.lock约束 → vendor/composer/installed.json快照。其中任意一层滞后都会让composer update“看不见”新版本。
-
composer clear-cache只删~/.composer/cache/files/（ZIP 包）和部分repo/子目录，但不会清掉~/.composer/cache/repo/https---packagist.org/下的主索引文件（比如packages.json），它可能还在用几小时前的 provider 列表 -
composer.lock里硬编码了每个包的dist.sha256和version，只要它存在，composer install就绝不会升版，哪怕远程已发v3.0.0 -
vendor/composer/installed.json是当前安装状态的快照，composer show读的就是它；若你手动删过某些vendor子目录但没重装，这里就变成“幻影包”，composer depends会误判依赖链
精准清理 metadata 缓存的三步操作
遇到“明明发了新版，composer update却不出现”，必须同步清理这三处，缺一不可：
- 运行
composer clear-cache清基础缓存 - 手动删掉
~/.composer/cache/repo/https---packagist.org/（Linux/macOS）或%APPDATA%\Composer\Cache\repo\https---packagist.org\（Windows）——这是最常滞后的元数据根目录 - 删掉
vendor/composer/installed.json和composer.lock；注意：composer.lock删完后必须跑composer update，不能直接install，否则会按composer.json重新解析，可能引入意外升版
验证是否生效：加--dry-run -v运行composer update，看到Downloading https://packagist.org/packages.json或Curl Http日志，说明 metadata 已走网络重载，不是复用旧缓存。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
镜像失效导致的“假缓存错误”
很多报错看起来像缓存问题，其实是镜像源配置失效——packagist.phpcomposer.com和packagist.laravel-china.org已下线，但composer config -g repo.packagist仍输出这些地址，就会静默失败或返回 404。
- 先确认镜像是否有效：
composer config -g repo.packagist，若含已停用域名，立刻切换到https://mirrors.aliyun.com/composer/（推荐）或https://mirrors.tencent.com/composer/ - 切镜像后别急着
update：旧composer.lock里还记着失效 URL，得先删vendor/和composer.lock，再跑composer install（不是update）重建环境 - 注意项目级配置覆盖：若项目
composer.json里有repositories字段，它会无视全局镜像设置，必须同步改掉
依赖冲突被误判为缓存问题
报Your requirements could not be resolved时，90% 不是缓存问题，而是约束冲突。盲目清缓存只会掩盖真因。
- 立刻执行
composer why-not vendor/package:version（如composer why-not php:8.3），输出第一行就是阻断源头 - 若第一行是
Root package requires php ^7.4，说明composer.json里写的 PHP 约束太窄；若是某个插件（如spatie/laravel-backup v8.0.0 requires php ^8.0），就得查它是否有兼容新版的 release - 别漏掉
require-dev：比如phpunit/phpunit常通过sebastian/exporter锁死symfony/console到 5.x，而新框架要 6.x，这种间接冲突必须靠why-not暴露
最易被忽略的点：团队协作中手动缝合composer.lock的冲突标记（如>>>>> HEAD）会导致content-hash不匹配、同包在packages和packages-dev中版本不一致等逻辑错误——这种损坏无法靠清缓存修复，只能删 lock + vendor 重算。
