composer exec确保调用当前项目vendor/bin下的指定工具版本，避免PATH中旧版或全局命令干扰；需用--分隔参数，不适用于交互式命令。
composer exec 不是让你“把命令变全局”，而是确保你调用的是当前项目 vendor/bin/ 下那个版本的工具——比如 phpunit、phpstan 或自定义脚本名。它解决的核心问题是：避免系统 PATH 里混着旧版、全局版或不同项目的同名命令，导致测试失败、分析误报、CI 行为不一致。
为什么直接敲 phpunit 会报错或版本不对
常见错误现象：Command "phpunit" not found，或者跑出一堆“已废弃”警告，甚至测试通过但线上却失败。
- 你的 shell PATH 可能根本没包含
./vendor/bin（尤其 Windows 或新装系统） - PATH 里有全局安装的
phpunit，版本比项目 require 的低，不支持--min-coverage这类参数 - Windows 下
./vendor/bin/phpunit是个.bat文件，直接执行 shell 脚本会失败 - CI 环境通常不配置 PATH，硬写
./vendor/bin/phpunit在 macOS/Linux 可行，但在 Windows runner 上挂掉
composer exec 自动把当前项目的 vendor/bin 加进临时 PATH，并根据平台选对可执行文件（.bat 或 #!/usr/bin/env php），一步屏蔽这些差异。
composer exec 怎么传参数给底层命令
关键在双横线 --：它用来分隔 composer exec 自己的选项和真正要传给目标命令的参数。
-
composer exec phpunit -- --filter=testLogin→--filter=testLogin传给phpunit，不是composer -
composer exec --timeout=300 phpstan analyse src/ --level=7→--timeout=300是 composer 的，--level=7才是phpstan的 - 漏掉
--就会报错，比如composer exec phpunit --filter=testLogin会被当成 composer 尝试找叫--filter=testLogin的命令
自定义脚本也一样：如果 composer.json 里写了 "scripts": {"lint": "php-cs-fixer fix"}，那 composer exec lint -- --dry-run 中的 --dry-run 最终会传给 php-cs-fixer。
哪些命令不能用 composer exec 安全运行
交互式命令基本不行，因为 composer exec 不接管完整 TTY。
-
composer exec psysh→ 输入卡住、回车无响应、Ctrl+C 退出异常 -
composer exec laravel tinker→ 启动成功但无法输入 PHP 表达式 -
composer exec composer update→ 虽然能跑，但属于“自己调自己”，容易触发嵌套 autoload 冲突，不推荐
这类工具请直接运行二进制：./vendor/bin/psysh 或 php ./vendor/bin/laravel tinker。它们能正确绑定 stdin/stdout/stderr，保证交互流畅。
composer exec 和直接调用 ./vendor/bin/xxx 有什么实际差别
表面看都是执行同一个文件，但行为边界很不一样。
- 路径处理：
./vendor/bin/phpunit是硬编码路径，一旦项目结构变动（比如放在子目录）、或用了 path repository 符号链接，就可能失效；composer exec phpunit始终基于当前composer.json解析真实 bin 路径 - 环境变量：
composer exec会把项目根目录设为工作目录（CWD），并加载vendor/autoload.php，某些依赖运行时路径的工具（如php-cs-fixer查配置文件）更稳定 - 别名支持：
composer exec lint能命中composer.json中"scripts": {"lint": "..."}定义的逻辑，而./vendor/bin/lint只认物理文件
真正容易被忽略的是：当你在子包（monorepo 场景）里开发时，composer exec 默认仍以主项目根为上下文；必须显式加 --working-dir=packages/foo 才能让它切换到子包的 vendor/bin，否则可能调错版本。
