直接删整个vendor/非必要，应先根据错误信息定位损坏包（如Failed to extract vendor/symfony/console），再进~/.composer/cache/files/手动删除对应ZIP文件，最后用composer install --no-cache --force-checksums重装。
直接删整个 vendor/ 是最粗暴的解法，但多数时候没必要——损坏往往只集中在某个包，手动定位并清理对应缓存文件，再重装，更快更稳。
怎么确认是哪个包损坏了？
错误信息里通常带具体路径，比如 Failed to extract vendor/symfony/console 或 Corrupted zip file: vendor/monolog/monolog。这是关键线索，别跳过。
- 运行
composer install -v或composer update -v，盯住最后一段输出，找Extracting或Downloading后跟失败提示的那一行 - 如果报
unable to open archive或Content-Length mismatch，基本可断定是 ZIP 下载不完整，不是代码逻辑问题 - 别信“Class not found”就去改 autoload —— 先查是不是
vendor/some/package目录下空着、或只有composer.json没有 PHP 文件
怎么精准删除损坏包的缓存？
Composer 不会自动覆盖已损坏的缓存 ZIP，必须手动清掉它，否则重装时仍会拉那个坏包。
- 先查缓存位置：
composer config cache-dir（通常是~/.composer/cache/files/） - 进该目录，用文件名模糊匹配：
ls -l symfony/console-*.zip或find . -name "*monolog*zip" - 删掉对应 ZIP：
rm -f ~/.composer/cache/files/symfony/console-5.4.32.zip（版本号要对得上） - Windows 用户用 PowerShell：
Remove-Item "$env:APPDATA\Composer\Cache\Files\symfony\console-*.zip"
为什么换镜像源经常没用？
换镜像本身不增加校验能力，所有官方镜像（阿里云、腾讯云等）都同步 Packagist 的 dist.sha256 值，校验逻辑完全一致。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 真正起作用的是强制校验失败时中断：
composer install --force-checksums - 这个参数必须每次显式带上，不会写入配置，也不会继承到 CI 环境
- 镜像 URL 必须以
/结尾，少一个斜杠就会拼出/packages.json→ 404，命令不报错但配置静默失效 - 项目根目录若有
composer.json里的repositories字段，全局镜像配置会被彻底忽略
重装时该用 install 还是 update？
优先用 composer install --no-cache --force-checksums，而不是 update。
-
install严格按composer.lock还原，不触发依赖重算，风险更低 -
--no-cache跳过本地缓存，避免从 ~/.composer/cache/files/ 里捞旧包 -
--force-checksums让校验失败时立刻退出，不尝试解压损坏 ZIP，防止污染vendor/ -
update容易 fallback 到 source（git clone），可能暴露凭据、卡在私有仓库、或拉到不稳定分支
最容易被忽略的是：缓存目录里同一个包可能有多个 ZIP（不同版本），删错一个不影响，但漏删一个就会反复踩坑；--force-checksums 不解决网络问题，但它能让你第一时间知道哪一步坏了，而不是等到运行时报 Class not found 才回头排查。
