Composer update 报错需据现象分类处理：Conflict 用 why-not/prohibits 定位依赖冲突；404/500 多因源失效或证书过期，需换镜像源并更新 CA；Permission denied 应清缓存、删 vendor 重装；卡住不动则检查约束是否已满足，用 -vvv 和 composer.lock 验证实际更新。
Composer update 报错不是单一原因，得按现象反推：是卡住不动、报 404/500、提示 conflict、还是直接 Permission denied？先看终端最后一行错误信息，再决定下一步。
看到 Conflict 或 Conclusion: remove xxx 怎么办
这是依赖解析失败的典型表现，不是网络问题，也不是权限问题，而是 Composer 算不出一个满足所有包版本约束的组合。
- 运行
composer why-not vendor/package:version（把vendor/package:version换成报错里提到的具体包名和目标版本），它会告诉你哪个已装包在阻止升级 - 再用
composer prohibits vendor/package:version查谁依赖了那个冲突版本——常会发现某个间接依赖锁死了旧版symfony/console或psr/log - 别急着删
vendor和composer.lock。先试composer update --dry-run看计划更新哪些包；如果只是想升 Laravel，用composer update laravel/framework --with-all-dependencies更安全
404 或 500 错误，尤其是请求 packagist.phpcomposer.com 时
这个域名早在 2022 年就下线了，但很多老项目或全局配置还留着它，一请求就返回 404，Composer 就以为“包不存在”。
- 执行
composer config -g repo.packagist看当前全局源，如果是https://packagist.phpcomposer.com，立刻换掉：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 清华源也行，但注意末尾必须带斜杠：
https://mirrors.tuna.tsinghua.edu.cn/composer/，少一个斜杠就会 404 - 如果换源后仍报 500，可能是 OpenSSL 的 CA 证书太旧。运行
php -r "print_r(openssl_get_cert_locations());"查default_cert_file路径，确认该 PEM 文件存在且更新时间不早于 2023 年
Permission denied 写入 vendor/ 或缓存目录
Linux/macOS 上常见于用户权限和安装路径不匹配；Windows 上多是 IDE 或杀毒软件占着文件没释放。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 检查
vendor/目录归属：ls -la vendor/，确保当前用户有读写权限。若属 root，别硬 chmod，直接删掉重来更省事：rm -rf vendor composer.lock && composer install - 缓存目录出问题也会导致奇怪报错：
composer clear-cache必做一步，尤其当你改过 PHP 版本或换了系统 - Windows 用户遇到 “file_put_contents(): failed to open stream”，关掉 PhpStorm / VS Code 的文件索引、禁用实时杀毒扫描，再试
命令执行完没反应、卡住、或显示 success 但 vendor 没变
这往往不是报错，而是“没触发更新逻辑”——Composer 认为你当前装的版本已经满足 composer.json 里的约束。
- 先确认你真想更新：运行
composer outdated，看哪些包其实可以升但没升 - 如果
composer.json里写的是"monolog/monolog": "^2.0"，而你已经装了2.10.0，那composer update就什么也不干——这是设计如此，不是 bug - 加
-vvv参数看真实行为：composer update -vvv | head -n 50，重点扫Reading composer.json和Resolving dependencies那几行，确认它读的是你改过的文件，而不是某个子目录下的旧配置
真正容易被忽略的是：Composer 不报错 ≠ 更新成功。有些冲突会被静默跳过，有些脚本错误会让 post-update-cmd 中断但主流程仍显示 success。只要结果不对，第一反应不该是重跑，而是看 composer.lock 是否被改写、vendor/ 里对应包的 composer.json 是否真变了版本号。
