全局与项目依赖冲突本质是PHP自动加载器运行时只能加载一个版本的类，导致Class not found或Cannot redeclare；根源在于同一CLI进程下全局v5与项目v6的symfony/console等库发生加载竞争。

全局包和项目依赖冲突的本质是什么

冲突不是因为“装了两次”，而是 PHP 自动加载器在运行时只能加载一个版本的类。当 composer global require 和项目 composer require 同时引入 symfony/console（比如 v5 和 v6），而两个环境又通过同一 CLI PHP 进程加载，就可能触发 Class not found 或 Cannot redeclare。这不是 Composer 的 bug，是自动加载机制的天然限制。

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

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

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• ✅ 适合 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

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