composer依赖信息错误需分层排查：远程元数据、本地repo缓存、composer.lock约束、vendor快照四层任一滞后均导致更新失败；clear-cache仅清基础缓存，须同步清理repo索引、lock文件及installed.json，并验证镜像配置是否真正生效。
缓存清理不能解决所有依赖信息错误，关键得先分清是哪一层缓存出了问题——composer clear-cache只动本地归档和元数据，但真正卡住更新的，往往是 composer.lock 锁定、vendor/composer/installed.json 快照过期，或远程仓库索引（如 ~/.composer/cache/repo/https---packagist.org/）没刷新。
为什么删了缓存还是拉不到新版包
Composer 的“依赖信息”不是单一层级，而是四层叠加：远程仓库元数据 → 本地 repo 缓存 → lock 文件约束 → vendor 安装快照。其中任意一层滞后，都会导致 composer update 看不到新版本。
-
composer clear-cache只清~/.composer/cache/files/（ZIP 包）和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会误判依赖链 - 私有仓库或 Satis 源若启用了 TTL 或 CDN 缓存，
clear-cache根本不触碰那层，得等上游刷新或加--no-cache强制绕过
精准清理 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
容易被忽略的镜像配置陷阱
即使清了所有缓存，如果镜像没真正生效，请求仍会 fallback 到 packagist.org，导致元数据始终滞后。验证是否接管成功，不能只看命令有没有报错：
- 检查配置键名：必须是
repo.packagist，写成repos.packagist（多一个 s）就完全无效 - type 值必须显式为
composer，漏掉这行，Composer 当作普通 HTTP 源处理，不走包索引协议 - URL 结尾不能带斜杠：
https://mirrors.aliyun.com/composer/是错的，正确是https://mirrors.aliyun.com/composer - 执行后立刻用
composer config --global --list | grep packagist确认输出里有repo.packagist.type=composer和对应 URL
CI 环境中尤其危险：Docker 构建时用 root 写的全局配置，和非 root 用户运行的 composer update 可能读取不同配置层级，--global 不一定生效。
删 vendor 不等于解决依赖信息错误
很多人以为 rm -rf vendor + composer install 就能重来，但只要 composer.lock 还在，安装行为就完全受其控制——它不查远程，只校验本地缓存 ZIP 是否匹配 lock 里的哈希值。所以：
- 若你只想升级某个包，别删
composer.lock，改用composer update vendor/package-name --with-dependencies - 若要彻底重算依赖树，必须删
composer.lock，再composer update；install永远只是“按 lock 执行” -
vendor/目录本身不存依赖逻辑，它只是结果；真正决定“该装什么”的，永远是composer.lock和远程仓库的 packages.json 元数据
最隐蔽的问题是：你删了缓存、删了 vendor、甚至换了镜像，但 composer.lock 里还写着旧的 dist.url（比如指向已下线的私有源），这时 Composer 会静默 fallback 到 packagist.org，且不提示，直到某天那个包在官方源也不存在了才报错。
