Composer update卡在“Resolving dependencies”或报错找不到包，主因是本地vendor/与composer.lock不一致或镜像元数据缓存滞后；需先clear-cache、验证镜像配置、必要时删除vendor和composer.lock后执行install而非update。

为什么 composer update 会卡在 “Resolving dependencies” 或报错找不到包？

多数情况不是网络问题，而是本地 vendor/ 和 composer.lock 状态不一致，或镜像源缓存了旧的包元数据（尤其是切换过镜像源后）。Composer 中文镜像（如阿里云、腾讯云）本身不存包文件，只代理 packagist.org 的元数据，但本地 composer cache 可能残留失效索引。

• 先清空 Composer 全局缓存：composer clear-cache
• 确认当前镜像源是否生效：composer config -g repo.packagist，应返回类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
• 如果之前用过 composer config -g repos.packagist composer https://packagist.org 手动切回过官方源，必须再切回来，否则 clear-cache 也无效

删 vendor/ 和 composer.lock 前必须确认的三件事

这不是“重装就能好”的操作，删错会导致依赖爆炸或版本倒退。重点不是删，而是删得干净且可控。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• vendor/ 必须完整删除（包括隐藏文件如 .htaccess 或 .gitignore），建议用 rm -rf vendor/（Linux/macOS）或 rmdir /s vendor（Windows cmd）
• composer.lock 可以删，但删之前运行 composer show --tree 记下关键包（如 laravel/framework、symfony/console）的大致版本范围，避免更新后跳版破坏兼容性
• 检查项目根目录是否有 composer.json 的 config.platform 字段，它会强制锁定 PHP 或扩展版本，若与当前环境不符，install 会失败且不提示具体原因

composer install 和 composer update 到底该用哪个？

绝大多数“清理冗余包”场景应该用 composer install，而不是 update。后者会无视 composer.lock 重新解析所有依赖树，容易引入不兼容变更；前者才真正按锁文件精确还原。

• 如果 composer.lock 存在且你没改过 composer.json：直接 composer install —— 它会清理 vendor 并按 lock 文件安装，冗余包自然消失
• 如果 composer.lock 已删，但你要保持历史版本：先 git checkout composer.lock（如果有 Git），再 install
• 只有明确要升级某包（如修复安全漏洞）时才用 composer update vendor/package-name，不要裸跑 composer update

中文镜像下仍出现 “Could not find package” 的真实原因

不是镜像挂了，大概率是包名拼写错误、包已废弃、或该包根本不在 packagist.org 上（比如私有 Git 仓库未配置 repositories）。

• 查包是否存在：打开浏览器访问 https://packagist.org/packages/{包名}，例如 https://packagist.org/packages/guzzlehttp/guzzle
• 检查大小写：Composer 包名严格区分大小写，monolog/monolog 对，Monolog/Monolog 错
• 私有包必须在 composer.json 显式声明：

  "repositories": [
    {
      "type": "vcs",
      "url": "https://your-git-server.com/private-package"
    }
  ]

  ，否则中文镜像无法代理

删 vendor/ 和 composer.lock 是手段，不是目的；真正起效的是 composer install 按锁文件重建的过程。最容易被忽略的是 config.platform 和私有仓库的 repositories 配置——它们不会报错，但会让安装静默失败或降级到低版本。