composer缓存是否有效，取决于update时是否真实发出http get请求获取元数据；用composer update --dry-run -v查看日志，出现downloading即缓存刷新成功，仅reading本地路径则未真正刷新。
composer update --dry-run -v 看日志里有没有 Downloading
缓存是否“有效”，本质是 Composer 有没有真去远程拉新元数据。最直接的判断方式，就是用 composer update --dry-run -v 观察输出日志：
- 如果看到
Downloading https://mirrors.aliyun.com/composer/packages.json（或你配置的镜像地址），说明元数据缓存已失效，正在重载——这是“缓存刷新成功”的铁证 - 如果只显示
Reading /path/to/cache/repo/https---mirrors-aliyun-com/packages.json，哪怕路径正确，也代表它还在读本地旧快照，缓存没真正刷新 -
--dry-run不改任何文件，-v才暴露关键网络行为；不加-v就等于盲操作
为什么 composer clear-cache 不等于缓存刷新成功
composer clear-cache 只删磁盘文件，但 Composer 在某些场景下仍会复用内存中残留的索引引用，尤其在 CI 容器、PHP-FPM 子进程复用、或连续执行多个命令时。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 它不强制丢弃
vendor/composer/installed.json和composer.lock中隐含的版本约束，update 仍可能“推测”出旧版本 - 它不触发对镜像源
packages.json的重新 GET 请求，只是清空了本地缓存目录里的副本 - 真正要绕过所有启发式推导，必须用
composer update --refresh（Composer ≥ 2.5）
检查镜像源是否生效，否则刷新也是白刷
缓存再干净，如果镜像源配错了，--refresh 或 --dry-run -v 拉的还是过期或不可达的元数据。
- 运行
composer config --global repos.packagist查全局镜像：输出应为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}（注意是repos.packagist，不是repo.packagist，单复数错就无效） - 项目级配置优先级更高，检查
composer.json里是否有"repositories"字段覆盖了全局设置 - 如果
composer update --refresh -v日志中出现的是https://packagist.org/packages.json，说明镜像根本没生效，得先修配置
verify-checksums 不是用来查缓存的，别误用
COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict 校验的是 vendor/ 下文件和 composer.lock 中记录的 dist.sha256 是否一致，和“update 缓存是否有效”完全无关。
- 它不碰
~/.composer/cache/，也不看元数据是否最新 - 它只回答“我当前 vendor 里的文件有没有被篡改或损坏”，不是“我能不能装到 2.1.0”
- 如果
composer update后立刻跑这个命令报 mismatch，大概率是镜像源替换了 dist 包但没同步原始哈希，或者你用了--prefer-source
