全局安装需配置PATH才能使用命令，项目内安装的工具不在PATH中故不可直接运行；工具应全局安装，运行依赖必须项目内安装；全局与项目共存时需避免autoload冲突。
全局安装的命令和PATH不配好，就等于没装
执行 composer global require laravel/installer 成功后，laravel 命令仍报 command not found，这是最常见问题。根本原因不是安装失败，而是系统找不到可执行文件。
- 全局二进制默认放在：
~/.composer/vendor/bin（linux/macos）或%appDATA%Composervendorbin（windows） - 必须手动把该路径加入系统
PATH：Linux/macOS 在~/.zshrc或~/.bashrc中加export PATH="$HOME/.composer/vendor/bin:$PATH"，然后source ~/.zshrc - Windows 需在「系统属性 → 环境变量」中将
%APPDATA%Composervendorbin加入用户或系统PATH，并重启终端 - 验证是否生效：运行
echo $PATH（macOS/Linux）或echo %PATH%（Windows），确认路径已包含；再执行which laravel或where laravel
项目内安装的工具为什么不能直接敲命令运行
用 composer require phpunit/phpunit 装完后，phpunit 命令依然不可用——因为它的可执行文件只存在于当前项目的 vendor/bin/phpunit，不在系统 PATH 里。
- 正确调用方式是：
./vendor/bin/phpunit（Linux/macOS）或vendorbinphpunit（Windows） - 想简化？可在
composer.json的scripts字段里定义别名，例如："test": "php vendor/bin/phpunit"，之后用composer test即可 - 不建议为每个项目手动加软链或改
PATH：既破坏隔离性，又增加维护成本 - 注意：项目内安装的包不会影响其他项目，哪怕版本冲突（比如 A 项目用 PHP-CS-Fixer v3.12，B 项目用 v3.20），互不干扰
什么该全局装，什么必须项目内装
不是看“是不是工具”，而是看“它是否参与项目运行逻辑”。一句话：**工具装全局，依赖装项目**。
- ✅ 推荐全局安装（开发辅助、跨项目使用）：
laravel/installer、friendsofphp/php-cs-fixer、phpstan/phpstan - ✅ 必须项目内安装（运行时依赖、需版本锁定）：
guzzlehttp/guzzle、monolog/monolog、symfony/console - ⚠️ 特别注意：
phpunit/phpunit表面是工具，但常被测试引导文件（如phpunit.xml或tests/bootstrap.php）autoload 引用，且 CI 流水线依赖具体版本，因此更推荐项目内安装 - ❌ 绝对不要全局安装项目运行依赖：比如把
doctrine/dbal全局装了，项目composer.lock就失去意义，部署时极易出错
全局与项目共存时，类加载冲突怎么破
全局装了 php-cs-fixer，项目也用了同名包不同版本，执行时报 class 'SymfonyComponentConsoleApplication' not found——这不是 Composer 自动解决的问题，而是自动加载器优先级导致的。
- Composer 的 autoloader 是按注册顺序加载的，全局和项目 vendor 是两个独立 autoload 体系，但 CLI 执行时可能混用
- 典型诱因：全局包依赖旧版
symfony/console，而项目用了新版，CLI 运行时加载了全局的 autoload，却试图 new 项目的类 - 解决思路：避免全局和项目同时提供相同命名空间的可执行命令；若必须共存，统一用项目内版本（删掉全局的，改用
composer exec php-cs-fixer） - 验证方式：运行
composer global show和composer show对比依赖树，重点检查symfony/、psr/等基础组件版本是否错位
全局安装省事，但 PATH 和版本管理稍有疏忽，就会变成“装了=白装”；项目内安装看似啰嗦，却是环境一致性的唯一可靠保障。真正容易被忽略的，不是“怎么装”，而是“谁在加载哪个 autoload.php”。