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/。
- 在项目根目录运行：
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"]），插件就能可靠工作。
