composer global require 将包安装到当前用户主目录下的 Composer 全局目录：Linux/macOS 为 ~/.composer/vendor/（可执行文件在 ~/.composer/vendor/bin/），Windows 为 %APPDATA%\Composer\vendor\（可执行文件在 %APPDATA%\Composer\vendor\bin\），路径可通过 composer config --global home --absolute 和 composer config --global bin-dir --absolute 确认，不涉及系统级路径或跨用户共享。
composer global require 安装的包只对当前用户生效，不涉及系统级权限或所有用户共享，也不是“全系统安装”——它只是用户主目录下的 Composer 全局 vendor 环境。
global require 实际安装到哪？
它把包放进用户主目录下的 Composer 全局目录，路径由 COMPOSER_HOME 决定，默认是：
- Linux/macOS：
~/.composer/vendor/（可执行文件在~/.composer/vendor/bin/） - Windows：
%APPDATA%\Composer\vendor\（可执行文件在%APPDATA%\Composer\vendor\bin\）
你可以用这两条命令确认真实路径：
composer config --global home --absolute<br>composer config --global bin-dir --absolute
注意：composer global require 不会写入 /usr/local/bin 或 C:\Windows\System32 这类系统级路径，也不需要管理员权限（除非你误加了 sudo）。
为什么 root 用户或其它用户都用不了你装的 global 包？
因为 global 作用域严格绑定当前 shell 用户的家目录和环境变量。常见错误现象：
- 你在自己的终端里运行
composer global require laravel/installer成功，但切换到sudo -i或另一个用户账号后，laravel命令直接报command not found - CI/CD 流水线用
www-data或jenkins用户跑脚本，即使全局装过phpstan，也会提示未找到命令
根本原因：PATH 只对你当前用户的 shell 配置生效（比如 ~/.zshrc），其它用户没有加载你的 PATH，也没有访问你的 ~/.composer 目录权限。
能绕过用户隔离、实现真系统级安装吗？
不能，也不该这么做。Composer 的 global 机制本身就不支持跨用户或 root 级部署。强行用 sudo composer global require 会导致：
-
~/.composer所属用户变成root，后续你自己的普通用户无法写入或更新 - 必须每次用
sudo才能global update或global remove，极易出错 - 破坏 Composer 的 autoload 自动发现逻辑，
composer global exec可能失败
如果你真需要多用户可用的 CLI 工具（比如公司内部统一 PHP-CS-Fixer 版本），正确做法是：
- 用包管理器安装（如 macOS 上
brew install php-cs-fixer） - 下载预编译二进制并放至
/usr/local/bin/ - 在 CI/CD 中显式指定工具路径，而不是依赖 global PATH
global require 和项目 require 的范围冲突怎么处理？
它们完全不重叠，但也完全不互通：
- 项目里
composer require phpunit/phpunit→ 装在./vendor/，只能通过./vendor/bin/phpunit或composer exec phpunit调用 - 全局
composer global require phpunit/phpunit→ 装在~/.composer/vendor/，只有加了~/.composer/vendor/bin到 PATH 后才能直接敲phpunit
关键点：同一个包，本地和全局可以共存不同版本，互不影响。但如果你同时装了，终端优先调用的是 PATH 里排在前面的那个 phpunit —— 所以建议只保留一种使用方式，避免混淆。
最容易被忽略的一点：global 安装不是“一次配置，永久生效”。换一台机器、重装系统、改用 zsh/bash、甚至升级 Shell（比如 macOS 从 bash 切到 zsh），PATH 都得重新配一遍；而 composer global exec 这种补救方案，每次都要多打一串前缀，反而掩盖了 PATH 配置缺失的本质问题。
