vendor/bin 目录在项目根目录下的 vendor/bin/，需将 $(pwd)/vendor/bin（Linux/macOS）或 %CD%\vendor\bin（Windows）加入 PATH 实现本地命令直接调用，推荐临时 export 或条件写入 shell 配置文件，避免全局污染。
composer bin 目录在哪？怎么加进 PATH？
Composer 本地安装的工具（比如 phpunit、php-cs-fixer）默认放在项目根目录下的 vendor/bin/，不是全局可执行的。想在项目里直接敲命令就运行，得让 shell 找得到它。
最稳妥的做法是把 vendor/bin/ 加进当前 shell 的 PATH，而不是用 ./vendor/bin/phpunit 这种冗长写法。
- Linux/macOS：在项目根目录下运行
export PATH="$(pwd)/vendor/bin:$PATH"（临时生效）；想永久生效，可以加到.bashrc或.zshrc里的条件判断中，避免污染全局环境 - Windows（CMD）：用
set PATH=%CD%\vendor\bin;%PATH%；PowerShell 用$env:PATH = "$PWD\vendor\bin;" + $env:PATH - 别直接改系统级 PATH——不同项目依赖的工具版本可能冲突，
vendor/bin是按项目隔离的，破坏这点就失去本地安装的意义
为什么 vendor/bin 下的脚本有时“找不到命令”？
常见现象是：明明 ls vendor/bin 看到 phpunit，但敲 phpunit --version 报 command not found，或者提示 Permission denied。
- 脚本没有可执行权限（尤其 Windows Git Bash 或某些 Docker 环境）：运行
chmod +x vendor/bin/*补上权限 - 脚本第一行是
#!/usr/bin/env php，但系统没装 PHP 或路径不对：检查which php是否正常，或用php vendor/bin/phpunit绕过 shebang - 某些工具（如
larastan）生成的是 Windows 批处理文件（.bat），在非 Windows 下自然跑不了——这类工具建议用composer exec代替
composer exec 比直接调用 vendor/bin 更可靠吗？
是的，composer exec 是 Composer 内置的代理命令，它会自动定位并执行 vendor/bin/ 下的工具，还自带环境隔离和参数透传，适合 CI 或多环境一致执行。
- 基本用法：
composer exec phpunit -- --testdox（--后面的参数会原样传给phpunit） - 它不依赖 shell 的 PATH，也不受文件权限影响，只要
composer.json里声明了依赖，就能跑 - 缺点是启动稍慢（要加载 Composer 自身），不适合高频交互场景（比如写代码时反复跑单测）；日常开发还是建议配好 PATH
- 注意：老版本 Composer（exec，得升级或改用
php vendor/bin/xxx
Windows 上 vendor/bin 脚本为什么总报错“无法加载程序”？
本质是跨平台脚本兼容问题。Composer 在 Windows 上默认生成 .bat 文件，而 WSL、Git Bash、Docker 容器这些环境不认 .bat，又没正确 fallback 到 PHP 脚本。
- 临时解法：用
php vendor/bin/phpunit显式调用解释器（所有平台都有效） - 长期建议：在
composer.json中加"config": {"bin-dir": "bin"}，再配合 Git 忽略vendor/bin/*.bat，强制走 Unix 风格脚本（需确保 PHP 可执行路径已配置） - CI 场景（GitHub Actions / GitLab CI）统一用
composer exec，省去平台差异判断
真正麻烦的不是路径本身，而是不同环境对“可执行文件”的理解不一致——vendor/bin 是 Composer 做的软链接/脚本桥接层，它既不是纯粹的二进制，也不是标准的 shell 脚本，得根据执行上下文选对打开方式。
