全局安装路径：Linux/macOS为~/.composer/vendor/bin，Windows为C:\Users\用户名\AppData\Roaming\Composer\vendor\bin；需手动添加至PATH环境变量并重启终端生效，否则命令不可用。
全局安装的命令和路径在哪？
全局安装用的是 composer global require，包会装到系统级目录：Linux/macOS 是 ~/.composer/vendor/bin，Windows 是 C:\Users\用户名\AppData\Roaming\Composer\vendor\bin。但注意——这不等于你敲 php-cs-fixer 就能直接运行。
- 必须把对应
bin目录加进系统PATH，否则会报command not found - 加完 PATH 后建议新开终端，再执行
echo $PATH（macOS/Linux）或echo %PATH%（Windows）确认生效 - 可用
composer global show查看已装了哪些全局工具
项目内安装为什么不能替代全局安装？
项目内用 composer require 装的包只在当前项目的 vendor/ 下，vendor/bin 里的可执行文件默认只能通过 php vendor/bin/php-cs-fixer 这种带路径的方式调用。想直接运行？得靠 scripts 配置或手动加软链，麻烦且不通用。
- 不同项目可能依赖同一工具的不同版本（比如 A 项目用 PHP-CS-Fixer v3.12，B 项目用 v3.20），全局装一个就冲突
- CI/CD 流水线里如果依赖全局命令，而构建镜像没预装，就会失败；项目内装则靠
composer install自动拉取，更可靠 -
composer.lock只管项目依赖，不管全局工具——这意味着团队成员之间全局工具版本可能天差地别
什么该全局装，什么必须项目内装？
一句话：**工具装全局，依赖装项目**。这不是风格偏好，是职责隔离。
- 该全局装的：
laravel/installer、friendsofphp/php-cs-fixer、phpstan/phpstan、psy/psysh—— 它们不参与业务逻辑，只服务开发过程 - 必须项目内装的：
guzzlehttp/guzzle、monolog/monolog、symfony/console—— 这些是代码运行时真正调用的，要进composer.json，要提交composer.lock，要上生产环境 - 特别注意：
phpunit/phpunit看似是工具，但很多项目在autoload-dev中引用它，且测试脚本可能依赖特定版本，所以更推荐项目内安装
常见错误：PATH 没配好 + 版本混用
最常遇到的两个问题不是“不会装”，而是“装了却用不了”或“用了却出错”。比如：
- 全局装了
php-cs-fixer，但执行时报PHP Fatal error: Uncaught Error: Class 'Symfony\Component\Console\Application' not found—— 很可能是另一个全局包（如symfony/console）版本不兼容，或者 Composer 自身用了旧版 autoload - 在项目里执行
composer global require phpunit/phpunit，结果发现phpunit命令能跑，但项目里./vendor/bin/phpunit却报错：找不到phpunit/phpunit的类 —— 因为全局装的跟项目无关，项目仍需自己require - Mac 用户升级 macOS 后，发现
composer global报错Permission denied：很可能是~/.composer所在目录权限变了，需sudo chown -R $(whoami) ~/.composer
真正容易被忽略的点是：全局安装看似省事，但它绕过了 Composer 最核心的价值——依赖锁定与可复现性。工具类可以容忍版本漂移，但项目依赖不行。所以哪怕多打几个字，也优先让 composer require 出现在你的日常操作里。
