vendor/bin 目录由 Composer 自动创建，用于存放依赖包通过 composer.json 中 "bin" 字段声明的可执行脚本链接或副本；仅声明了 "bin" 且指向有效脚本时才会被暴露，同名会覆盖，实际调用仍依赖原路径和 autoload。
vendor/bin 是 Composer 自动创建的符号链接（或可执行文件）存放目录，专门用于暴露依赖包中提供的命令行工具，让开发者能在项目根目录下直接运行它们，而无需记住完整路径或手动添加到 $PATH。
为什么有些包的命令会出现在 vendor/bin 里？
只有在包的 composer.json 中声明了 "bin" 字段，且该字段指向一个可执行脚本（如 phpstan、phpcs、laravel-zero 的入口文件），Composer 安装时才会把对应文件软链（Linux/macOS）或复制（Windows）进 vendor/bin。
- 例如
phpunit/phpunit的composer.json包含"bin": ["phpunit"]，安装后vendor/bin/phpunit就可用 - 如果包没写
"bin"，哪怕它有bin/目录或可执行脚本，也不会自动暴露到vendor/bin - 多个包声明同名
"bin"（如都叫foo），后安装的会覆盖先安装的 —— Composer 不做冲突检测
运行时实际调用的是什么？
你执行 vendor/bin/phpcs，真正运行的通常是 vendor/squizlabs/php_codesniffer/bin/phpcs 这类原始路径。Composer 只是做了路径映射，不改写脚本内容或逻辑。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 脚本本身仍依赖其所在包的
autoload和相对路径（比如它可能 require../src/...） - 因此不能把
vendor/bin/phpcs单独拷出去用，它不是独立二进制 - Windows 下生成的是批处理文件（
.bat），内容只是包装了php "xxx\phpcs"调用
常见问题和绕过方式
有时 vendor/bin 里的命令报错，比如 Class not found 或 command not found，大概率不是路径问题，而是环境或加载逻辑不对。
-
./vendor/bin/phpunit报Class 'PHPUnit\Framework\TestCase' not found：说明脚本没走 Composer 自动加载，检查该脚本是否漏了require __DIR__ . '/../vendor/autoload.php'; -
bash: vendor/bin/phpcs: Permission denied（Linux/macOS）：文件缺少可执行权限，运行chmod +x vendor/bin/phpcs - 想全局使用（不用写
vendor/bin/前缀）：可以把vendor/bin加进 shell 的$PATH，但注意这会让所有项目共享同一套命令版本，容易引发冲突
// 示例：一个典型的 bin 脚本头部（如 phpunit）
#!/usr/bin/env php
<?php
if (file_exists(__DIR__ . '/../../autoload.php')) {
require_once __DIR__ . '/../../autoload.php';
} elseif (file_exists(__DIR__ . '/../../../autoload.php')) {
require_once __DIR__ . '/../../../autoload.php';
} else {
die('Composer autoloader not found');
}
// 后续才是真正的逻辑入口
真正要注意的是：这些命令不是“安装即用”的黑盒，它们的行为高度依赖包自身的结构和 autoload 配置。删掉 vendor 重装后命令还在，但一旦某个包更新并修改了 "bin" 路径或移除了该字段，vendor/bin 里的对应文件就会失效或消失 —— 这点很容易被忽略。
