clear-cache 不能解决校验失败，因它不删除已损坏的 ZIP 文件和 composer.lock 中锁定的旧哈希值；需精准删除对应坏 ZIP、清空 vendor 和 composer.lock，并用 --no-cache --force-checksums 重装。
直接运行 composer clear-cache 不能解决“校验失败”类错误，因为它不清理已损坏的 ZIP 文件与硬编码在 composer.lock 中的哈希值——这两者才是校验失败的根源。
为什么 clear-cache 后仍报 Corrupted zip file？
Composer 校验失败不是因为缓存“太多”，而是因为：~/.composer/cache/files/ 下某个 ZIP 文件实际损坏（如下载中断、磁盘写异常），而 composer.lock 中记录的 dist.sha256 值仍指向这个坏文件。执行 clear-cache 后，Composer 默认仍会复用旧缓存路径中的同名 ZIP，并再次校验失败，不会自动重下。
- 错误典型输出：
Corrupted zip file: monolog/monolog、Failed to extract vendor/symfony/console -
clear-cache会删掉files/目录，但若系统权限或进程占用导致部分 ZIP 未被真正删除，残留坏包仍在 - 更隐蔽的问题：
composer.lock没更新，它锁死的是旧哈希，哪怕你手动下载了新 ZIP，Composer 也拒绝使用
定位并删除具体损坏的 ZIP 文件
别全量清缓存。先从错误日志中精准揪出问题包，再删对应 ZIP：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer install -v，盯住末尾几行，找Extracting或Downloading后紧跟着的包名（如symfony/console） - 查缓存根目录：
composer config --global cache-dir（Linux/macOS 通常是~/.composer/cache，Windows 是%APPDATA%\Composer\Cache） - 进
files/子目录，模糊搜索：
Linux/macOS：ls -l *symfony*console*.zip
Windows PowerShell：Get-ChildItem "$env:APPDATA\Composer\Cache\Files" -Recurse -Filter "*console*.zip" - 只删匹配到的 ZIP，**不要动
repo/和vcs/**——它们不参与解压，删了反而拖慢首次 update
必须同步清理 composer.lock 和 vendor/
删 ZIP 只是第一步。只要 composer.lock 还在，Composer 就坚持用里面写的旧哈希去比对——哪怕你刚下了个新 ZIP，它也认为“不匹配”，直接拒装。
- 备份：
cp composer.lock composer.lock.bak（Linux/macOS）或copy composer.lock composer.lock.bak（Windows） - 彻底清空：
rm -rf vendor composer.lock（Linux/macOS）或rd /s /q vendor & del composer.lock（Windows） - 重装时加两个关键参数：
composer install --no-cache --force-checksums
—--no-cache强制跳过本地 ZIP，直连镜像源下载新包
—--force-checksums让校验失败立刻退出，避免污染vendor/或静默降级
CI 环境中特别容易漏掉的关键点
CI 构建里常默认挂载缓存卷，但 composer.lock 若含旧源地址（比如公司内网镜像失效后仍写 https://mirror.internal），重装永远走错路——--no-cache 也救不了。
- 确认镜像配置真实生效：
composer config -g repo.packagist输出必须含有效 URL，且键名是repo.packagist（不是repos.packagist，多一个 s 就无效） - CI 脚本中，
composer install前务必确保composer.lock是最新生成的，或干脆用composer update --lock动态刷新 - 如果用 Docker，检查基础镜像是否预装了旧版 Composer 或残留
~/.composer/config.json，它可能覆盖全局镜像设置
最常被忽略的其实是 composer.lock 的存在本身——它不像缓存那样“看得见摸得着”，但却是校验链条里最刚性的一环。删 ZIP 不删 lock，等于换轮胎不松螺丝。
