“Package not found”与PHP扩展缺失无关，是元数据解析阶段失败，需优先检查镜像配置、repositories屏蔽效应及包名准确性。
Composer 报 “Package not found” 与 PHP 扩展缺失**没有直接关系**。它不会因为 ext-json、ext-openssl 或 ext-zip 缺失而显示这个错误——那些扩展缺失会导致 composer install 在**下载、解压或校验阶段失败**，错误信息会明确写 “requires ext-xxx”、“The xxx extension is missing” 或 “file could not be downloaded”。
“Package not found” 是 Composer 在**元数据解析阶段**就终止了，根本没走到需要加载扩展的步骤。它只说明一件事：当前配置下，Composer 没在任何已启用的源里匹配到你写的包名和版本约束。
为什么你会误以为是扩展问题？
因为两类错误常被一起遇到，但因果不成立：
- 你刚重装系统/PHP，既没配镜像，也没装扩展 → 运行
composer install同时爆出 “Package not found” 和后续 “ext-zip missing”，容易混淆主次 - 某些 CI 环境（如 GitHub Actions）默认不带扩展，又没设镜像 → 先卡在找不到包，你反复重试，最后才看到扩展报错，误把时间顺序当因果
真正该查的三件事（按优先级）
遇到 “Package not found”，立刻验证以下三项，跳过所有扩展检查：
-
composer config -g repos.packagist输出是否为有效镜像地址（如https://mirrors.aliyun.com/composer/），注意键名是repos.packagist（复数），不是repo.packagist - 项目根目录的
composer.json是否含"repositories"字段？如果存在，它会**完全屏蔽全局配置**，且必须包含{"packagist.org": false}（独立对象、放数组末尾）才让私有源生效 - 包名是否 100% 正确？访问
https://packagist.org/packages/vendor/name能打开，composer search vendor/name有结果，且大小写、连字符、组织名与页面 URL 完全一致
扩展缺失会在哪一步暴露？
只有当你跨过 “Package not found” 阶段，进入实际安装环节后，扩展问题才会浮现：
-
ext-openssl缺失 →composer install卡在 “Downloading https://…” 后无响应，或报 “file could not be downloaded”（HTTPS 失败） -
ext-zip缺失 → 下载完成后解压时报 “class ZipArchive not found” 或 “failed to extract” -
ext-json缺失 →composer install直接中止并输出 “The json extension is missing”，甚至无法解析composer.lock
最易被忽略的是：你在本地调试时开了 XAMPP/WAMP，改了 Apache 的 php.ini 启用扩展，但 CLI 模式下跑 composer 用的是另一个 php.ini —— php --ini 和 php -m 必须在终端里执行，不能只看浏览器里的 phpinfo()。
