Composer已完全移除对PEAR仓库的支持，包括发现、下载、安装与自动加载，2.0起直接报错；需删除pear仓库配置、替换为Packagist现代包（如guzzlehttp/guzzle）、或手动autoload单文件。
pear.php.net 上的包（如 PEAR::HTTP_Request2、PEAR::Mail），它在 Composer 2.x 下根本无法 composer install 成功。
为什么PEAR支持被彻底砍掉？
PEAR 仓库协议陈旧、无标准元数据、不支持语义化版本约束，且长期缺乏维护。Composer 的设计哲学是“声明式依赖 + 可重现安装”，而 PEAR 的 channel.xml 和 package.xml 格式无法满足这一前提。官方早在 2020 年就标记为废弃，2.0 版本正式执行移除。
迁移时遇到 Could not find package xxx at any version 错误怎么办？
这通常意味着你在 composer.json 中写了类似这样的过时配置：
{
"repositories": [
{
"type": "pear",
"url": "https://pear.php.net"
}
],
"require": {
"pear-pear.php.net/http_request2": "*"
}
}
你需要做三件事：
- 删除整个
"repositories"数组中"type": "pear"的条目 - 查替代包：访问 packagist.org 搜索原功能关键词（如
http request、mail smtp），优先选guzzlehttp/guzzle、phpmailer/phpmailer等现代包 - 重写 require 条目，例如把
"pear-pear.php.net/http_request2": "*"替换为"guzzlehttp/guzzle": "^7.8" - 若找不到纯 Composer 替代品，可临时用
"autoload": { "files": [...] }手动引入 PEAR 的.php文件（仅限极简场景，不推荐长期使用）
PEAR 类文件如何在 Composer 项目中继续用？
如果你只用了几个 PEAR 的单文件类（比如 System.php 或 Validate.php），且没有命名空间，最务实的做法不是找“PEAR 兼容层”，而是：
- 把对应
.php文件复制进项目vendor/pear-shim/目录（或你自定义的lib/） - 在
composer.json中添加文件级自动加载：
{
"autoload": {
"files": ["vendor/pear-shim/System.php", "vendor/pear-shim/Validate.php"]
}
}
然后运行 composer dump-autoload。这样既绕过仓库限制，又保持加载可控——比试图复活 PEAR 通道更轻、更可靠。
检查你的项目是否还隐含依赖 PEAR
老项目常通过以下方式“悄悄”绑定 PEAR：
-
require_once 'System.php'这类硬编码路径（尤其在includes/或libs/目录下） - 第三方私有包的
composer.json里残留"type": "pear"（注意：子依赖的仓库定义会被 Composer 忽略，但若它 require 了 pear 包，仍会失败） - CI 脚本中调用
pear install命令未被同步清理
迁移前务必全局搜索 pear、System::、PEAR::、require_once.*\.php 等模式，否则 composer install 会在新环境静默失败。
include 链和部署脚本里的隐式依赖——它们不会报错，只会让应用在某次请求中突然 Fatal error: Class 'System' not found。 
