Composer 采用本地依赖管理，通过 composer.json 定义项目级依赖，支持自动加载与复杂依赖解析，而 PEAR 全局安装包，缺乏灵活的版本控制与依赖解决机制，易导致项目冲突。
Composer 和 PEAR 都是 PHP 的包管理工具，但它们在设计理念、使用方式和生态系统上有本质区别。理解它们的区别和历史背景，有助于更好地掌握现代 PHP 开发的依赖管理方式。
历史渊源：PEAR 曾经是唯一的选择
PEAR（PHP Extension and Application Repository）早在 2001 年就已推出，是 PHP 社区最早的官方包管理系统。它提供了一套标准化的方式来分发 PHP 类库和工具，支持通过命令行安装扩展包。PEAR 的设计初衷是构建一个类似 CPAN（Perl 的包管理器）的中心化系统。
在早期 PHP 版本中，PEAR 是组织代码、复用组件的主要方式。许多开发者通过 pear install 命令来安装数据库抽象层、邮件类等通用组件。然而，随着项目复杂度上升，PEAR 的局限性逐渐显现。
架构与作用范围不同
PEAR 将包安装为全局资源。一旦安装，包就存在于系统的统一目录下（如 /usr/share/pear），所有项目共享这些库。这种“全局安装”模式带来几个问题：
- 不同项目可能需要同一包的不同版本，PEAR 无法满足
- 升级全局包可能破坏已有项目
- 部署时需确保目标环境也安装了相应 PEAR 包，增加运维负担
而 Composer 从一开始就采用“本地依赖”理念。每个项目拥有自己的 composer.json 文件定义依赖，运行 composer install 后，依赖被下载到项目的 vendor/ 目录中。这意味着：
- 项目之间互不干扰，可使用不同版本的相同库
- 依赖关系清晰，便于版本控制和部署
- 支持自动加载（autoload），无需手动 include 文件
依赖管理能力差异显著
PEAR 的依赖处理较为简单，缺乏对嵌套依赖和版本冲突解决的完善机制。例如，如果两个包分别依赖某个库的不兼容版本，PEAR 往往无法自动协调。
Composer 使用先进的依赖解析算法（基于 Solver 组件），能分析整个依赖树并找出满足所有约束的版本组合。这使得引入第三方库变得安全可靠，极大提升了开发效率。
生态与社区演进
PEAR 虽然历史悠久，但其审核流程严格、发布缓慢，导致新项目参与意愿低。随着时间推移，活跃度下降，很多现代 PHP 框架不再支持或推荐使用 PEAR。
Composer 则依托 Packagist 作为默认仓库，允许任何人自由发布和使用包。这一开放模式迅速吸引了 Laravel、Symfony、PHPUnit 等主流项目加入，形成了繁荣的生态系统。现在几乎所有的 PHP 开源项目都提供 composer 支持。
基本上就这些。Composer 并不是 PEAR 的简单替代品，而是顺应现代软件工程需求产生的全新工具。它解决了 PEAR 在作用域、版本控制和自动化方面的根本缺陷，成为当前 PHP 开发生态的核心基础设施。PEAR 仍有遗留系统在使用，但对于新项目，Composer 是无可争议的标准选择。不复杂但容易忽略的是：工具变迁背后反映的是开发范式的进步——从全局共享到项目自治，从手动管理到声明式依赖。
