bin 字段声明项目级可执行脚本，仅对当前项目生效，必须指向项目内存在且有执行权限的文件或PHP脚本，路径相对于composer.json目录，不支持函数名或类方法。
什么是 bin 字段，它到底绑定谁？
bin 字段在 composer.json 中声明的是「项目级可执行脚本」，不是全局命令，也不是 Composer 插件入口。它只对当前项目生效，且必须指向项目内存在的、有可执行权限（chmod +x）的文件，或 PHP 脚本（Composer 会自动用 php 解释器运行）。
常见误解是以为填个函数名或类方法就能注册命令——不行。bin 只接受文件路径字符串，且路径相对于 composer.json 所在目录。
- ✅ 正确：
"bin": ["bin/mytool"]（对应./bin/mytool） - ✅ 正确：
"bin": ["scripts/deploy.php"]（Composer 自动加php前缀） - ❌ 错误：
"bin": ["MyTool::run"]或"bin": ["vendor/bin/phpunit"]（后者属于依赖包，不该放这里）
如何让 bin/mytool 在本地直接运行？
Composer 安装后，会把 bin 下所有条目软链接到 vendor/bin/。所以你运行 vendor/bin/mytool 是没问题的，但想在项目根目录下直接敲 mytool，得靠 shell 的 $PATH 或 alias。
更实用的做法是：在 composer.json 的 scripts 里封装调用，再用 composer run mytool 启动：
{
"bin": ["bin/mytool"],
"scripts": {
"mytool": "bin/mytool"
}
}
这样既免去 PATH 配置，又保证环境一致（比如使用项目锁定的 PHP 版本）。如果真要全局可用，需手动将 $(pwd)/vendor/bin 加入 shell 的 $PATH，但不推荐用于协作项目。
bin 文件本身要满足什么条件？
它不是任意脚本——必须能被系统直接执行或被 PHP 解释器识别。两类写法最常用：
- Shell 脚本：第一行必须是
#!/usr/bin/env sh或#!/usr/bin/env bash，且文件要有执行权限（chmod +x bin/mytool） - PHP 脚本：第一行写
#!/usr/bin/env php，文件扩展名建议为.php，且确保有开头（否则 Composer 可能跳过解析）
注意：Windows 用户若用 Git Bash，#!/usr/bin/env php 仍有效；但 CMD/PowerShell 不识别 shebang，此时依赖 Composer 自动调用 php，所以 PHP 脚本更跨平台。
示例 bin/mytool（PHP 类型）：
#!/usr/bin/env php为什么
composer install后vendor/bin/里没生成链接？最常见三个原因：
-
bin字段没写在根项目的composer.json里，而是写在了某个require的包中（那是包作者的事，不影响你的项目） - 文件路径写错，比如
"bin": ["bin/tool"]但实际文件是bin/tool.php（Composer 不自动补扩展名） - 运行了
composer install --no-bin-links或设置了环境变量COMPOSER_BIN_DIR=/dev/null
验证方式：执行 composer config bin-dir 看输出是否为 vendor/bin；再检查 ls -l vendor/bin/ 是否有对应软链接。没有就说明前面某步断了。
真正容易被忽略的是：Composer 只在 install 或 update 时生成链接，改了 bin 字段后不重装就不会更新 vendor/bin —— 得手动删掉 vendor/bin/xxx 再跑一次 composer install。
