PHP环境必须达标（≥7.3且启用openssl/curl/mbstring/json/zip扩展），再通过三步校验安装Composer官方脚本，禁用系统源安装，确保使用v2版本，并在项目目录下执行composer install。
确认PHP环境是否达标，否则装了也跑不起来
Composer不是独立程序，它本质是PHP脚本，必须依赖PHP CLI环境。CentOS上常见坑是：系统自带的PHP版本太老（如5.4）、缺关键扩展、或php命令根本不在PATH里。
- 先执行
php -v，确保输出 ≥ 7.3（Laravel 8+ 等主流框架已要求） - 检查必需扩展是否启用：
php -m | grep -E 'openssl|curl|mbstring|json|zip'—— 少一个都可能在后续composer install时报错 - 如果提示
command not found: php，说明PHP没装或没加到PATH，别急着装Composer，先解决PHP路径问题
用官方脚本安装最稳，但跳过校验等于埋雷
直接curl -sS https://getcomposer.org/installer | php看着快，但一旦中间被劫持或CDN缓存污染，下载到的是恶意脚本——这不是理论风险，2025年已有真实案例。
- 务必分三步走：
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"→ 用hash_file('sha384', 'composer-setup.php')比对官网最新SHA-384值 → 确认后才执行php composer-setup.php - 安装完立刻删掉临时文件：
php -r "unlink('composer-setup.php');"，避免残留可执行脚本 - 全局软链用
sudo mv composer.phar /usr/local/bin/composer，别用ln -s，防止权限继承混乱
CentOS 7/8/9 包管理器安装看似省事，实则隐患最多
虽然sudo yum install composer或dnf install composer能一键装上，但CentOS官方源里的Composer版本通常滞后1–2年，且不带自动更新机制。
- CentOS 7默认仓库里还是Composer v1，而v1已于2022年停止维护，v2才支持PHP 8+和现代依赖解析算法
- 装完运行
composer --version，如果显示1.x，请立刻卸载：sudo yum remove composer，再走官方脚本流程 - 想图省事？可以加EPEL源后装，但依然要手动
composer self-update升到v2，否则遇到Package manifest version mismatch类错误只能重装
装完就跑composer install？先看当前目录有没有composer.json
很多人连cd /www/wwwroot/your-site都没进，就在根目录敲composer install，结果报No composer.json present还反复重试。
- Composer不是服务器级工具，它是项目级依赖管理器——没有
composer.json，它什么也干不了 - 宝塔用户注意：
putenv函数常被禁用（安全策略），会导致composer install卡在“Loading composer repositories”不动，需进宝塔PHP设置里手动放开 - 第一次部署建议加
--no-dev参数：composer install --no-dev --optimize-autoloader，既跳过开发依赖，又生成高效autoload映射，避免线上环境加载测试类报错
composer --version，也不确认php -m里有没有openssl——这两步跳过，后面所有报错基本都白查。 
