@
kenshin 我觉得你这涉及到框架实现的问题。我一直认为使用全栈框架的风险很大，就不说迁移了，万一框架内的bundle有Bug（比如因为使用不当造成），那么隐患相当大。
我在个开发框架的时候（哪怕是给自己开发），通常都是选择最保守的路线（方针是“我是最笨的，别人有权利作选择”），不做大而全或者提供具体的功能（比如ORM这些（好吧，我的框架虽然是有，但是被独立放到了单元的部分，非框架组件）），仅仅面向项目管理，比如提供稍微强大的组件加载和管理功能。其他功能一律作为可以替换掉的组件。
如果开发者需要具体功能，可以使用Composer来管理自己的组件依赖等等。所以我框架做出来，严格来说仅仅只是一个按照一定规则进行组件加载的加载器，然后剩余的东西基于这个加载器规范进行管理。将框架本身的能造成的风险降到最低。
以上。
当然，我不会拿我自己这个框架作为负载产品的底层结构推广给公司用，理由倒不是不安全，而是这个框架的设计本身就不是为了敏捷开发。甚至于会降低开发速度（你必定需要写一些自己的组件，因为框架不提供），不适合互联网公司的开发。
而我开发这个框架是因为：
1、我不想总是跟在Laravel等一堆框架们后面等它更新，或者在它更新之后尝试让旧项目兼容新的框架。而我自己的框架做到现在最让我头疼的一次兼容性更新也仅是更换模板引擎（是的，要改模板），而我其实也能让它不需要更新就能兼容（重新打包下旧模板引擎然后设定下就可以了，但我想使用新模板引擎啊）；
2、很多MVC的项目的基本文件结构都是M一个大文件夹，C一个大文件夹（比如Controller\User\Account\Register\API这样的结构），V一个大文件夹。嗯，没错，我一开始也是这样用。但是当我项目里有100来个PHP文件飘在里面一层一层翻文件夹的时候真的感觉一点都不惬意。于是根据我的需求，我把一个大项目拆成了若干个小项目（我叫做Package）。这样文件结构就变成了类似 User.Account.Register\Application\Controller\API，虽然是换汤不换药，但是文件结构瞬间好了很多有没有，至少能让精力可以锁定到这个Package里，现在200多个PHP文件了，但是管理起来依然轻松。想如果用其他框架的话，想要这么做，得付出更大的努力才可以（但可能别的框架不需要翻文件夹？）。
3、不想妥协的接受某些设定。就拿配置全局访问设置的例子，配置有些在数据库里，有些在本地配置文件里，有些设置不需要加载，有些配置应该在使用的时候自动加载并更新缓存。一些框架很麻烦，多多少少得造点轮子。于是我造了个大轮子，我让自己的框架支持了分区自动加载，通过命名空间来自动预加载某些文件以便初始化。总归来说就是不妥协。
轮子不造，怎么知道好不好？我的观点是不论对不对，先造个出来玩。何况轮子造好之后很有意思+能学到很多不是么？