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 Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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。