composer global require用于安装全局CLI工具，如phpunit、phpstan等开发辅助工具，而非共享项目依赖。它将工具安装至用户目录的vendor中，并通过PATH调用，适用于多项目共用的命令行工具，但不可用于替代项目本地依赖，避免版本冲突与环境不一致问题。
在使用 PHP 开发时，Composer 是管理项目依赖的核心工具。但很多人会误以为可以像 Node.js 的 npm 一样通过全局命令安装包并供所有项目使用。实际上，Composer 的设计哲学是“每个项目独立管理依赖”，但这并不意味着完全不存在“全局”使用的场景。正确理解 composer global require 的用途和限制，对多项目环境下的工具管理尤为重要。
什么是 composer global require？
composer global require 并不是用来管理多个项目的“共享依赖”的，而是用于安装那些你希望在系统命令行中全局可用的 CLI 工具类库。这些工具通常不参与具体项目的业务逻辑，而是辅助开发、调试或部署。
执行该命令后，Composer 会将包安装到用户主目录下的一个全局 vendor 目录中（通常是 ~/.composer/vendor 或 ~/.config/composer/vendor），同时把可执行文件链接到 ~/.composer/vendor/bin。你需要确保这个路径已加入系统的 PATH 环境变量，才能在任意位置调用这些命令。
适用场景：哪些工具适合全局安装？
以下类型的工具适合使用 global require 安装：
- PHP 代码质量工具：如 phpunit/phpunit（测试）、phpstan/phpstan（静态分析）、psalm/psalm、squizlabs/php_codesniffer
- 依赖安全扫描器：如 friendsofphp/security-advisories、localheinz/composer-security-checker
- 项目脚手架工具：如 laravel/installer、symfony/cli
- 代码格式化工具：如 fabpot/php-cs-fixer
- 依赖管理辅助工具：如 bamarni/composer-bin-plugin（用于隔离不同用途的依赖）
这些工具的共同点是：你在多个项目中都会用到，且以命令行方式运行，不作为项目代码的一部分被引用。
为什么不推荐用 global 来“共享”项目依赖？
试图用全局依赖来避免在每个项目中重复安装相同的库（比如 monolog/monolog 或 guzzlehttp/guzzle）是一种常见误解。这种做法存在严重问题：
- 版本冲突：不同项目可能需要同一库的不同版本，全局只能保留一个版本
- 不可移植：项目无法在没有预先配置全局环境的机器上正常工作
- 破坏依赖隔离：项目不再自包含，违背 Composer 的设计理念
- 部署风险：生产环境通常不会安装全局包，导致运行失败
正确的做法始终是在每个项目的 composer.json 中声明所需依赖，让 Composer 在本地 vendor/ 目录中独立安装。
最佳实践建议
合理使用全局命令的关键在于明确区分“开发工具”和“项目依赖”：
- 只将 CLI 工具类库安装到全局
- 确保 ~/.composer/vendor/bin 加入 PATH
- 定期运行 composer global update 更新工具，但注意版本兼容性
- 使用 composer global status 检查全局依赖状态
- 避免在 CI/CD 脚本中依赖全局安装，应在任务中显式安装所需工具
对于需要在多个项目中复用的私有组件，应考虑构建私有 Packagist 仓库或使用 git submodules + Composer path repositories，而不是依赖全局机制。
基本上就这些。Composer 的 global 功能是一个便利的开发者工具管理手段，但绝不能替代项目级的依赖管理。理解这一点，才能在多项目环境中高效又安全地使用 Composer。
