根本原因是 composer.lock 硬编码了 dist url 和 sha256，只要它存在且未变，install 就不会触发新下载；缓存 zip 删除后若 lock 未更新，composer 会因校验失败静默回退或报错。
直接运行 composer clear-cache 不能解决“重复下载”问题——它只会清掉本地 ZIP 和元数据，但 Composer 仍可能复用旧的 composer.lock 或缓存的 packages.json，导致看似重装、实则解压旧包。
为什么 composer clear-cache 后还在重复下载旧包
根本原因不是缓存没清干净，而是 Composer 的行为逻辑被三个文件锁定：
-
composer.lock里硬编码了 dist URL 和sha256值，只要它存在且没变，install就不会触发新下载，哪怕缓存已空 -
vendor/composer/installed.json是当前安装快照，影响show、outdated等命令判断，也会干扰更新路径 -
~/.composer/cache/repo/https---packagist.org/下的packages.json和provider-*.json是远程元数据镜像；不清它，update仍读旧索引，看不到新版本
强制重新下载某个包的最小操作集
别删整个缓存，只动关键位置，避免拖慢后续所有依赖安装：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先定位该包缓存 ZIP：
find $(composer config cache-dir) -name "*vendor-name*package-name*"（Linux/macOS）或 PowerShell 中Get-ChildItem "$env:APPDATA\Composer\Cache\Files" -Recurse -Filter "*vendor-name*package-name*" - 只删匹配的
.zip文件，别碰repo/或vcs/ - 执行
composer remove vendor-name/package-name，再composer require vendor-name/package-name:^x.y.z（显式带版本号） - 加
--no-cache参数可跳过 ZIP 解压路径：composer require --no-cache vendor-name/package-name
CI/CD 中重复下载失败的典型修复链
在 GitHub Actions 或 GitLab CI 里，常见现象是 composer install 卡在 “Downloading …” 却反复拉同一个旧 URL。这不是网络问题，而是缓存和 lock 文件状态不一致：
- 必须加
--no-interaction，否则clear-cache会 hang 住 - 删
vendor/和composer.lock前，先确认是否真要重算依赖树；若只需重拉，保留composer.lock并只删vendor/+composer clear-cache - 镜像配置必须生效：检查
composer config -g repo.packagist输出是否含"type": "composer"和正确 URL（结尾不能少/） - 最后一步加
--force-checksums：composer install --no-cache --force-checksums，让校验失败立刻退出，不写入损坏的vendor/
真正容易被忽略的是 composer.lock 和缓存 ZIP 的耦合关系：删 ZIP 不删 lock，Composer 仍会尝试用 lock 里的 sha256 去校验一个不存在的文件，然后静默 fallback 到更老的缓存或报错。动手前先 composer show vendor-name/package-name 看当前实际版本，比猜更可靠。
