composer的bin字段声明的可执行脚本才是真正的二进制包，需显式配置、被识别并生成代理入口才生效；vendor/bin下命令能直接运行，是因为composer安装时自动创建符号链接（linux/macos）或.bat封装（windows），所有代理均带shebang或等效逻辑，确保调用真实路径如vendor/phpunit/phpunit/phpunit。
bin 字段定义的可执行脚本，就是 Composer 二进制包。它不是指 PHP 扩展本身，也不是随便放个 .php 文件就能用——必须显式声明、被 Composer 识别、并生成代理入口，才算真正生效。
为什么 vendor/bin 下的命令能直接运行？
因为 Composer 在安装含 "bin" 配置的包时，会自动在 vendor/bin 目录下创建代理文件：
- Linux/macOS：生成指向真实脚本路径的符号链接（
ln -s） - Windows：生成同名
.bat脚本，内部调用php "path\to\real\script.php" - 所有代理都带 shebang（
#!/usr/bin/env php）或等效 Windows 封装逻辑，确保可执行
所以你敲 vendor/bin/phpunit，实际跑的是 vendor/phpunit/phpunit/phpunit ——路径隔离、版本绑定、无需手动软链。
如何正确声明一个二进制包？
在你要发布的包的 composer.json 中写清楚 bin 字段：
{
"name": "myorg/my-tool",
"bin": ["bin/my-tool", "bin/my-tool.php"]
}
注意几点：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
bin值必须是相对于包根目录的路径，且文件需存在、有执行权限（Unix）或以#!/usr/bin/env php开头 - 不支持 glob（如
"bin/*.php"），必须逐个列出 - 如果脚本依赖
autoload，请确保composer.json中已正确定义autoload或autoload-dev -
bin里的脚本不应是纯库代码入口（比如index.php），而应是 CLI 工具主入口
常见错误：命令找不到或 Permission denied
典型现象包括：
-
bash: vendor/bin/my-tool: No such file or directory→ 实际是代理文件存在但目标脚本路径错误，检查bin路径是否拼写正确、是否随包发布（确认composer install后该文件真在包里） -
Permission denied（Linux/macOS）→ 脚本缺少+x权限，运行chmod +x bin/my-tool再提交 Git - Windows 下报
'php' is not recognized→.bat代理依赖系统 PATH 中的php，确认 PHP 已全局可用，或改用绝对路径（不推荐） - 脚本里用
require __DIR__.'/../vendor/autoload.php'失败 → 错误地假设了项目结构；二进制包应使用require_once __DIR__.'/../autoload.php'（Composer 自动生成的）或通过composer dump-autoload --classmap-authoritative提前固化加载逻辑
想全局用 my-tool 而不加 vendor/bin/ 前缀？
可以，但要自己动手：
- 把
$(pwd)/vendor/bin加进 shell 的PATH（临时：export PATH="$(pwd)/vendor/bin:$PATH"；永久：写进~/.zshrc或~/.bashrc） - 注意：不同项目可能依赖同一工具的不同版本，全局 PATH 会掩盖这种隔离性，容易引发兼容问题
- 更安全的做法是用别名：
alias my-tool='vendor/bin/my-tool'，只在当前项目生效
真正容易被忽略的点在于：二进制包的生命期完全绑定于 Composer 安装流程，删掉 vendor 或执行 composer update 后，vendor/bin 下的代理会重生成——但如果你手动改过这些代理文件，下次就会被覆盖掉。别动它们，只管维护好源脚本和 bin 声明就行。
