迁移 PEAR 包到 Composer 需优先查找 Packagist 上的现成替代包，无则自行封装为 PSR- 4 私有包；替换 PEAR 特有函数与路径为原生 PHP 实现；采用渐进式策略，通过 class_alias 桥接、新旧并存、测试验证确保行为一致。
将旧的 PEAR 包迁移到 Composer，核心是用 Composer 替代 PEAR 的安装、依赖管理和自动加载机制。PEAR 本身已停止维护，迁移不仅是技术升级，更是项目长期可维护性的保障。
确认 PEAR 包是否已有 Composer 版本
很多经典 PEAR 包（如HTTP_Request2、Mail_Mime）早已被社区移植为 Composer 包，并发布在 Packagist 上。先搜索packagist.org，查是否有官方或广泛采用的替代包：
- 搜索关键词如
pear-http-request2或直接试php-http/client-implementation这类现代标准接口实现 - 优先选带
phpunit/phpunit这类明确维护者（如 PHP-FIG 成员、知名组织）的包 - 注意看
require中 PHP 版本和扩展依赖是否兼容你当前环境
若无现成 Composer 包：封装为私有包
如果该 PEAR 包无人维护、也未被移植，可自行打包供 Composer 使用：
- 将 PEAR 包源码（含
package.xml）整理为标准 PSR- 4 结构，例如：src/MyPkg/Http/Request.php - 编写
composer.json，声明autoload（推荐 PSR-4）、type（如library）、license等字段 - 托管到 Git 仓库（GitHub/GitLab），并在
composer.json中添加仓库配置（repositories）或直接提交到 Packagist（需注册） - 安装时执行：
composer require vendor/name:dev-main（或指定 tag）
处理 PEAR 特有的运行时行为
PEAR 包常依赖 PEAR::setErrorHandling()、PEAR::raiseError() 或全局 $_PEAR 变量，这些在 Composer 环境下不自动存在：
- 移除对
PEAR.php的require_once，改用 Composer 自动加载 - 将
PEAR::raiseError()替换为throw new Exception(……)或自定义异常类 - 如有硬 编码 路径（如
PEAR_INSTALL_DIR），改为用__DIR__或配置驱动的路径 - 检查是否调用
System::mktemp()等 PEAR 特有 工具 函数——需用 PHP 原生函数（如sys_get_temp_dir()）替代
逐步替换与测试策略
避免一次性全量替换导致故障，推荐渐进式迁移：
- 先在
composer.json中保留 PEAR 安装（不影响现有运行），同时引入新 Composer 包 - 新建一个功能模块，用新包重写，并通过单元测试验证行为一致
- 使用
class_alias()临时桥接旧类名到新类（仅限过渡期），减少代码改动范围 - 确认无误后，删除 PEAR 安装（
pear uninstall xxx）并清理所有require_once 'PEAR.php'等残留
基本上就这些。关键不是“能不能装上”，而是确保行为不变、错误处理不丢、路径不崩、测试全过。PEAR 到 Composer 不是换命令，是换整套依赖哲学。
