执行 composer install 或 update 必须在含 composer.json 的项目根目录运行，composer 不支持 --working-dir 参数，常见错误是路径错误导致找不到文件或 vendor 为空。
composer install 必须在项目根目录运行
执行 composer install 或 composer update 时，当前工作目录必须是含 composer.json 和 composer.lock 的项目根目录。Composer 不会自动向上查找或向下遍历，也不接受 --working-dir 这类参数——它只认当前路径。
常见错误现象：Could not find a composer.json file in /path/to/xxx 或静默失败后 vendor 为空。
- 确认你已
cd进入正确目录：比如项目结构为/var/www/myapp/composer.json，就得先cd /var/www/myapp - 不要试图用
composer install -d /var/www/myapp——这个-d参数根本不存在，Composer 命令行不支持 - 如果目录名含空格或中文（如
D:\我的项目），Windows 下容易因路径解析失败导致命令卡住或报错，建议改用纯英文路径
想在其他目录触发项目命令？用 --working-dir 是错的
很多人搜到 --working-dir，以为能指定项目位置，但这是个严重误解：--working-dir 是 Composer 插件或脚本内部使用的上下文参数，**不是用户可用的 CLI 选项**。直接运行 composer install --working-dir=/path 会报错 Unrecognized option "--working-dir"。
真正可行的替代方式只有两个：
- 用
cd切换后再执行（最稳妥） - 用 shell 的子 shell 语法一次性完成：
(cd /path/to/project && composer install)（注意括号和空格）
后者适合写进 CI 脚本或 Makefile，避免残留路径状态；但别在 Windows CMD 中直接用，PowerShell 支持更好。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
全局命令（如 laravel）为何在任意目录都能跑
像 laravel new myapp 或 phpunit 这类命令之所以不依赖当前目录，是因为它们是通过 composer global require 安装到全局 vendor 的二进制文件，并被软链接到了系统 PATH 中的某个 bin 目录（如 $HOME/.composer/vendor/bin）。
关键点在于：它们和当前项目无关，只是碰巧名字像 Composer 命令而已。
- 验证方式：运行
which laravel（Linux/macOS）或where laravel（Windows），看到的是全局 bin 路径，不是项目里的vendor/bin/laravel - 如果你在项目里运行
vendor/bin/laravel，那它才真正依赖当前项目结构和 autoload - 误把全局命令当项目命令用，常导致
Class not found，因为加载的是全局 autoloader，而非项目自身的
CI/CD 或自动化脚本中切换目录要防坑
在 GitHub Actions、GitLab CI 或 Jenkins 里调用 Composer，最容易出问题的是路径没切对，尤其当 checkout 后默认在仓库根，但项目实际在子目录（如 src/ 或 backend/）。
示例场景：仓库根有 backend/composer.json，但 CI 脚本直接写 composer install，就会失败。
- 明确用
cd backend（Linux/macOS）或Push-Location backend（PowerShell）切换 - 别依赖相对路径变量如
$PWD/../backend，CI 环境下 $PWD 可能不可靠 - 加一句
ls -l composer.json或Test-Path composer.json做前置校验，比事后 debug 更省时间
路径切换看着简单，但在跨平台、多阶段构建中，漏掉一次 cd 就会让整个流程静默失败——而错误日志里往往只显示 “vendor not found”，不会告诉你当前在哪。
