composer install无自修复机制，仅严格按composer.lock逐条还原：ZIP损坏、权限不足或磁盘满时立即报错中断，不重试、不降级、不忽略；失败后需人工清理缓存、删除损坏包或修正环境。

composer install 没有自修复机制。它不会自动补全缺失文件、跳过错误、重试失败解压，更不会根据报错反向修正 composer.lock 或重写依赖约束。

它只做一件事：严格按 composer.lock 文件逐条还原。只要 lock 文件存在且格式合法，它就照单下载、校验、解压、写入 vendor/；一旦中间某步失败（比如 ZIP 损坏、权限不足、磁盘满），就立刻中断并报错——不重试、不降级、不忽略。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

composer install 失败时为什么有人觉得它“能自愈”？

常见错觉来源：

• 看到网络超时后命令继续往下走 → 实际是 Composer 内置的 HTTP 重试逻辑在起作用，但那属于 CurlDownloader 层，和 install 命令本身无关
• 二次运行 composer install 成功了 → 很可能是因为上次失败后残留了部分 vendor/ 目录，这次走了“增量安装”路径，而非真正重来
• 清了缓存再跑就通了 → 是 --no-cache 绕过了损坏的 ZIP，不是 install 主动识别并丢弃了它

哪些问题 composer install 确实完全不管？

• composer.lock 被手动改过 → 报 lock file is not up to date，拒绝执行，不提示怎么修
• vendor/bin/phpunit 没执行位 → 安装完仍是 -rw-r--r--，不 chmod，不警告
• vendor/symfony/console 目录下 PHP 文件为空 → 不校验文件内容完整性，只校验 ZIP 的 SHA256 和解压是否成功
• php-zip 扩展未启用 → 直接抛出 ZipArchive::extractTo() failed，不 fallback 到其他解压方式

真正需要人工干预的典型场景

• 错误信息里带 Failed to extract → 先去 ~/.composer/cache/files/ 找对应 ZIP 删掉，再加 --no-cache --force-checksums 重装
• 报 No composer.lock file present → 不是让你“再试一次”，而是必须先用 composer update 生成它
• vendor/ 下某些包目录存在但内容为空 → install 不会重新拉取，得手动删掉那个子目录再跑一遍

最常被忽略的一点：当 vendor/ 已存在但状态混乱时，composer install 默认不清理旧文件，也不会验证现有文件是否匹配 lock 中的哈希值——它只管“没下载的补上”，不管“已有的对不对”。