composer install 是还原依赖的唯一正确操作，它严格按 composer.lock 安装；require 仅用于新增依赖，误用会破坏环境一致性；失败时优先检查 composer.json 语法、PHP 版本和扩展缺失。

直接说结论：你不需要“导入依赖”或“一键安装所有插件”——composer install 就是唯一正确操作，前提是项目里已有 composer.json 和（通常也有的）composer.lock。

为什么不能用 composer require 来“导入已有依赖”

很多人误以为要一个个 composer require vendor/package 才能装上项目原本的库，这是典型误解。已有项目依赖信息全在 composer.json 里，require 是用来「新增」依赖的，不是「还原」依赖的。

• 执行 composer require foo/bar 会修改 composer.json，并写入新条目，还可能升级其他包，破坏原有依赖关系
• 如果项目已上线或多人协作，随意 require 会导致本地环境和生产环境不一致
• composer.json 里的 require 字段只是声明，真正锁定版本的是 composer.lock —— 它必须被保留并参与安装

composer install 才是还原依赖的唯一方式

这个命令读取 composer.lock（如有），严格按其中记录的版本、哈希、源地址安装；没 lock 文件时才退回到 composer.json 并生成新 lock —— 这反而容易出问题。

Workflow Decomposer

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

下载

• ✅ 正确做法：把整个项目（含 composer.json 和 composer.lock）拉下来，运行 composer install
• ⚠️ 常见错误：删掉 vendor/ 后跑 composer update —— 这会忽略 lock，重新解析全部依赖，很可能升版、引入不兼容变更
• ? 如果只有 composer.json 没 lock（比如老项目或别人没提交），先跑 composer install --no-interaction 生成锁文件，再交给团队共享
• ? install 默认跳过 require-dev 的包（如测试工具），加 --with-all-dependencies 或明确用 --dev 才装开发依赖

哪些情况会卡住或报错？重点看这三处

执行 composer install 失败，90% 出在这几个地方，别急着搜错误全文，先盯住这些点：

• composer.json 语法错误：用 composer validate 快速检查，常见于多了一个逗号、引号没闭合
• PHP 版本不匹配：看 composer.json 里 "php": "^8.1" 这类约束，运行 php -v 对比；不一致时 Composer 会直接拒绝安装
• 扩展缺失：比如提示 ext-zip not found，说明 PHP 编译时没开 zip 扩展，Ubuntu 上装 php-zip，macOS 用 brew install php@8.2（注意版本对齐）
• 权限问题：某些共享主机或 Docker 环境下，vendor/ 写入失败，可临时加 --no-scripts 跳过 post-install-cmd，再手动处理

最麻烦的其实是 composer.lock 被改写却不自知——它看起来只是个 JSON 文件，但里面每个包的 commit hash、dist url、verify-key 都影响最终安装结果。别手动编辑它，也别让 IDE 自动格式化，更别用不同 Composer 版本来回生成。