Composer 不支持原生 PEAR 仓库,需将 PEAR 包重构为 Composer 包:通过 Satis 搭建私有仓库或手动包装为 ZIP 并用 package 方式引入,不建议使用已废弃的 PEAR Channel 桥接工具。

Composer 本身不支持原生的 PEAR 仓库(PEAR Channel),它专为 PSR-0/4 自动加载的 PHP 包设计,而 PEAR 使用的是传统目录结构和 .tgz 归档分发方式。因此,你不能直接在 Composer 中“配置私有 PEAR 仓库”来安装 PEAR 风格的包。但如果你的目标是:在私有环境中分发和安装类 PEAR 的 PHP 库(尤其是遗留 PEAR 包或需兼容旧系统),可通过以下几种务实路径实现。
用 Satis 搭建私有 Composer 仓库(推荐)
Satis 是官方维护的轻量级静态 Composer 仓库生成器,适合私有包托管。它不运行服务,而是将 Git 仓库打包成 packages.json,供 Composer 拉取。
- 把你的 PEAR 包重构成标准 Composer 包:添加
composer.json,声明autoload(如"psr-4"或"classmap"),并确保代码结构可被自动加载 - 将代码推送到私有 Git 服务器(如 GitLab、Gitea 或内部 Git)
- 用 Satis 生成仓库索引:
satis build satis.json web/
其中satis.json中配置你的私有包源:{ "name": "my-org/private-packages", "repositories": [ { "type": "vcs", "url": "https://git.internal/my-org/legacy-utils" } ], "require-all": true } - 将生成的
web/目录部署为 HTTP 可访问的静态站点(如 Nginx 目录) - 在项目
composer.json中添加:"repositories": [ { "type": "composer", "url": "https://packages.internal/" } ] - 运行
composer require my-org/legacy-utils即可安装
手动包装 PEAR 包为 Composer 包
若必须复用现有 PEAR .tgz 包(如 My_Package-1.2.0.tgz),可将其转为 Composer 兼容格式:
-
解压 PEAR 包,观察其结构:通常含
package.xml和php/下的类文件 - 新建目录,复制所有 PHP 类文件,并补全
composer.json,例如:{ "name": "my-org/my-pear-package", "version": "1.2.0", "autoload": { "classmap": ["."] } } - 打一个 ZIP 包(非 PEAR .tgz),上传到私有 HTTP 服务器,URL 如:
https://files.internal/my-pear-package-1.2.0.zip - 在
composer.json中用package方式声明:"repositories": [{ "type": "package", "package": { "name": "my-org/my-pear-package", "version": "1.2.0", "dist": { "url": "https://files.internal/my-pear-package-1.2.0.zip", "type": "zip" }, "autoload": { "classmap": ["."] } } }] - 然后
composer require my-org/my-pear-package:1.2.0
不建议的做法:尝试对接 PEAR Channel
虽然存在第三方工具(如 pear-composer)试图桥接 PEAR Channel 和 Composer,但它们:
- 已多年未更新,不兼容 PHP 8+ 和新版 Composer 2.x
- 无法处理 PEAR 的依赖解析逻辑(如
channel://协议、package.xml中的) - 不支持自动加载,仍需手动
require_once,违背 Composer 设计初衷 - 引入额外复杂度,且无长期维护保障
基本上就这些。核心思路是:放弃 PEAR 分发协议,拥抱 Composer 生态——把私有库标准化、加 composer.json、走 Git 或 HTTP 分发。迁移一次,后续更新、依赖管理、CI/CD 都更稳。










