如何通过Composer Global机制防止全局包被局部修改而造成污染？

本文共计742个文字，预计阅读时间需要3分钟。

突然不是因为装了两次，而是因为+PHP+自动加载器在运行时只能加载一个版本的类。当使用+composer global require+和+composer require+同时引入+symfony/console（例如v5和v6）时，由于两个环境都通过同一CLI PHP进程加载，可能会导致+Class not found或+Cannot redeclare错误。这不是Composer的bug，而是自动加载机制的自然限制。

哪些工具真该用 global，哪些必须进项目

判断标准只有一条：它是否参与项目代码的运行逻辑。

• ✅ 适合 global：纯命令行工具，不被项目代码 require 或 autoload，比如 laravel/installer、deployer/deployer
• ⚠️ 强烈建议进项目：测试类库（如 phpunit/phpunit）、静态分析（如 phpstan/phpstan）、格式化（如 friendsofphp/php-cs-fixer）——它们常被 phpunit.xml、CI 脚本或 composer.json 的 scripts 字段直接调用，且版本敏感
• ❌ 绝对禁止 global：任何运行时依赖，如 guzzlehttp/guzzle、monolog/monolog。全局安装会让 composer.lock 失效，部署时行为不可控

PATH 配置不到位，global 就等于没装

composer global require 成功后命令仍报 command not found，90% 是因为 ~/.composer/vendor/bin（Linux/macOS）或 %APPDATA%\Composer\vendor\bin（Windows）没加进系统 PATH。

• macOS/Linux：确认改的是当前 shell 的配置文件（zsh 改 ~/.zshrc，bash 改 ~/.bash_profile），加完必须 source ~/.zshrc 或新开终端
• Windows：在「系统属性 → 环境变量」中添加完整路径（不能用 %APPDATA% 变量），添加后重启终端
• 验证方式：which laravel（有输出才算成功）；echo $PATH 确认路径已包含

卸载 global 包后命令还在？这是最常漏掉的两步

执行 composer global remove vendor/package-name 后，laravel 命令还能运行，说明残留未清干净。

• 第一步：手动删 ~/.composer/vendor/bin/laravel（Linux/macOS）或 %APPDATA%\Composer\vendor\bin\laravel.bat（Windows）——remove 不保证清理 bin 目录
• 第二步：必须运行 composer global dump-autoload，否则旧的类映射仍在 ~/.composer/vendor/composer/autoload_psr4.php 里，PHP 仍会按错误路径加载
• 验证是否清干净：which laravel 应无输出；laravel --version 应报 command not found

真正麻烦的从来不是装不上，而是装上了却不知道它正在悄悄覆盖项目里的同名类。隔离的关键不在“装在哪”，而在“谁加载谁”。