全局插件装在~/.composer/vendor/bin（Linux/macOS）或%APPDATA%\Composer\vendor\bin（Windows），具体路径须执行composer global config bin-dir --absolute获取，且该路径必须加入系统PATH才能调用命令。
全局插件装在哪？先搞清 Composer 的全局 bin 目录
Composer 全局安装的插件（比如 laravel/installer、phpunit/phpunit）实际是通过 composer global require 装到用户家目录下的 ~/.composer/vendor/bin/（Linux/macOS）或 %APPDATA%\Composer\vendor\bin（Windows）。这个路径必须在系统 $PATH 里，否则命令找不到。
执行 composer global config bin-dir --absolute 可直接输出当前生效的全局 bin 路径，别依赖记忆或文档默认值——不同 PHP 版本或 Composer 配置可能改变它。
- 如果
which laravel或where laravel找不到命令，八成是bin-dir没加进$PATH -
composer global config --list能看到所有全局配置，重点关注bin-dir和home - Windows 用户注意：PowerShell 和 CMD 的
$PATH修改方式不同，改完要新开终端
怎么查已安装的全局插件？用 composer global show
composer global show 是唯一可靠的方式列出所有全局 require 的包，它读的是 ~/.composer/composer.json，不是当前项目文件。不加参数时显示包名、版本、描述；加 -i 可看详细信息（含依赖树）。
常见误区：有人在项目根目录下跑 composer show，结果只看到本地依赖——那跟全局插件完全无关。
- 想筛选特定包：用
composer global show | grep "laravel"（Linux/macOS）或composer global show | findstr "laravel"（Windows） - 包名显示为
laravel/installer，但可执行文件名通常是laravel，二者不总一致 -
composer global list已废弃，别用；composer show -g在新版 Composer 中也不支持
升级或卸载全局插件时，为什么经常出错？
全局插件升级失败（如 composer global update laravel/installer 报 Root composer.json requires ...）通常是因为：Composer 尝试把全局依赖当作“根项目”来解析，而 ~/.composer/composer.json 可能有冲突的约束或过时的 platform config。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
最稳的操作是显式指定操作范围：
- 升级单个包：
composer global require laravel/installer:^4.0 --update-with-dependencies（强制重装并更新依赖） - 卸载：
composer global remove laravel/installer（别用rm -rf直删 vendor 目录，会残留 bin 文件和 autoload） - 如果
global update卡住，先composer global config platform.php 8.1.0对齐当前 PHP 版本，再重试
为什么 composer diagnose 不报全局环境问题？
composer diagnose 默认只检查当前目录的 composer.json 和本地配置，**完全不扫描全局环境**。它说 “OK”，不代表全局插件能正常运行。
真正要验证全局状态，得组合几个命令：
- 检查 bin 是否可达：
ls -l $(composer global config bin-dir --absolute)（Linux/macOS） - 验证可执行文件是否链接正确：
composer global show -s | head -5看有没有 “command not found” 类错误 - PHP 扩展缺失常导致全局命令启动即挂，比如
phpunit缺xml扩展，此时运行phpunit --version才暴露问题
全局插件的生命周期独立于任何项目，它的依赖解析、autoload 加载、二进制链接全由 ~/.composer/ 下的配置驱动——这点和本地开发习惯相反，容易被忽略。
