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中的<dependencies>） - 不支持自动加载，仍需手动
require_once，违背 Composer 设计初衷 - 引入额外复杂度，且无长期维护保障
基本上就这些。核心思路是：放弃 PEAR 分发协议，拥抱 Composer 生态——把私有库标准化、加 composer.json、走 Git 或 HTTP 分发。迁移一次，后续更新、依赖管理、CI/CD 都更稳。
