清理缓存不能解决真正的依赖版本冲突，仅能修复缓存污染导致的哈希校验失败等问题；需同步删除 composer.lock、vendor/、元数据缓存，并用 --no-cache --prefer-dist 重装。
清理缓存本身不能解决依赖版本冲突，它只解决因缓存污染导致的“假性冲突”或哈希校验失败。 真正的版本冲突（如 monolog/monolog 被两个包分别要求 ^1.0 和 ^3.0）必须靠调整约束、升级包或重构依赖关系来解，缓存再干净也绕不开语义化版本的逻辑矛盾。
为什么清缓存后 still 有 hash verification failed
典型现象是执行 composer install 报错：hash verification failed，但你明明刚运行过 composer clear-cache。这是因为：
-
composer.lock文件没删——它记录着旧版本包的dist.sha256，而镜像源已更新包内容，哈希对不上 -
vendor/没删——composer install会跳过已存在目录，不重新校验 -
~/.composer/cache/repo/https---packagist.org/下残留的 packages.json 快照没手动清，Composer 仍会读取过期元数据 - 私有仓库缓存藏在
~/.composer/cache/repo/https---your-private-repo.com/，composer clear-cache默认不碰它
必须同步执行的四步清理组合
仅靠 composer clear-cache 是不够的。要让 Composer 从零开始解析，得做这四件事（顺序不能乱）：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 备份并删除
composer.lock：mv composer.lock composer.lock.bak - 彻底清空
vendor/：rm -rf vendor/ - 手动清理元数据缓存：
rm -rf ~/.composer/cache/repo/https---packagist.org/（国内镜像同理，如https---mirrors.aliyun.com） - 重装时禁用缓存并强制走 dist：
composer install --no-cache --prefer-dist
什么时候该怀疑是缓存问题而非真冲突
如果你遇到以下任意一种情况，优先按缓存污染处理，而不是立刻改 composer.json：
- 切换 PHP 版本（如从 8.1 升到 8.3）后
composer update报错，但composer why显示所有包都支持新版本 - 刚切回官方源（
composer config -g repo.packagist composer https://packagist.org/），却仍提示某包 “not found”，而该包在 packagist.org 上明明存在 -
composer diagnose提示 “The configured CA bundle does not exist” 或 “You are running Composer with SSL/TLS protection disabled”，但证书文件路径没错——很可能是缓存里混了旧 CA 元数据 - 同一份
composer.json在 CI 和本地行为不一致，且 CI 使用了--no-cache
真正难啃的是跨 major 版本的间接依赖冲突，比如 symfony/console v5 和 v6 同时被不同子依赖拉入。这种问题不会因清缓存消失，得靠 composer why 定位源头，再决定是升级、降级还是加 replace 规则。缓存只是第一道过滤网，别让它替真正的版本逻辑背锅。
