如果一个框架能用很少的业务代码实现特别多的功能，那么其实就是这个框架内置了大量的惯例，当这些惯例不符合项目预期的时候，如何添加代码精确地改变对应的惯例，而不搞砸其他部分，就会变的很难。经典的例子是各类 CMF，drupal，wordpress，比起框架来已经更接近应用了。
如果一个框架能实现的功能很多，也很容易修改或定义其中的功能细节，那么这个框架往往需要写非常多的业务代码来填充起这些允许自定义的部分（因为如果这些部分有预设值，这个框架就落回到上一个类型）。一般而言的“重”框架往往是这种类型。
而一个框架如果要写的业务代码不多，也还是能够轻松的改变其中的功能，那么这个框架往往无法内置很多功能，需要开发者自己动手拼积木。
以上是我总结的框架的三角原理，业务代码（少），内置功能（多）和内部掌控（易）三者不可得兼。
作为开发者，我选择放弃内置功能的数量，因为我觉得这是唯一可以由外部弥补的，不属于一个框架本身素质。
啰嗦了这么多，这是一个以 PSR 为核心的，自带 DI 机制的微框架，其他一切皆可选配。如果你喜欢 Slim，但又嫌弃他自身不模块化没法换轮子，DI 不正宗搞 service locator 反模式，不妨了解一下。如果你还不了解 Slim，还不知道为啥那么多老司机上手就是 Slim，但又懒得四处安利 Slim 这么小的框架究竟好在哪里，那也可以和 Slim 一起看下。
http://litphp.github.io/blog/… (全英文预警)