Composer update默认复用缓存ZIP且不校验远程变更，损坏ZIP导致“Corrupted zip file”错误；必须定位删除对应ZIP、同步清理composer.lock和repo元数据，或直接使用composer update --refresh（≥2.5）强制刷新索引。
composer update 默认复用缓存中的 ZIP 文件
它不会重新下载已存在的包 ZIP，哪怕远程版本号变了、SHA256 校验值已不匹配。Composer 只比对 dist.sha256 字段是否与本地缓存 ZIP 的哈希一致；一致就直接解压，跳过网络请求和校验逻辑。
这意味着：如果缓存 ZIP 损坏（如下载中断、磁盘写异常），composer update 仍会尝试解压它，报 Failed to extract 或 Corrupted zip file 错误——这不是网络问题，是缓存文件本身坏了。
- 运行
composer clear-cache会清空整个~/.composer/cache/files/，但 CI 环境或某些容器中可能因权限/挂载限制未真正生效 - 更精准的做法是定位到具体包名，再删对应 ZIP：
ls -l ~/.composer/cache/files/*vendor*package*.zip（Linux/macOS）或 PowerShell 中用Get-ChildItem "$env:APPDATA\Composer\Cache\Files" -Filter "*package*.zip" - 删 ZIP 后若仍失败，大概率是
composer.lock里记录的dist.sha256和新下载内容不一致，必须同步删掉composer.lock和vendor/再重装
metadata 缓存滞后导致“看不到”新 ZIP
composer update 是否去拉新版 ZIP，取决于它“知不知道有新版”。而这个“知道”，靠的是 ~/.composer/cache/repo/https---packagist.org/ 下的 packages.json 和 provider-*.json。这些文件过期了，Composer 就根本不会发起对新 ZIP 的请求。
比如某包发了 2.1.0，但本地 repo 缓存还停留在 2.0.3 的索引，那 composer update 就只会查 2.0.3 对应的 ZIP URL，自然拉不到 2.1.0 的包。
-
composer clear-cache不强制刷新repo/目录下的 metadata，它默认跳过该路径 - 必须手动删掉整个子目录：
rm -rf ~/.composer/cache/repo/https---packagist.org/（Windows 对应%APPDATA%\Composer\Cache\repo\https---packagist.org\） - 删完后跑
composer update --dry-run -v，看到Downloading https://packagist.org/packages.json才算真正触发元数据重载
composer update --refresh 是唯一可靠的强制刷新方式
它不是“先清缓存再 update”，而是把元数据刷新和依赖解析合并成原子操作：丢弃所有本地 metadata 快照，直连镜像源拉最新 packages.json，再基于它做完整依赖求解。低于 Composer 2.5 的版本不支持该参数。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
相比 clear-cache + update，--refresh 绕过了三个常见断层：内存残留引用、installed.json 启发式推导、composer.lock 的旧约束干扰。
- 执行前务必确认版本：
composer --version；如过旧，先composer self-update - 加
-v可验证效果：日志中必须出现Downloading https://...，不能只有Reading /path/to/cache/... - 它只刷新 metadata，不重下 ZIP 包，所以快；但前提是镜像源配置正确，否则刷新的是错误地址
删缓存不删 lock 文件等于白干
composer.lock 不是缓存，但它是 composer update 的决策锚点。只要它存在且未被修改，Composer 就认为“当前锁定状态有效”，不会主动升级任何包——哪怕 metadata 已刷新、ZIP 已更新、composer.json 里写了 "^2.0"。
很多人清理了所有缓存目录，却留着 composer.lock，结果 update 依然显示 Nothing to install or update。这不是 bug，是设计如此。
- 想让
update真正拉新版本，必须删掉composer.lock（或至少用composer update vendor/package显式指定目标） - 删
composer.lock后别直接composer install，否则会按composer.json重新解析全部依赖，可能引入意外升版 - 最稳妥流程是：删
composer.lock→ 删vendor/composer/installed.json→ 运行composer update --refresh
真正卡住更新的从来不是 ZIP 文件本身，而是 metadata 索引和 lock 文件构成的“认知闭环”。一旦其中一环滞后，Composer 就会坚定地复用旧世界里的所有东西，包括损坏的 ZIP。
