Composer没有“渲染”概念，所有红色报错只是终端对stderr的高亮显示；关键线索在错误末尾非空行，如“Conclusion: don’t install…”揭示依赖冲突根源。
Composer 没有“渲染”概念，更不会报“渲染错误”——这个说法本身是误用术语，常见于把前端框架（如 React/Vue）或视频编辑软件的提示套到了 Composer 上。它是个纯命令行依赖管理工具，所有输出都是文本日志，所谓“红色报错”只是终端对 stderr 的颜色高亮，不是 UI 渲染异常。
composer install/update 报满屏红色，关键线索在最后一段非空行
别被滚动刷屏吓住，真正决定性信息永远在底部。Composer 的 SAT 求解器失败时，会以 Conclusion: 开头给出最简冲突断言，例如：
Conclusion: don't install monolog/monolog 2.10.0|install symfony/console 5.4.39
这说明求解器已穷尽所有可能，确认这两个版本无法共存。常见诱因包括：
-
composer.json里用了中文引号、末尾逗号或注释 → 立即运行composer validate -
composer.lock被 Git 合并损坏 → 不要手动改，执行composer update --lock - 本地 PHP 版本或扩展（如
mbstring）不满足某个包的platform约束 → 运行php -v和php -m | grep mbstring -
require-dev中的包（如phpunit/phpunit）悄悄锁死了核心依赖 → 用composer show --tree查树状依赖
为什么 composer update --dry-run 也报红却没说清哪错了
--dry-run 仍会完整走一遍依赖解析流程，但若没输出明确的 Conclusion 行，大概率是卡在底层环节，而非逻辑冲突：
- HTTP 响应体损坏：比如看到
Failed to decode response: zlib_decode(): data error→ 网络中间件（如代理、防火墙）篡改了压缩流 - SAT 求解器死循环：日志停在
Resolving dependencies through SAT后无下文 → 约束太紧，或存在隐式互斥（如两个包都写了"conflict"） - 插件崩溃：
Exception trace显示某插件第 X 行抛出ext-foobar缺失 → 检查config.platform是否写了不存在的扩展
此时必须加 -vvv，否则看不到真实根因。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-vvv 日志太多怎么快速定位关键行
-vvv 输出量极大，但真正有用的线索集中在三处：
- 开头几行：
Reading ./composer.json失败 → JSON 语法错误，比后面所有冲突都优先修复 - 中间高频词：
grep -i "error\|exception\|zlib\|SAT" debug.log可秒级聚焦 - 末尾堆栈：
Exception trace下第一行通常就是崩溃点，例如Plugin\SomePlugin::activate()→ 直接去查该插件源码
务必用 composer update -vvv 2>&1 | tee debug.log 保存完整输出，终端滚动太快，肉眼根本盯不住关键行。
类找不到、方法不存在，问题不在 Composer 报错本身
这类问题 90% 是自动加载映射未更新或依赖版本实际未装对，和红色报错无关：
- 运行
composer dump-autoload -v，看输出里是否出现你的命名空间前缀；没出现 →autoload配置无效（缩进错、引号漏、PSR-4 末尾缺反斜杠） - 打开
vendor/composer/autoload_psr4.php，手动搜最长匹配前缀（如GuzzleHttp\Psr7\），没匹配上就说明映射根本没生成 - 执行
composer show guzzlehttp/guzzle，确认实际安装版本是否符合预期；若显示2.9.1但你代码调的是3.x新 API，那就是语义化版本失控
真正的难点从来不是看懂报错，而是分清：这是 Composer 自身流程卡住（需 -vvv），还是它装完后你的代码跑不起来（得查 autoload 和版本兼容性）。
