composer 不能用 composer install 安装自身，因其仅用于安装项目依赖；正确方式是下载官方 phar 脚本（linux/macos 用 curl + php）、运行安装程序（windows）或通过包管理器（如 apt，但版本滞后）。
Composer 安装命令为什么不能直接用 composer install
因为 composer install 是用来安装项目依赖的，不是安装 Composer 自身。想装 Composer，得用官方提供的下载脚本或包管理器——它本身是个 PHAR 文件，不是靠 Composer 命令装出来的。
常见错误是运行 composer install 后报错 Command "install" is not defined 或提示未找到 composer.json，这说明当前目录没项目，也暴露了对命令用途的误解。
- Linux/macOS 推荐执行：
curl -sS https://getcomposer.org/installer | php，然后把生成的composer.phar移到/usr/local/bin/composer（需sudo） - Windows 用户直接下载
Composer-Setup.exe，它会自动探测 PHP 路径并配置全局命令 - 某些 Linux 发行版（如 Ubuntu）可通过
apt install composer安装，但版本常滞后，不建议用于生产环境
如何判断本地 Composer 是否需要更新
Composer 有内置更新机制，但不会自动提醒。运行 composer --version 可看到当前版本号和发布日期；若日期早于官网首页显示的最新稳定版（https://getcomposer.org/），就该更新了。
注意：Composer 的 self-update 命令只更新自身，不更新已安装的包，这点和 npm update -g npm 类似，但行为更保守。
- 普通用户运行
composer self-update即可升级到最新稳定版 - 想升级到预发布版（如 RC 版），加
--snapshot参数：composer self-update --snapshot - 若提示
Permission denied，说明composer.phar不在可写路径，应改用sudo composer self-update（仅限全局安装场景） - CI/CD 环境中建议固定版本，用
composer self-update 2.5.8显式指定，避免因自动升级引入非预期变更
全局安装后 composer 命令仍不可用怎么办
本质是系统 PATH 没包含 Composer 所在目录。比如你把 composer.phar 放在 ~/bin/，但该路径未加入 shell 配置文件（~/.bashrc 或 ~/.zshrc）。
另一个常见原因是 Windows 上安装时勾选了 “Use Git Bash” 但没重启终端，导致 PATH 更新未生效。
- Linux/macOS：确认
which composer是否有输出；没有的话，在 shell 配置中追加export PATH="$HOME/bin:$PATH"并执行source ~/.zshrc - Windows：检查系统环境变量 PATH 是否含
C:\ProgramData\ComposerSetup\bin（默认安装路径），或重新运行安装程序并勾选 “Add to PATH” - 如果用的是 Homebrew 安装的 PHP，而 Composer 是手动下载的 PHAR，务必确保
php命令可用——composer本质是用 PHP 解释执行的，PHP 不在 PATH 会导致“command not found”假象
为什么 CI 流水线里总推荐用 php -d memory_limit=-1 composer.phar
因为 Composer 在解析依赖图、执行安装时内存消耗剧烈，尤其在大型项目中。默认 PHP 内存限制（常为 128M 或 256M）极易触发 Allowed memory size exhausted 错误。
这不是 Composer 的 bug，而是其依赖求解算法本身需要大量中间状态缓存。线上服务器可调高限制，但 CI 环境往往资源受限，所以更稳妥的做法是绕过限制而非盲目加大。
-
php -d memory_limit=-1 composer.phar install表示不限制内存，适合 CI - 若不允许无限内存，至少设为
-d memory_limit=2G，比默认值更安全 - Docker 场景下，可在
Dockerfile中写ENV COMPOSER_MEMORY_LIMIT=-1，这样所有composer命令都继承该设置 - 注意：本地开发一般不需要这么干，反而该保留限制来及早发现低效的
composer.json配置
composer，还是 composer 调用 PHP 去执行某个 PHAR；每层失败都会表现为不同错误，定位时得一层层剥开看。
