vendor目录损坏或composer.lock与实际不一致导致报错，应先验证锁文件可信性，再清缓存并用--no-cache重装，autoload.php缺失多因路径错误或权限问题。
composer install 报错“corrupted package”或找不到 vendor/autoload.php
这说明 vendor/ 目录已损坏，或者 composer.lock 与实际安装状态不一致。别急着删整个 vendor/，先确认问题根源：Composer 不会自动“修复”损坏的包，它只按 composer.lock 精确还原——所以第一步永远是验证锁文件是否可信。
实操建议：
- 检查
composer.lock是否被手动修改过、是否 git 拉取时换行符出错（尤其 Windows ↔ Linux 协作时），git status看它是否被标为 modified - 运行
composer validate，若提示 “lock file is not up to date”，说明composer.json有改动但没执行composer update，此时直接composer install必然失败 - 如果
composer.lock是干净的，但vendor/里缺文件或报哈希校验失败，就该清掉重来——但别用rm -rf vendor/后直接install，优先走composer install --no-cache，跳过本地缓存干扰
composer update 强制重拉所有包但速度慢、卡在某个包
composer update 默认只更新 composer.json 中声明变更的依赖，想“重新拉取所有包”，本质是让 Composer 忽略缓存、强制重新解包和安装。但盲目加 --force 或反复 update 很容易触发网络超时或 packagist 限流。
实操建议：
- 先清空 Composer 缓存：
composer clear-cache，否则它可能从损坏的缓存中恢复旧包 - 加
--no-cache参数再跑composer install，比update更轻量、更可控（前提是composer.lock可信） - 如果必须
update，加-vvv看卡在哪一步，常见是某私有仓库认证失效，或dist包下载失败后没 fallback 到source；此时可临时设COMPOSER_REPO_PACKAGIST=https://packagist.org排除镜像问题 - 某些包（如含二进制的
hirak/prestissimo）在旧版 Composer 中会因并行下载损坏，升级到 Composer 2.5+ 能显著降低这类风险
vendor/autoload.php 丢失或 require_once 失败
这不是 Composer “没装好”，而是自动加载机制没触发。只要 vendor/ 存在且 autoload.php 文件物理存在，90% 的原因是路径引用错了，或用了错误的入口方式。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
实操建议：
- 确认当前工作目录是项目根目录（即含
composer.json的那一层），否则require 'vendor/autoload.php'会相对当前路径找，自然失败 - 不要手动复制
vendor/目录到其他项目——自动加载路径写死在vendor/composer/autoload_*.php里，跨目录即失效 - 如果刚执行过
composer install但autoload.php还是不存在，大概率是权限问题：Docker 容器内运行时 uid/gid 不匹配，导致vendor/创建失败却无报错，检查ls -la vendor/输出是否为空 - 极少数情况是
composer.json里写了"autoload": {"psr-4": {}}但没填值，会导致 autoload 生成逻辑跳过，删掉空配置段即可
CI/CD 中 vendor 恢复不稳定，本地好线上挂
根本矛盾在于：本地开发通常用完整 composer install，而 CI 常加 --no-dev 或 --prefer-dist，一旦 composer.lock 里 dev 依赖影响了 autoloading 或脚本执行顺序，就会表现不一致。
实操建议：
- CI 中统一用
composer install --no-interaction --optimize-autoloader --no-progress，去掉交互和进度条能减少超时假象 - 禁止在 CI 中使用
composer update，除非你明确要更新 lock 文件——CI 应该只做“还原”，不是“决策” - 如果用了私有包，确保 CI 环境的
auth.json已正确注入（GitHub Actions 用secrets.COMPOSER_AUTH，GitLab CI 用COMPOSER_AUTH环境变量），否则会静默跳过包或拉取空内容 - 某些共享主机或低配 CI runner 会因内存不足中断安装，加
COMPOSER_MEMORY_LIMIT=-1防止 OOM kill
最麻烦的情况其实是 lock 文件里混进了平台配置（比如 ext-gd 版本约束），但目标环境没装对应扩展——这种不会报错，只会悄悄降级包版本，最后 runtime 才暴露问题。得靠 composer check-platform-reqs 提前扫一遍。
