报“Command 'xxx' is not defined”主因是命令未注册或 autoload 失效，需检查 vendor/autoload.php 是否有效、composer.json 的 autoload 配置是否正确、命令类是否符合命名空间与继承规范、服务提供者是否注册、PATH 是否包含全局 bin 目录、PHP 扩展是否启用，以及使用 -vvv 查看真实错误。
报“Command 'xxx' is not defined”是命令未注册或 autoload 失效
这不是 Composer 本身坏了，而是 composer.json 里声明的脚本没被加载，或 vendor/autoload.php 没生效。常见于刚 clone 项目就跑 composer install 后立即执行自定义命令（如 php artisan、bin/console）却提示命令不存在。
- 先确认
vendor/autoload.php是否真实存在且可读：运行php -f vendor/autoload.php，无输出即表示加载成功；报错则说明 autoload 生成失败或路径损坏 - 检查
composer.json的autoload或autoload-dev字段是否含"psr-4"映射，且对应目录下有实际 PHP 类文件；若用classmap，需确保已运行composer dump-autoload - 自定义命令类（如
App\Console\Commands\FooCommand）必须满足：命名空间与 PSR-4 路径一致、类名正确、继承了框架约定基类（如Symfony\Component\Console\Command\Command），否则即使 autoload 成功也不会被识别 - 某些框架（Laravel、Symfony）依赖服务提供者注册命令，而提供者注册逻辑写在
config/app.php或src/Kernel.php中——若这些文件缺失、拼写错误或被.gitignore错误排除，命令就永远不出现
全局命令（如 laravel）报“不是内部或外部命令”要查 PATH 和 .bat 文件
Windows 下最典型：运行 composer global require laravel/installer 成功，但敲 laravel -V 就报错。问题不在 Composer，而在系统找不到那个 .bat 文件。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer config --global home查出全局根目录（通常是C:\Users\用户名\AppData\Roaming\Composer），再确认%APPDATA%\Composer\vendor\bin是否已加入系统 PATH（控制面板 → 系统 → 高级 → 环境变量 → 用户变量 → Path） - 进入该
bin目录，检查是否存在laravel.bat，右键 → 属性 → 安全 → 当前用户是否有“读取和执行”权限；若被杀软拦截过，可能文件为空或损坏 - PowerShell 默认禁用未签名脚本，若用它启动命令，需临时运行
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser（仅当前用户，非全局） - 更稳妥的做法是绕过
.bat：直接调用php %APPDATA%\Composer\vendor\bin\laravel，或改用 Git Bash（它把.bat自动转为 shell wrapper）
报“Script xxx handling yyy returned with error code 1”得看 -vvv 输出的真实 stderr
Composer 默认吞掉脚本执行时的原始错误，只告诉你“失败了”。不加 -vvv，你永远不知道是哪行 PHP 报了 Fatal error 还是 Class not found。
- 必须加
composer install -vvv，然后搜索日志里的Fatal error、ParseError、Class not found、Call to undefined function—— 这些都在 stderr 里，-vv不会显示 - 如果脚本是 PHP 文件，检查开头是否有
#!/usr/bin/env php（Linux/macOS）或是否被 Windows 当作文本而非可执行文件处理；推荐统一写成"php script.php"形式，在composer.json的scripts字段中显式指定解释器 - 某些脚本依赖扩展（如
ext-gd），而该扩展虽已安装，但未启用；-vvv日志末尾会列出所有检测到的平台扩展，比php -m更贴近 Composer 实际判断逻辑
“invalid command”出现在 CI/CD 或 Docker 中，大概率是镜像没装对 PHP 扩展
Docker 构建时 composer install 成功，但容器内运行 php artisan list 却报无效命令，往往因为基础镜像缺关键扩展，导致框架核心类无法加载。
- 检查 Dockerfile 是否显式启用了
openssl、mbstring、xml、zip（Composer 2.x 强依赖）—— Alpine 镜像要用apk add php82-zip这类包名，Debian 用apt-get install php-zip - PHP CLI 和 FPM 模块配置可能不同：运行
docker exec -it container php -m | grep zip，确认 CLI 模式下扩展确实启用；别只信phpinfo()页面 - 某些命令（如 Laravel 的
schedule:run）依赖proc_open，而该函数常被 Docker 安全策略禁用；检查容器内php -r "var_dump(function_exists('proc_open'));"返回是否为true - 不要在构建阶段用
--ignore-platform-reqs绕过检查——它会让 Composer 装上不兼容的包，运行时才暴露问题，排查成本翻倍
-vvv，不查 vendor/autoload.php 是否可执行，不验证 php -m 在当前上下文是否真生效，就动手重装 Composer，纯属浪费时间。 
