首先，我要说明的一点是，我在项目的前期是有使用composer的，那时候我觉得一个新项目不使用Composer那就是开倒车。但是其实不是这样的，Composer是一种依赖的管理手段，它的主要功能并不是作为一个引导程序去使用，而我恰恰就是将其作为引导程序使用，因此迷失了方向……

最初TarBlog项目仅有一个主要依赖，就是illuminate/database，它是从Laravel中剥离出来的数据库组件。我一直很中意这个组件的设计，但是当时水平不足，无法用自己的语言复现其行为，因此直接作为依赖引入到了项目中。到后来，我发现只引入这个组件太浪费了，因为它带来了很多额外的无用文件，因此打算充分利用，想搞一个类似于Lumen的框架内核。当然，这个野心没有实现，调试起来过于麻烦，而且体积也越来越大，我发现这是没有意义的。

回归本质，做这个博客程序的目的其实并不是去做成一个大型框架，而是做一个相对定制化且轻量级的博客程序。到了今天，我可以说定制化基本上已经完成（想对于我而言）；而轻量化，目前仍然在努力，因为一些前端组件确实也没法一下子用更轻量的东西去代替，但是代码层面上基本是轻量化的。

说到这里，其实我不再使用Composer的原因基本上已经都阐明了，我再补充和总结一下：

• Composer带来太多无用依赖，导致占用体积大
• Composer的自动引入机制其实是PHP自动引入机制的扩展，是可以自己实现的
• Composer对于我的插件机制来说是噩梦，非常影响开发者定制插件的灵活性
• Composer在虚拟主机上基本无法使用，还要本地安装好依赖再打包到虚拟主机上，麻烦
• Composer很影响我整个安装流程，去掉它我的安装流程设计会更加轻松

这些也只是一些原因，一些更深层次的原因我暂时不提，但是我相信这些问题已经足够让我弃用Composer。

不过，这不代表我讨厌Composer，对于Composer管理比较大的项目我还是很欢迎的，因为本身就不考虑体积的问题，而且Composer安装依赖非常方便，可以不用去一一找官方网站下载依赖，更新卸载也不需要手动操作文件。我的另一个项目NewIDC就是通过Composer管理的，框架使用Laravel，因为这个项目比较庞大，所以直接用现成框架很省事。

项目要不要使用Composer，主要还是考虑到项目规模，如果不大且用不到太多依赖，建议还是“原始”一点，这样可以掌控全局；项目规模大，则用Composer更好，用到的依赖越多，越能体现Composer的价值。最后，不要把Composer单纯地当作一个自动引入插件，没必要！