composer 不能真正“全局安装”，它只是被系统 path 找到的可执行文件；下载的 composer.phar 需手动移至 path 目录（如 /usr/local/bin）、赋予执行权限并确保 php 可用，缺一不可。
Composer 不能真正“全局安装”——它只是被系统 PATH 找到的可执行文件，安装位置和配置方式决定你能否在任意目录用 composer 命令。
为什么 curl -sS https://getcomposer.org/installer 默认不等于全局可用
这个命令只把 composer.phar 下载到当前目录，比如 ./composer.phar。它本质是个 PHP 归档文件，没加执行权限，也没放进系统路径里。直接运行 php composer.phar 可以，但输 composer 肯定报 command not found。
- 常见错误现象：
bash: composer: command not found，哪怕你刚跑完安装脚本 - 真正要做的：把
composer.phar放进一个被$PATH包含的目录，并确保有执行权限 - 推荐位置：
/usr/local/bin/composer（macOS/Linux）或C:\ProgramData\ComposerSetup\bin\composer.bat（Windows 官方安装器默认走这路径） - 别放
~/bin或./下就以为“全局”了——那些目录不一定在$PATH里
Linux/macOS 手动配置全局 composer 命令
核心是两步：下载 + 移动 + 赋权。跳过任何一步都会失败。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 执行
sudo curl -sS https://getcomposer.org/installer | sudo php -- --install-dir=/usr/local/bin --filename=composer（一行搞定，--install-dir和--filename缺一不可） - 验证是否生效：
which composer应输出/usr/local/bin/composer；composer --version不报错才算成功 - 如果提示
Permission denied，不是 Composer 问题，是/usr/local/bin写入权限不足——改用~/.local/bin并确保它在$PATH前置（比如在~/.zshrc里加export PATH="$HOME/.local/bin:$PATH"） - 别用
alias composer="php /path/to/composer.phar"代替——某些工具（如 Laravel Installer、Docker 中的脚本）会绕过 alias，必须是真实可执行文件
Windows 上“全局”的实际含义和陷阱
Windows 没有 PATH 自动继承的惯性思维，所谓“全局”依赖两个条件同时满足：文件在 PATH 目录下 + 有对应 .bat 封装。
- 官方 Windows 安装器（Composer-Setup.exe）会自动做三件事：下载
composer.phar、生成composer.bat、把安装目录加进系统 PATH——这是最省心的方式 - 手动安装时，如果只放
composer.phar到C:\tools，但没配 PATH，或没建composer.bat（内容仅一行：@php "%~dp0composer.phar" %*），composer命令依然无效 - PowerShell 用户注意：
composer在 CMD 能用不代表 PowerShell 立刻能用——重启终端或运行$env:PATH = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User")刷新 - WSL 用户请按 Linux 方式处理，不要混用 Windows 的 Composer 安装路径
PATH 配置是否生效、.bat 文件是否存在、PHP 是否在系统中可用——这三个点只要漏掉一个，composer 就永远只是当前目录下的一个普通文件。很多人卡在“明明装了却用不了”，问题几乎全出在这三层里。
