根本原因是PHP自动加载器只能加载一个版本的类，而全局与项目依赖可能引入同名库的不同版本，导致Class not found或Cannot redeclare；应优先本地安装工具并使用vendor/bin调用，避免全局依赖，必要时用Phive或Docker隔离。
全局包和项目依赖同时存在时，Composer install 为什么会报错
根本原因是 PHP 自动加载器只能加载一个版本的类，而全局安装的包（如 composer global require php-cs-fixer）和项目本地 composer.json 中声明的同名包（比如也 require 了 friendsofphp/php-cs-fixer）可能版本不一致。Composer 不会合并它们，运行时却可能混用 autoload 配置，导致 Class not found 或 Cannot redeclare。
如何确认是全局包引发的冲突
先排除本地环境干扰，再定位源头：
- 运行
composer global show，看是否装了和项目里同名或提供相同类的包（如phpunit/phpunit、symfony/console） - 临时重命名全局 vendor 目录（如
mv ~/.composer/vendor ~/.composer/vendor.bak），再跑composer install—— 如果成功，基本就是它 - 检查错误信息里是否出现来自
/home/xxx/.composer/vendor/...的路径，这是最直接证据
推荐做法：彻底停用全局命令，改用项目级调用
全局安装不是必须的，反而是多数冲突的起点。项目该用哪个版本，就让它自己管：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 卸载全局工具：
composer global remove friendsofphp/php-cs-fixer phpunit/phpunit - 在项目中本地安装：
composer require --dev friendsofphp/php-cs-fixer - 后续统一走
./vendor/bin/php-cs-fixer而非php-cs-fixer - 配合
scripts字段简化调用，例如在composer.json里加："scripts": {"cs-fix": "php-cs-fixer fix"}，然后运行composer cs-fix
如果非得保留全局安装，该怎么收敛风险
全局环境必须“干净且可控”，否则每次新项目都可能踩坑：
- 只装极少数真正跨项目的 CLI 工具（如
laravel/installer），且确保所有项目都兼容其版本 - 定期清理：
composer global update+composer global outdated，发现过期包立刻remove - 绝对不要在全局装开发类工具（如
phpstan、psalm、infection），它们对 PHP 版本和扩展敏感，极易与项目冲突 - 更稳妥的替代方案是用
phive安装 PHAR 包（如phive install php-cs-fixer），它不走 Composer autoloader，完全隔离
真正麻烦的不是“怎么装”，而是“谁在加载”。只要全局和项目共用同一个类名空间，哪怕版本号看着不冲突，自动加载顺序一变，行为就不可控。把工具下沉到项目层，才是可复现、可审计、可协作的底线。
