composer config bin-dir 修改的是 composer 安装可执行脚本（如 phpunit）时默认写入的目录，即 bin 文件的存放路径，而非 vendor 目录或项目根目录；默认为 vendor/bin，可设为相对或绝对路径，修改后需确保 shell 的 $path 包含该路径才能直接调用。
composer config bin-dir 改的是哪个目录
它改的是 Composer 安装可执行脚本（比如 phpunit、larastan、pest）时默认写入的位置，不是 vendor 目录本身，也不是项目根目录。改完后，所有通过 composer require --dev 安装的含 bin 字段的包，其二进制文件都会软链或复制到你指定的路径。
常见错误现象：vendor/bin/phpunit 找不到，但 ./vendor/bin/phpunit 能跑——说明你本地没加 vendor/bin 到 $PATH，而误以为是 bin-dir 没生效；其实它只管“往哪放”，不管“怎么调用”。
- 默认值是
vendor/bin（相对路径），实际解析为项目根目录下的vendor/bin - 可以设为绝对路径，比如
/usr/local/bin，但要注意写权限和系统 PATH 是否包含该路径 - 设为相对路径时，始终相对于
composer.json所在目录，不是当前 shell 工作目录
怎么安全地设置 bin-dir（不破坏现有流程）
直接运行命令就行，不需要改 composer.json 手动加字段，Composer 会自动写进 composer.lock 同级的 composer.json 的 config 块里：
composer config bin-dir bin-scripts
这样所有 bin 文件就会放进项目下的 bin-scripts/ 目录。之后再 composer install 或 composer update 就会按新路径生成链接。
- 如果已有 bin 文件在
vendor/bin下，composer install不会自动清理旧文件，得手动删掉vendor/bin目录（或整个vendor）再重装 - CI/CD 环境中，确保
composer install前已执行过composer config，否则仍走默认路径 - 多人协作时，这个配置会写进
composer.json，所以要 commit，不然别人composer install还是用默认vendor/bin
为什么改了 bin-dir 后某些命令还是找不到
根本原因：shell 不知道新路径在哪。Composer 只负责“放”，不负责“让你能敲出来”。比如你设成 bin-scripts，那得自己把 $(pwd)/bin-scripts 加进 $PATH，或者用 ./bin-scripts/phpunit 显式调用。
- Linux/macOS：在
~/.bashrc或~/.zshrc里加export PATH="$(pwd)/bin-scripts:$PATH"——但注意，$(pwd)是动态的，只对当前目录有效；更稳妥的是用绝对路径，比如/path/to/project/bin-scripts - Windows PowerShell：用
$env:PATH += ";C:\path\to\project\bin-scripts"，同样需绝对路径 - IDE（如 PHPStorm）可能缓存了旧的
vendor/bin路径，需要重启或刷新外部工具配置
bin-dir 和 vendor-dir 能不能设成同一级目录
可以，但不推荐。比如都设成 ../lib，会导致 vendor 和 bin 并列在上层目录，看似整洁，实则埋坑：
-
vendor-dir改动会影响所有依赖的安装位置，很多包的 autoloader、路径硬编码（尤其测试引导文件）会崩 -
bin-dir设为上级目录时，composer install会尝试创建该路径，若无写权限直接报错：Could not create directory ../lib - Git 忽略规则容易漏掉新 bin 目录，导致脚本被意外提交，或不同人环境不一致
- 某些托管平台（如 Laravel Vapor、Heroku Buildpack）默认只扫描
vendor/bin，换路径后 CI 任务直接失败
真正省事的做法是接受默认 vendor/bin，然后统一用 composer exec phpunit 或 npm-style 的 composer run test 封装调用，绕过 PATH 问题。
