在 composer.json 顶层配置 "bin-dir": "tools"（推荐相对路径），可自定义可执行脚本软链接位置；需删除 vendor 后重新 install，且仅当依赖包声明了 "bin" 字段并被正确安装时才生效。
composer.json 里怎么配 bin-dir？
直接在 composer.json 的顶层加 "bin-dir" 字段就行，值是相对路径（推荐）或绝对路径。它控制所有包里 bin 目录下可执行脚本的软链接存放位置，默认是 vendor/bin。
常见错误：写成 "bin" 或 "bin-path" —— 都不生效，必须是 "bin-dir"。
- 路径建议用相对路径，比如
"bin-dir": "tools"，这样项目迁移时不会断 - 如果设为
"bin-dir": "/usr/local/bin"，后续composer install会尝试往系统目录写软链接，大概率因权限失败 - 改完记得删掉旧
vendor/bin（或整个vendor），再跑composer install，否则旧链接残留
为什么 vendor/bin 下的脚本没生成？
不是所有包都提供可执行文件。只有包的 composer.json 里声明了 "bin" 字段（比如 "bin": ["phpunit", "psalm"]），且你装的是该包（非 require-dev 里但没启用 --dev），才会被链入 bin-dir。
典型现象：composer require phpunit/phpunit 后 vendor/bin/phpunit 没出现 —— 因为 PHPUnit 5.7+ 把 bin 移到了 require-dev，且默认不启用开发依赖安装。
- 确认包是否真有
"bin"声明：查它的composer.json（GitHub 上直接搜） - 检查是否装对了版本：有些包只在特定版本提供
bin，比如larastan从 v2 开始才放bin - 开发依赖要显式安装：
composer install --dev或确保"config": {"dev": true}
全局 bin-dir 和项目级 bin-dir 冲突怎么办？
全局配置（COMPOSER_HOME/config.json）里的 "bin-dir" 会被项目级 composer.json 覆盖，优先级：项目 > 全局 > 默认。但容易踩的坑是「以为设了全局就一劳永逸」—— 实际上只要项目里没配，就还是用默认 vendor/bin。
另一个问题是：某些 IDE（如 PHPStorm）硬编码识别 vendor/bin，换了 bin-dir 后自动补全失效。
- 查当前生效的
bin-dir：运行composer config bin-dir（显示项目级值）或composer global config bin-dir（全局） - IDE 不识别新路径？手动在设置里指定可执行路径，别依赖自动发现
- CI/CD 脚本里别假设
vendor/bin/phpunit存在，改用$(composer config bin-dir)/phpunit
Windows 下 bin 脚本打不开？
Windows 不支持 Unix 软链接，Composer 会生成 .bat 包装器。但这些 .bat 文件依赖 php.exe 在 PATH 中，且要求扩展名关联正确。
典型报错：'php' is not recognized as an internal or external command，或者双击 .bat 闪退。
- 确保
php.exe可执行：命令行输php -v能返回版本 - 不要把
bin-dir设成带空格的路径（如"My Tools"），.bat 解析会出错 - 避免用 WSL 的路径（如
/mnt/c/...）作为bin-dir，Windows 命令行无法访问 - 想彻底绕过 .bat？用
php vendor/autoload.php手动加载入口类，但得自己处理参数解析
事情说清了就结束。注意 bin-dir 是 Composer 安装时的链接策略，不影响包内脚本本身的逻辑；改路径后所有 CI、IDE、团队成员都得同步认知，不然协作时第一个报错的永远是别人。
