Composer 2.x 不支持 PEAR 仓库类型，因已彻底移除 pear 类型代码；PEAR 的 package.xml 格式、依赖机制、自动加载与 Composer 不兼容，且 PHP 7.4+ 已废弃 ext/pear 扩展。
Composer 官方早已停止对 PEAR 仓库的支持，pear.php.net 也不再作为 Composer 的合法仓库类型存在。直接配置 PEAR 仓库并用 composer install 安装 PEAR 包在现代 Composer（2.x+）中不可行。
为什么 composer.json 里加 pear repo 会报错
Composer 从 1.0 版本起就移除了原生 pear 类型仓库支持；2.0 彻底删除了相关代码。如果你在 composer.json 的 repositories 中写入类似：
{
"type": "pear",
"url": "https://pear.php.net"
}
执行 composer update 会直接报错：[InvalidArgumentException] Invalid repository type "pear"。
- PEAR 包的元信息格式（
package.xml）与 Composer 的composer.json结构不兼容 - PEAR 的依赖解析逻辑、安装路径、自动加载机制和 Composer 完全不同
- PHP 7.4+ 已移除
ext/pear扩展，系统级 PEAR 工具本身也在淘汰
想用老 PEAR 包，实际可行的替代方案
没有“安装 PEAR 包”的直通路径，但可根据包用途选择适配方式：
Evez Github Manager
下载
在 OpenClaw 中管理 GitHub 仓库、Pull Request、Issue 与工作流。适用于审查 PR、管理 Issue、自动化 GitHub Actions、同步仓库等场景。
- 查 GitHub / Packagist：很多经典 PEAR 包（如
PEAR_HTTP_Request2、PEAR_Mail）已被社区迁移为 Composer 友好版本，搜索php-http-request2或phpmailer/phpmailer等更可靠 - 手动封装成 Composer 包：fork 原 PEAR 项目，在根目录添加
composer.json，声明autoload（通常用classmap指向PHP/目录），然后以vcs类型引入："repositories": [{ "type": "vcs", "url": "https://github.com/your-fork/HTTP_Request2" }] - 临时混用 PEAR CLI（仅限开发环境）：用系统 PEAR 安装（如
pear install HTTP_Request2），再通过include_path或手动require加载——但这绕过 Composer 自动加载，无法被composer dump-autoload管理
composer.json 里写 "type": "package" 能不能硬塞 PEAR 包
可以定义一个 package 类型的虚拟包，但需你自行提供完整元数据，且无法自动同步上游更新：
{
"repositories": [{
"type": "package",
"package": {
"name": "pear/http-request2",
"version": "2.4.2",
"dist": {
"url": "https://pear.php.net/get/HTTP_Request2-2.4.2.tgz",
"type": "tar"
},
"autoload": {
"classmap": ["HTTP/"]
}
}
}]
}
注意点：
-
dist.url必须指向可公开下载的归档地址（PEAR 的/get/接口仍可用，但不稳定） - 解压后目录结构必须匹配
autoload.classmap路径，PEAR 包通常把类放在HTTP/Request2.php这类子目录下 - 所有依赖（如
PEAR_Exception）都得手动声明或一并打包，Composer 不会解析package.xml里的<dependencies>
真正麻烦的不是配置，而是 PEAR 包普遍缺乏命名空间、不遵循 PSR-4、依赖全局函数或 __autoload。哪怕“装上了”，运行时仍可能因加载顺序或符号冲突失败。
