vendor-bin 是社区约定的开发工具隔离目录，非 Composer 原生支持；推荐使用 bamarni/composer-bin-plugin 自动管理软链接，避免 bin-dir 全局配置或手动维护带来的路径冲突、兼容性及维护问题。

vendor-bin 目录不是 Composer 原生支持的路径

Composer 本身没有 vendor-bin 这个内置概念，它默认只管理 vendor/ 下的依赖包。所谓 vendor-bin，是社区为**隔离命令行工具（如 PHPStan、Psalm、PHP-CS-Fixer）**而约定的一种目录结构，目的是避免这些 dev-only 工具污染项目主 vendor/bin/，也方便统一管理或 CI 环境复用。

用 composer-bin-plugin 实现 vendor-bin 自动管理

最成熟可靠的方案是使用 bamarni/composer-bin-plugin。它会在安装时自动把指定的工具包二进制文件软链接到 vendor-bin/ 下，不侵入主 vendor/bin/。

Wjs Uploading Video

将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。

下载

• 在项目根目录运行：

  composer require --dev bamarni/composer-bin-plugin

• 在 composer.json 中声明工具包（必须放在 require-dev 下）：

  {
    "require-dev": {
      "phpstan/phpstan": "^1.10",
      "php-cs-fixer/php-cs-fixer": "^3.14"
    }
  }

• 插件会自动创建 vendor-bin/，并在其中生成对应软链接，例如：vendor-bin/phpstan、vendor-bin/php-cs-fixer
• 执行时直接调用：

  vendor-bin/phpstan analyse src/

为什么不能只靠 bin-dir 配置？

很多人尝试在 composer.json 中设置：

"config": {
  "bin-dir": "vendor-bin"
}

这会导致所有包的 bin 文件（包括 monolog/monolog 这类非 CLI 包的脚本）都写入 vendor-bin/，且无法区分“项目依赖”和“开发工具”，还可能破坏某些包对 vendor/bin/ 的硬编码路径假设。

• bin-dir 是全局生效的，影响所有包，不推荐用于工具隔离
• 部分工具（如 phpunit）会检查自身是否在 vendor/bin/ 下运行，路径变更可能导致 __DIR__ 解析异常
• CI 环境中若多个项目共用缓存，bin-dir 切换易引发冲突

手动维护 vendor-bin 的风险点

有人选择不用插件，而是手动 ln -s 或复制二进制文件到 vendor-bin/，这种方式短期可用，但长期难维护：

• 每次 composer update 后，新版本工具的二进制路径可能变化（如从 phpstan/bin/phpstan 变为 phpstan/phpstan/bin/phpstan）
• 不同工具的入口脚本位置不一致：php-cs-fixer 在 php-cs-fixer/php-cs-fixer，psalm 在 vimeo/psalm，手动链接极易出错
• Windows 下软链接需管理员权限，composer-bin-plugin 会自动 fallback 到 copy 模式，手动方式无此兼容性

真正需要关注的是：工具包是否声明了正确的 bin 字段，以及插件能否识别其入口。只要包本身合规（比如 phpstan/phpstan 的 composer.json 里有 "bin": ["phpstan"]），插件就能可靠工作。