php pear现在还值得用吗？对比Composer看看哪个更方便。

发布日期： 2025-09-26 阅读量： 作者： admin

今天就来聊聊我以前折腾 PHP PEAR 的那点事儿，也算是翻翻老黄历了。

记得刚开始鼓捣 PHP 那阵子，环境装好了，写了点简单的页面，就想着怎么能方便地用别人写好的代码，别老是自己造轮子。那时候就听说了 PEAR 这个东西，说是 PHP 官方自带的一个包管理器，能装不少现成的库。

行，那就试试呗。我当时用的 PHP 环境里好像就已经带了 PEAR 命令。我就打开那个黑乎乎的命令行窗口，试着敲了个 `pear`，回车，出来一堆帮助信息。看着有点晕，不知道具体该咋用。

琢磨了半天，又去网上搜了搜，大概明白了，想装个啥包，就用 `pear install 包的名字` 这样的命令。我就随便找了个看着顺眼的包，好像是叫 `Log` 还是啥的，用来写日志的，就敲了 `pear install Log`。看着命令行跑了一会儿，下载、安装，提示成功了。

心里还挺高兴，觉得挺方便。但高兴得有点早。装完了，我回到我的 PHP 代码里，想直接用这个 `Log` 类，结果一运行就报错，说找不到类。我又懵了，这咋回事？不是装好了吗？

又是一顿折腾，到处找资料。才搞明白，PEAR 装的包，默认是装在一个公共的地方，通常在 PHP 的安装目录下面。关键是，装好了你还得在自己的 PHP 文件里手动 `include` 或者 `require` 那个包的入口文件！它不像现在有些工具，装完了能自动加载。我得自己找到那个文件的路径，然后老老实实在代码开头写上 `require_once '*';` 类似这样的代码。这才算是能用了。

后来用着用着，又发现点别扭的地方。比如，PEAR 装的包默认是全局的，就是说我这台机器上所有 PHP 项目都能访问到。听起来好像挺但有时候项目一多，不同项目可能需要同一个包的不同版本，这就麻烦了，容易冲突。而且项目部署的时候，还得确保服务器上也用 PEAR 装了同样版本、同样依赖的包，感觉有点繁琐。

再就接触到了像 Composer 这样的工具。嚯，那感觉就不一样了。项目里放个 `*` 文件，写清楚需要哪些库和版本，然后一个 `composer install` 命令下去，哗就把所有需要的包（包括依赖的依赖）都下载到你项目自己的 `vendor` 目录里了，相互隔离，清清楚楚。更爽的是，它还自带了自动加载机制，基本上装完就能直接 `use` 相应的类，不用自己操心 `include` 或 `require` 那一大堆文件了。

所以现在回头看 PEAR

PEAR 这东西，怎么说，在当年那个环境下，它确实是 PHP 社区一个重要的进步，提供了一种管理和分发代码库的方式。我刚学 PHP 的时候，也确实靠它装过几个工具包，解决了当时的一些问题，算是我的 PHP 学习经历里的一部分。

时代在发展嘛。跟 Composer 比起来，PEAR 在易用性、项目依赖隔离、自动加载这些方面确实是落后了。现在我们做新的 PHP 项目，基本上都是用 Composer 来管理依赖了，方便、规范，也成了事实上的标准。PEAR 嘛就渐渐淡出主流视野了，可能也就一些非常老的项目或者特定的系统级 PHP 工具还在用它。对我来说，那段折腾 PEAR 的经历，现在想想，也算是一种技术变迁的见证。

上一篇: 虚拟机和宿主机哪个更好？优缺点对比分析！

php pear现在还值得用吗？对比Composer看看哪个更方便。

随便看看