答案是PHP CLI环境缺失指定扩展，需通过php -r和php --ini验证真实状态，再按系统安装对应包（如Ubuntu用php8.2-zip、CentOS 7用php-pecl-zip）、检查libzip版本≥1.6.0及系统unzip命令，并重启终端验证。
composer install 报 “ext-xxx is missing” 是锁文件在验证环境
这不是 composer.lock 文件本身“找不到扩展”，而是 Composer 在执行 install 时，用它来核对当前 PHP CLI 环境是否满足所有已锁定包的运行前提。报错里写的 ext-zip、ext-swoole 或 ext-sockets，是 composer.lock 中某个包（比如 laravel/framework 或 php-amqplib/php-amqplib）明确声明的硬性依赖，缺一个就卡住。
先确认 CLI 真实加载状态，别信报错文字或 php.ini 里的注释
报错说缺 ext-gd，不代表它真没装——可能只是没被 CLI 加载。必须用命令直接验：
-
php -r "var_dump(extension_loaded('gd'));"—— 输出bool(false)才算坐实缺失 -
php --ini—— 查清 CLI 实际读的是哪个php.ini（常见坑：MAMP/宝塔有php.ini和php-cli.ini两个文件，你改了 Web 版的，CLI 还是老样子） -
php -m | grep -E "zip|gd|sockets|swoole"—— 一次性扫多个关键扩展，漏一个都可能让install失败
按系统装对包名，CentOS 和 Ubuntu 的命名规则完全不同
装错包名 = 白干。不同系统扩展包名差异极大，且 PHP 版本号常要显式带上：
- Ubuntu/Debian：
sudo apt install php8.2-zip（不是php-zip，版本号必须匹配php -v输出） - CentOS/RHEL 7：
sudo yum install php-pecl-zip（不是php-zip；pecl-前缀是重点） - CentOS/RHEL 8+：
sudo dnf install php-zip - macOS + Homebrew：
brew install php@8.2-swoole，再手动检查php.ini是否含extension="swoole.so" - Windows：
php.ini里取消;extension=php_swoole.dll的分号，并确认php_swoole.dll真在extension_dir指向的目录中
装完不生效？这些静默失效点最常被忽略
扩展显示已安装，但 composer install 仍报错，大概率是下面某处断链：
- Linux 下装了
php8.2-zip，但没新开终端——旧 shell 缓存着旧的php -m结果，新模块不会自动刷进去 - PHP 8.0+ 要求
libzip≥ 1.6.0，CentOS 7 自带 0.10，即使extension=zip加载成功，解压时也会崩溃；查版本：pkg-config --modversion libzip - Docker 中只装了
php8-zip，但没装系统级unzip命令（apk add unzip），Composer 默认优先调它，报unzip not found - 宝塔或 MAMP 等多版本共存环境，改了 A 版本的
php-cli.ini，但composer实际调用的是 B 版本的 PHP —— 运行composer show --platform | grep php确认它用的是哪个 PHP
真正卡住的地方，往往不在扩展有没有装，而在 CLI PHP 到底读了哪份配置、用了哪个 libzip、有没有新 shell 刷新模块列表——这些细节一错，composer.lock 就永远过不去校验这关。
