composer需先系统级安装才能用global命令；全局包命令不可用因~/.composer/vendor/bin未加入path；全局配置应通过composer config -g操作，而非手动编辑文件。
全局安装 Composer 为什么不能直接 composer global install
因为 composer global 不是安装命令，而是管理「全局依赖包」的子命令；Composer 本身必须先在系统级安装好，才能用它装别的包。很多人卡在这步，输完 composer global require laravel/installer 却提示 command not found: composer，说明根本没装上 Composer 本体。
正确做法是下载官方安装脚本，配合 PHP CLI 执行：
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === 'e0012edf3e80b6978849f5eff0d4b4e4c79ff1609dd1f6cb2a50eb2c5c5712b0c2633355f4a141f4710822e71d551459c32') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer
- 第三行的 SHA384 哈希值要和 官网最新版 对得上，过期了会报
Installer corrupt -
--install-dir必须是$PATH中的路径，/usr/local/bin最稳妥；写成~/bin很可能不生效 - macOS 如果用 Homebrew 装过 PHP，优先走
brew install composer，更省事且自动处理 PATH
全局配置 composer.json 存在哪、怎么改
Composer 全局配置不是靠编辑某个文件实现的，而是通过 composer config 命令写入用户级配置文件，位置固定：~/.composer/config.json（Linux/macOS）或 %APPDATA%\Composer\config.json（Windows）。直接手改容易格式出错，建议全用命令操作。
- 设默认仓库（比如切国内镜像）：
composer config -g repo.packagist composer https://packagist.phpcomposer.com - 加认证令牌（用于私有包）：
composer config -g http-basic.bitbucket.org username token - 禁用插件自动加载（避免某些全局包干扰项目）：
composer config -g disable-tls false（注意这是反直觉的：设为false才启用 TLS，true反而禁用）
执行后立刻生效，不用重启终端。但要注意：-g 参数漏掉就变成改当前项目的 composer.json，白忙活。
composer global require 安装的包为什么找不到命令
因为 Composer 全局 bin 目录默认是 ~/.composer/vendor/bin，这个路径不在系统 $PATH 里。装完 laravel/installer 或 phpunit/phpunit 后输 laravel 报 command not found，十有八九是这问题。
- 查当前全局 bin 路径：
composer global config bin-dir --absolute - 把它加进 shell 配置（如
~/.zshrc或~/.bashrc）：export PATH="$HOME/.composer/vendor/bin:$PATH" - 重载配置：
source ~/.zshrc（macOS Catalina+ 默认 zsh） - 验证：
echo $PATH看是否含该路径，再试which laravel
Windows 用户注意：composer global config bin-dir --absolute 输出的是类似 C:\Users\Name\AppData\Roaming\Composer\vendor\bin 的路径，需手动加到系统环境变量 PATH 中，且路径分隔符必须用 ;，不能用 :。
全局包和项目本地包混用时的冲突风险
全局装的 phpunit/phpunit 和项目 require-dev 里声明的版本可能打架。Composer 不会帮你做版本对齐，运行 phpunit 时到底调哪个，取决于 $PATH 里谁排前面、以及项目是否用了 ./vendor/bin/phpunit 显式调用。
- 项目内优先用本地 bin：
./vendor/bin/phpunit永远比全局phpunit可靠 - 全局包尽量只装「工具类」且不常更新的，比如
laravel/installer、deployer/deployer；别全局装monolog/monolog这种库 - 升级全局包前先
composer global outdated，避免跳大版本导致命令签名变化（比如phpunit9.x → 10.x 移除了--colors参数）
最麻烦的情况是：全局装了旧版 symfony/console，又在项目里 require 了新版，某些全局命令内部依赖它，就可能报 Class not found —— 这类问题没有银弹，只能靠 composer global show 逐个排查依赖树。
