Composer 是项目级依赖管理工具，PEAR 是系统级安装工具；Composer 通过 vendor 目录隔离项目依赖、支持语义化版本约束与 SAT 求解、自动加载及 Packagist 生态，而 PEAR 缺乏依赖解析、版本管理混乱、生态萎缩且已被 PHP 官方弃用。
Composer 是项目级依赖管理，PEAR 是系统级安装
你跑 composer install，所有包都进当前项目的 vendor/ 目录；而 pear install 默认把代码装到 PHP 的全局路径（比如 /usr/share/php），所有项目共享同一份文件。这意味着：一个项目用 Guzzle 7，另一个要用 Guzzle 6？PEAR 做不到——它会直接冲突或覆盖。
- 多个项目共用一个
Mail.php类？改了就全崩，调试时根本分不清谁动的 - 部署新机器时，PEAR 需手动重装所有包，还可能因 PHP 版本差异失败；Composer 只要
composer install+composer.lock就能还原一模一样的环境 - PEAR 不记录依赖树，
pear list只显示已装包名，不知道 A 包是否偷偷拉了 B 包的旧版导致运行时报错
依赖解析能力差是 PEAR 最硬的短板
当你 require 一个包，它又 require 另一个包，后者再 require 第三个……这种嵌套依赖，PEAR 基本靠人肉判断版本兼容性。而 Composer 会读取所有 composer.json 中的版本约束（如 "monolog/monolog": "^2.0"），用 SAT 求解器算出唯一可行组合，并写进 composer.lock。
- PEAR 安装
Net_SMTP时不会检查你本地有没有Auth_SASL，更不会管版本是否匹配——运行时才报Class 'Auth_SASL' not found - Composer 能处理
dev-master、分支别名、path repo 等复杂源，PEAR 连 Git 仓库都不原生支持 - PEAR 的版本号格式混乱：
1.4.14、beta、stable，不遵循 SemVer，无法做范围约束
自动加载和 PSR-4 支持让 Composer 开箱即用
新建一个类，只要按 PSR-4 规则放在 src/ 下，加一行 autoload 配置，require 'vendor/autoload.php' 后就能 new 出来；PEAR 的类必须手动 require_once，或者靠 ini_set('include_path', ...) 拼路径，稍有不慎就 Warning: include(): Failed opening。
- PEAR 包通常用
PEAR::isError()这种全局函数风格，跟现代命名空间水土不服 - Composer 自动生成的
vendor/autoload.php支持 classmap、psr-0、psr-4、files 四种加载方式，PEAR 没有等效机制 - 想在 Laravel 或 Symfony 里用 PEAR 包？得自己写 ServiceProvider 绑定，而 Composer 包基本开箱即用
Packagist 生态碾压 PEAR，连维护都断档了
Packagist 上有超 35 万个可直接 composer require 的包，包括 Laravel、Symfony、Doctrine 全家桶；PEAR 官方仓库目前仅剩约 120 个活跃包，且多数三年没更新。2025 年起，PHP 官方文档已移除 PEAR 安装指引，推荐改用 Composer。
- 想装
phpunit？PEAR 版本停在 4.x，Composer 可直接装最新^10.0 - PEAR 的包发布流程繁琐：要注册、提交、人工审核、UP 投票；Composer 只需
git tag+ 提交到 Packagist，几分钟生效 - 连 PEAR 自己的升级命令
pear upgrade-all都常因权限或路径问题失败，而composer update日志清晰、回滚方便
真正容易被忽略的是：哪怕你只是临时用一个 PEAR 包（比如 Console_Getopt），也建议走 Composer ——它支持通过 pear type 从 PEAR 镜像拉取，写进 composer.json 后依然享受锁文件、自动加载和项目隔离。硬切回 PEAR 工具链，等于主动退回 PHP 5.2 时代。
