Composer中文镜像不影响ext-扩展检查，因镜像仅代理包元数据和下载，ext校验由本地extension_loaded()执行；常见误判源于镜像加速掩盖超时或同步延迟，而非跳过检查。
Composer中文镜像不影响ext-扩展的自动检查
中文镜像（如阿里云、腾讯云、华为云镜像）只代理packagist.org上的包元数据和zip包下载，不参与PHP扩展依赖的校验流程。Composer 对ext-mbstring、ext-intl等的检查发生在本地，调用的是extension_loaded()，与镜像无关。
常见误解是“换镜像后ext依赖不报错了”，实际原因通常是：镜像加速后composer install跑得更快，掩盖了原本因超时导致的脚本中断；或镜像同步延迟让旧版composer.json缓存生效，误以为跳过了检查。
镜像可能干扰的唯一场景：post-install-cmd中调用pecl
如果某个包在scripts.post-install-cmd里写了pecl install redis这类命令，而该命令又依赖pecl.php.net源，那么中文镜像对Composer本身无影响，但pecl仍会直连国外源——此时你看到的失败（如Connection timed out）不是Composer镜像问题，而是PECL没换源。
- PECL 换源需单独执行：
pecl config-set php_dir https://www.php.cn/link/1585a6f19f4b5e324deb3bf511e783f8不生效；正确方式是：pecl config-set preferred_state stable && pecl config-set channel pecl.php.net，再配合国内镜像代理（如pecl.php.net镜像站需手动配置HTTP代理或使用pear config-set） - 更稳妥的做法是：避免在
post-install-cmd里调用pecl，改用系统包管理器（apt install php-redis）或Docker构建阶段预装 - 检查是否真在走PECL：运行
composer install -vvv，搜索Executing command日志行，确认触发的是pecl还是其他命令
自动发现（Package Discovery）机制完全不受镜像影响
Laravel 的自动发现（读取extra.laravel.providers）、Symfony 的extra.symfony.bundles、或插件自定义的extra.myframework.loaders，全部基于已安装在vendor/下的包的composer.json文件内容。这些文件由Composer解压后本地读取，不经过网络请求，镜像再快也插不上手。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
立即学习“PHP免费学习笔记（深入）”；
容易混淆的点：有人把“装不上包”归咎于镜像，结果发现是自己漏写了"type": "laravel-package"，导致Laravel的PackageManifest跳过扫描——这不是镜像问题，是包类型声明缺失。
真正要盯住的三个本地环节
当你怀疑“镜像搞坏了扩展检查”，其实99%的问题出在以下三处：
-
php -m输出里确实没有intl，但composer.json写了"ext-intl": "^1.1"→ Composer 必然报错，换任何镜像都一样 -
composer.lock里记录了"ext-redis": "*"，但PHP CLI和Web SAPI启用的扩展不一致（比如CLI有redis，Apache没加载）→ 报错发生在composer install，但根源是PHP配置分裂 - 用了
--ignore-platform-reqs后看似成功，但运行时抛Class 'Redis' not found→ 镜像没骗你，是你绕过了守门人
镜像只是快递员，不负责检查你的PHP有没有装好扩展，也不负责替你写extension=redis.so。真出问题，先看php -i | grep extension_dir和php --ini，再查镜像。
