如果一个框架可以用很少的业务代码实现很多功能，那么其??实框架里面内置了很多公约。当这些约定不符合项目预期时，如何添加代码改变相应的约定，又不把其他部分搞乱，就会变得困难。经典的例子是各种CMF，drupal，wordpress，比框架更接近应用。如果一个框架可以实现很多功能，并且很容易修改或定义功能细节，那么这个框架往往需要写很多业务代码来填充这些允许定制的部分（因为如果这些部分有预设值，此帧回落到以前的类型）。“重型”框架通常属于这种类型。但是，如果一个框架没有太多的业务代码可写，但仍然可以很容易地改变它的功能，那么这个框架往往不能内置很多功能，需要开发者自己搭积木。以上就是我总结的框架三角原理。业务代码（less）、内置函数（more）和内控（easy）不能结合。作为一个开发者，我选择放弃内置函数的数量，因为我觉得这是唯一可以由外部来弥补的东西，而不是一个框架本身的好坏。说了这么多，这是一个以PSR为核心，内置DI机制的微框架，其他都是可选的。如果你喜欢Slim，但不喜欢它不模块化，不能换轮子，DI不正宗，搞servicelocator反模式，不妨了解一下。如果你对Slim还不了解，也不知道为什么那么多老司机入手Slim，但是你又懒得四处寻找安利Slim这么小的车架到底有什么好，你可以也可以看看Slim。http://litphp.github.io/blog/...（全英文警告）
