composer镜像生效依赖php.ini三项关键配置：memory_limit需设为-1或512m以上防oom，max_execution_time至少300秒防元数据同步超时，curl.cainfo须指向有效ca证书路径确保https镜像请求成功。
PHP.ini里哪些配置会影响Composer镜像生效
Composer本身不读PHP.ini，但它的运行严重依赖PHP底层网络和内存行为。镜像配对了，composer install却仍卡在Downloading或报Connection refused，大概率是PHP.ini里几个关键项没调好。
-
memory_limit设太低（如128M）会导致依赖解析阶段OOM，Composer反复重试，看起来像“卡住”，实际是内存耗尽后崩溃重连 -
max_execution_time默认30秒，在镜像首次同步元数据时容易超时，尤其项目依赖多、composer.lock老旧时 -
opcache.enable开启能加速Composer自身脚本执行，但opcache.validate_timestamps=Off会导致它读到过期的缓存类文件，引发autoload错误 -
curl.cainfo若指向错误证书路径，https://mirrors.aliyun.com/composer/会握手失败，降级为HTTP重试或直接报SSL certificate problem
必须改的三项PHP.ini参数值
不是所有PHP.ini项都相关，只动这三处就能解决90%的镜像“配了没用”问题：
-
memory_limit = -1（CI/部署环境可设为512M，开发机建议-1）——Composer解析依赖图非常吃内存，尤其带大量require-dev时 -
max_execution_time = 300（至少5分钟）——第一次用新镜像拉全量packages.json可能耗时较长，别让它中途断掉 -
curl.cainfo = "/etc/ssl/certs/ca-certificates.crt"（Linux）或"C:\php\extras\ssl\cacert.pem"（Windows）——确认路径真实存在且证书包最新，否则HTTPS镜像请求直接失败
为什么改完PHP.ini还要重启服务
PHP CLI和Web SAPI加载的是不同实例：你在终端跑composer install走的是CLI模式，而宝塔、Docker或systemd里执行的可能是FPM或Apache模块。改完php.ini后：
- CLI模式：直接生效，无需重启，但需确认
php --ini输出的Loaded Configuration File路径是你刚改的那个 - FPM模式：必须
sudo systemctl restart php-fpm或宝塔面板里点“重启PHP” - Apache模块：需
sudo systemctl restart apache2，否则phpinfo()看到的仍是旧配置
验证PHP.ini改动是否真正起效
别信“我改过了”，要亲眼看到：
- 查CLI实际加载的ini：
php --ini，然后grep -E "(memory_limit|max_execution_time|curl.cainfo)" /path/to/php.ini - 测curl能否通镜像：
php -r "echo file_get_contents('https://mirrors.aliyun.com/composer/packages.json') ?: 'fail';"，返回JSON说明HTTPS+CA配置OK - 看Composer是否真用上大内存：
COMPOSER_MEMORY_LIMIT=-1 php -d memory_limit=-1 $(which composer) install -vvv 2>&1 | grep "Resolving dependencies"，如果不再报Allowed memory size exhausted就对了
最容易被忽略的是：PHP.ini改的是PHP行为，不是Composer逻辑。哪怕镜像URL写对了、repo.packagist也生效了，只要curl.cainfo指向空文件或memory_limit卡在128M，Composer照样会在下载前一步就跪。先确保PHP底层稳了，再谈镜像优化。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
