答案：composer install --no-cache 是唯一绕过损坏 ZIP 的强制重拉手段，需配合 clear-cache 和 CI/CD 中 COMPOSER_CACHE_DIR=/dev/null 使用，它跳过所有本地缓存查找，直接向镜像源发起新 HTTP 请求，但不改变 composer.lock 解析逻辑。
Composer install --no-cache 是唯一绕过损坏 ZIP 的强制重拉手段
缓存里的 ZIP 文件一旦校验失败（Failed to extract vendor/package），Composer 不会自动重试或替换，而是反复读取那个坏包直到报错。只删 vendor/ 没用，因为 composer install 默认仍从 ~/.composer/cache/files/ 读取 ZIP。
必须显式禁用缓存逻辑：
• 运行 composer clear-cache 清空旧缓存
• 再执行 composer install --no-cache，它跳过所有本地 ZIP 查找，直接向镜像源发起新 HTTP 请求
• CI/CD 中还要加 COMPOSER_CACHE_DIR=/dev/null 防止挂载卷残留干扰
注意：--no-cache 不影响 composer.lock 解析，只阻断 dist 包的缓存路径
损坏 ZIP 的真实来源是镜像源本身，不是网络中断
错误如 Content-Length mismatch 或 unable to open archive 表明下载完成的 ZIP 文件 SHA256 校验失败——这是 Composer 在解压前做的硬校验，失败即中止，不写入 vendor/。
常见原因：
• 镜像节点同步滞后，返回了旧版 ZIP 但 composer.lock 记录的是新版哈希
• 某些地域节点（如阿里云华东 CDN）回源抖动，返回截断或乱码响应
• 镜像站已下线（如 packagist.phpcomposer.com），HTTP 302 跳转到不可控页面，返回 HTML 而非 ZIP
验证方式：手动 curl -I https://mirrors.aliyun.com/composer/p2/monolog/monolog.json，看是否返回 200 OK + application/json
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
镜像配置失效会让 ZIP 损坏更难定位
你以为在走国内镜像，实际请求发到了 packagist.org，错误日志里却不会提示“正在从 packagist.org 拉取”。
关键检查点：
• 运行 composer config -g repo.packagist，输出必须是完整 HTTPS URL（结尾带 /），否则走默认源
• grep -A 5 '"repositories"' ./composer.json，项目级 "repositories" 会完全屏蔽全局镜像配置
• composer install -vvv 时盯第一行日志：Downloading https://...，确认域名是否匹配你设的镜像地址
Windows 用户注意缓存路径是 %APPDATA%\Composer\Cache，不是 ~/.composer/cache
verify-checksums --strict 才能发现已安装包是否被篡改
composer install --verify 只在校验下载来的 ZIP 是否匹配 composer.lock 中的 dist.sha256；而 verify-checksums --strict 是唯一读取磁盘、重新计算 vendor/{package}/ 目录实际哈希并比对的命令。
启用方式：
• 必须设置环境变量 COMPOSER_EXPERIMENTAL=1
• 运行 COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict
• 不加 --strict 时即使校验失败也只警告且返回 0，CI 会误判成功
注意：verify-checksums 不校验 vendor/composer/autoload_*.php 等生成文件，但会扫到你手动改过的 vendor/autoload.php，导致失败
