composer 必须手动安装，因包管理器提供的 1.x 版本不支持 ^2.5 依赖、php 8.2+ 及包签名校验，且缺失扩展提示与更新能力。
composer 必须手动安装到 Linux，用 apt install composer 或 yum install composer 装出来的几乎肯定不能用——它大概率是 1.x 版本，不支持 ^2.5 这类依赖约束，也跑不动 PHP 8.2+ 项目，更不会校验包签名。
为什么不能直接用包管理器装
Ubuntu/Debian 仓库里的 composer 通常卡在 1.10.22；CentOS/RHEL 更老，甚至缺 php-zip 扩展支持。这类旧版：
- 解析不了 composer.json 中的 platform-check 或 conflict 块
- composer install 时静默失败，报错却是 Class 'ZipArchive' not found（其实是因为没启用扩展，但旧版不提示）
- 不支持 self-update --stable，也没法切到 2.x 稳定通道
正确安装步骤（含校验和权限修复）
官方安装脚本生成的是 composer.phar，核心流程是「下载 → 校验 → 执行 → 移动 → 设权」，漏任何一环都可能后续出无声故障：
- 先确保 PHP 扩展就位：
sudo apt install -y php-cli php-zip php-json php-mbstring php-xml php-phar（Ubuntu）或sudo dnf install -y php-cli php-zip php-json php-mbstring php-xml php-phar（RHEL 8+） - 进临时目录下载并校验（防中间人攻击）：
cd /tmp<br>curl -sS https://getcomposer.org/installer -o composer-setup.php<br>HASH=$(curl -sS https://composer.github.io/installer.sig)<br>php -r "if (hash_file('sha384', 'composer-setup.php') === '$HASH') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;" - 执行安装：
sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer - 删掉临时文件：
rm composer-setup.php - 若
composer --version报Permission denied，补权限：sudo chmod +x /usr/local/bin/composer
PATH 不生效？这是最常卡住的环节
/usr/local/bin 默认在多数发行版的 PATH 里，但最小化系统、Docker 容器或某些定制镜像会删掉它。不报错，只是命令找不到：
- 检查是否在路径中：
echo $PATH | grep -o '/usr/local/bin'—— 没输出就说明没加载 - 临时加进去：
export PATH="/usr/local/bin:$PATH" - 永久生效需写入 shell 配置（如
~/.bashrc或/etc/profile），但别直接改/etc/profile，除非你清楚后果
国内用户必须配镜像源，否则大概率超时失败
默认走 packagist.org，国内直连基本不可用。不配镜像，composer require monolog/monolog 可能卡死半小时后报 failed to open stream: Connection timed out：
- 全局配置阿里云镜像（推荐）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 如果已用过旧镜像（比如
packagist.phpcomposer.com），先取消：composer config -g --unset repos.packagist - 验证是否生效：
composer config -g repo.packagist应输出阿里云地址
真正容易被忽略的不是命令怎么敲，而是校验哈希那一步——跳过它，等于把执行权交给未经验证的远程脚本；还有就是 php-zip 扩展，它不报错，但所有解压操作都会挂，问题现象和原因完全对不上。
