全局与项目依赖冲突源于同一库的不同版本被同时加载，导致类找不到或函数重复定义。应优先在项目中本地安装工具，使用 vendor/bin 下的可执行文件，避免全局依赖；若需全局使用，应定期清理并统一版本，或采用 Phive、Docker 等隔离方案，确保环境纯净。
当使用 Composer 管理 PHP 项目时，全局安装的包与项目内依赖版本不一致，可能会导致类找不到、函数重复定义或版本兼容问题。这类冲突的核心在于：全局包和项目依赖可能加载了不同版本的同一库，而 PHP 只能加载其中一个。
理解冲突来源
Composer 全局安装的包（如通过 composer global require 安装）会放在系统级的 vendor 目录中，通常位于用户主目录下（如 ~/.composer/vendor）。这些包在命令行中可直接调用，比如 Laravel Installer、PHP-CS-Fixer 等。但当项目中通过 composer require 引入相同包的不同版本时，自动加载机制可能出现混乱。
red">典型表现：- 运行命令时报错“Class not found”
- 提示函数已定义（Cannot redeclare）
- 行为异常，实际执行的是旧版本代码
隔离全局与项目依赖
最稳妥的做法是避免全局和项目共用同一包。对于开发工具类包，优先使用项目本地安装，然后通过 vendor/bin 调用。
建议做法：- 将常用工具安装在项目中：composer require --dev friendsofphp/php-cs-fixer
- 运行时使用 ./vendor/bin/php-cs-fixer 而非全局命令
- 借助 Makefile 或 scripts 字段简化调用
这样能确保每个项目使用自己锁定的版本，不受全局环境干扰。
清理并统一全局环境
如果仍需使用全局包，应定期检查并清理过时依赖。
操作步骤：
- 查看全局已安装包：composer global show
- 卸载冲突包：composer global remove 包名
- 重新安装所需版本：composer global require 包名:^2.0
注意：全局 composer.json 位于 ~/.composer/composer.json，可手动编辑后执行 global install 更新。
使用独立工具管理器替代全局 Composer
为避免全局污染，推荐使用专用工具管理 CLI 工具，例如：
- Phive：专用于管理 PHAR 包，隔离性好
- Tools like Laragon 或 Docker：在容器或独立环境中运行工具
这些方式能彻底规避 Composer 自动加载交叉问题。
基本上就这些。关键在于减少对全局 Composer 包的依赖，优先让项目自给自足，工具版本随项目走，才能避免冲突。
