composer全局安装仅适用于cli工具，将包装入用户目录下的~/.composer/vendor（linux/macos）或%appdata%\composer\vendor（windows），其可执行文件软链接至对应vendor/bin目录，必须手动将该bin路径加入系统path才能调用命令。
Composer 全局依赖只适合装 CLI 工具，不是共享库的方案；装错包或 PATH 没配对，命令就一定找不到。
composer global require 实际做了什么
它把包安装到 ~/.composer/vendor（Linux/macOS）或 %APPDATA%\Composer\vendor（Windows），再把包 bin 字段声明的可执行脚本软链接到对应 vendor/bin/ 目录下。这些软链接才是你终端里能直接敲的命令，比如 phpunit 或 laravel。
- 不修改系统 PATH，这些软链接永远进不了 shell 的搜索路径
- 没有
composer global这个独立命令——只有composer global require、composer global list等子命令 - 全局安装不参与项目 autoload，所以别指望用
new PHPUnit\Framework\TestCase()—— 它压根不是为运行时类设计的
PATH 配不对我就找不到命令
这是 90% 的“command not found”问题根源。必须手动把全局 bin 目录加进系统 PATH：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Linux/macOS：在
~/.zshrc或~/.bashrc末尾加export PATH="$HOME/.composer/vendor/bin:$PATH"，然后运行source ~/.zshrc - Windows：打开「系统属性 → 高级 → 环境变量」，在用户或系统 PATH 中添加
%APPDATA%\Composer\vendor\bin - 如果你改过
COMPOSER_HOME（如用composer config --global home /opt/composer），那 bin 路径就是/opt/composer/vendor/bin，PATH 也得同步改 - 验证是否生效：
echo $PATH（macOS/Linux）或echo %PATH%（Windows），确认路径已出现
哪些包能装？哪些绝对不能碰
只装真正需要跨项目调用、且本身提供命令行入口的工具：
- ✅ 推荐：
phpunit/phpunit（phpunit）、phpstan/phpstan（phpstan）、laravel/installer（laravel）、symfony/cli（symfony）、fabpot/php-cs-fixer（php-cs-fixer） - ❌ 禁止：
monolog/monolog、guzzlehttp/guzzle、doctrine/dbal—— 它们没提供可执行文件，装了只是污染全局 autoload 和 vendor，还可能引发版本冲突 - ⚠️ 注意：有些包虽有 bin，但实际是开发辅助脚本（如某些包带
bin/console），不属于通用 CLI 工具，也不该全局装
装错了怎么安全清理
全局安装没有“卸载”命令，硬删文件容易残留软链接或 autoload 映射：
- 先删
~/.composer/composer.json里的对应行：sed -i '/"phpunit\/phpunit"/d' ~/.composer/composer.json（Linux/macOS） - 再强制重建全局 vendor：
composer global update—— 这会按新composer.json重装所有包，旧二进制文件自动消失 - 别直接
rm -rf ~/.composer/vendor：这会让所有全局命令立刻失效，且composer global list仍显示已安装，造成误导 - 如果 PATH 里还留着旧 bin 路径，即使包已删，shell 仍可能缓存旧命令路径，建议清理后新开终端验证
最易被忽略的是 COMPOSER_HOME 变更后 PATH 忘同步更新，以及误把 require-dev 类工具当全局 CLI 工具装——这两处一旦出错，调试成本远高于重装。
