Composer全局安装命令报command not found，是因为~/.composer/vendor/bin（Linux/macOS）或%APPDATA%\Composer\vendor\bin（Windows）未加入PATH；需手动配置环境变量并重启终端验证。
为什么 composer global require 装完命令却报 command not found
根本不是安装失败，而是系统压根没找到可执行文件在哪。Composer 全局安装的二进制（比如 laravel、php-cs-fixer）默认放在：~/.composer/vendor/bin（Linux/macOS）或 %APPDATA%\Composer\vendor\bin（Windows），但这个路径不在系统 PATH 里。
- Linux/macOS：在
~/.zshrc或~/.bashrc末尾加一行export PATH="$HOME/.composer/vendor/bin:$PATH"，然后运行source ~/.zshrc - Windows：打开「系统属性 → 高级 → 环境变量」，把
%APPDATA%\Composer\vendor\bin加进「用户变量」的PATH，然后**重启终端**（不是关掉再开，是彻底新建一个） - 验证是否生效：运行
echo $PATH或echo %PATH%，确认输出里有对应路径；再试which laravel或where php-cs-fixer
项目里 composer require phpunit/phpunit 后，为什么 phpunit 命令不能直接敲
因为它的可执行文件只存在于当前项目的 vendor/bin/phpunit，没进 PATH，系统当然不认识这个命令。这不是 bug，是设计使然——隔离性优先。
- 正确调用方式：
./vendor/bin/phpunit（Linux/macOS）或vendor\bin\phpunit（Windows） - 想省事？在
composer.json的scripts字段里加一条："test": "php vendor/bin/phpunit"，之后直接运行composer test - 别手动给
vendor/bin/phpunit创建全局软链——破坏项目边界，CI 流水线会挂，同事拉代码也跑不起来
哪些该全局装，哪些死都不能全局装
不是看“是不是命令行工具”，而是看它“参不参与项目运行逻辑”。一句话：工具装全局，依赖装项目。
- ✅ 推荐全局：
laravel/installer、friendsofphp/php-cs-fixer、phpstan/phpstan——它们只在你敲命令时起作用，不被autoload加载，不进生产环境 - ✅ 必须项目内：
guzzlehttp/guzzle、monolog/monolog、symfony/console——这些会被你的代码new或use，必须写进composer.json，必须生成composer.lock，必须上生产 - ⚠️ 特别注意：
phpunit/phpunit表面是工具，但很多项目在autoload-dev里引用它，phpunit.xml也可能依赖特定版本，所以更推荐项目内装 - ❌ 绝对禁止全局：
doctrine/dbal、laravel/framework这类——等于废掉composer.lock，部署时版本错乱，错误信息指向你完全没装过的类
全局和项目都装了同一个包，为什么报 Class 'Symfony\Component\Console\Application' not found
这不是 Composer 自动解决的问题，是自动加载器加载顺序冲突了。比如全局装了 php-cs-fixer v3.12（带 symfony/console v5.4），而项目里用了 symfony/console v6.3，两个版本的 Application 类互相覆盖或缺失。
- Composer 不会协调全局和项目 autoload 的优先级，谁先注册谁生效
- 最稳解法：删掉全局的冲突包（
composer global remove friendsofphp/php-cs-fixer），改用项目内安装 +composer scripts封装命令 - 如果真要共存，确保全局工具用的 Symfony 组件版本 ≥ 项目所用最低版本（查
composer show symfony/console对比），否则大概率出问题
