答案是PHP CLI环境未启用对应扩展，需用php -m验证、php --ini定位配置文件并启用extension=xxx.so或php_xxx.dll。
Composer install报“ext-xxx missing”其实是PHP扩展没加载，不是系统缺库
报错里带 ext-posix、ext-zip、ext-gd 这类提示，不是Linux没装libzip-dev或macOS没装pkg-config，而是PHP CLI根本没启用对应扩展。Composer只看php -m输出，不查系统包管理器。
- 先运行
php -m | grep zip，如果没输出，说明extension=zip没在php.ini里启用，而不是apt install libzip-dev没装 - Windows下确认
php.ini路径用php --ini，别改错XAMPP自带的php.ini（它常和CLI用的不是同一个） - Linux/macOS用
php-config --extension-dir查extension_dir是否指向真实.so文件所在目录，路径错会导致扩展加载失败但无报错
“cURL error 60: SSL certificate problem”大概率是系统时间歪了
这不是证书真过期，也不是CA证书缺失，而是本地系统时间比真实时间快或慢超过2分钟，导致OpenSSL校验HTTPS证书的notAfter字段失败。
- Linux/macOS执行
timedatectl status，看System clock synchronized是否为yes；不是就跑sudo timedatectl set-ntp true再sudo systemctl restart systemd-timesyncd - Windows执行
w32tm /resync，若报“service not started”，先net start w32time，再强制指定源：w32tm /config /syncfromflags:manual /manualpeerlist:"time.nist.gov" - 别用
composer config -g secure-http false硬绕——这解决不了时钟问题，反而掩盖真实故障点
“failed to open stream: Permission denied”基本是vendor/被root占了
错误行里出现vendor/autoload.php或composer.lock路径，说明写入失败，但原因90%不是权限不够，而是目录归属错了。
- 运行
ls -ld vendor/ composer.lock，如果显示root而不是当前用户，就是sudo composer install污染了目录 - 修复命令：
sudo chown -R $USER:$USER vendor/ composer.lock（macOS/Linux）或takeown /f vendor /r+icacls vendor /grant %USERNAME%:F /t（Windows） - 别
chmod 777——这治标不治本，还可能引发安全告警
镜像配置写了却没生效？检查repo.packagist拼写和斜杠
配置命令看似成功，但composer install -vvv日志里还是请求packagist.org，说明镜像根本没走成。常见坑就三个字：拼错、少斜杠、没加-g。
- 必须用单数
repo.packagist，写成repositories或repos全无效 - URL末尾必须有
/：正确是https://mirrors.aliyun.com/composer/，少斜杠会拼出/packages.json这种404路径 - 全局配置必须带
-g：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 项目级
composer.json里只要存在"repositories": []，就会屏蔽全局镜像——临时删掉它：composer config --unset repositories
libxxx，它只认php -m里有没有那个ext-xxx；而时间不同步这类底层问题，往往被当成网络故障反复换镜像折腾。 
