框架设计目标：
还是mvc结构；
框架只包含路由、db封装以及验证类（适合国情的手机号码、身份证、邮箱验证等）；
干一件事，只有一种方式；比如很多框架会提供很多种方法来从数据库取一条记录，这个框架只有一种方法，比如只有find(array $where)来取一条数据，没有其他封装方法，除非你用底层方法query；
api风格统一，类、方法、变量命名格式统一；
框架基础类继承不超过3层，你可以很容易地看懂框架源代码；
swiftmailer等国外成熟的类库直接通过composer加载即可使用，其他手动加载的类库放在library下面；
还有什么，大家继续补充。。。
框架目录结构：
├── composer.json├── composer.lock├── config //配置文件夹│   └── main.php├── controllers //控制层│   └── usercontroller.php├── library //第三方类库│   └── weibo├── models│   ├── dao //数据访问对象层，封装sql操作为相应的对象方法│   │   └── user.php│   └── data //业务控制层，封装业务逻辑，可以调用dao层、data层│   └── user.php├── public //web访问目录│   └── index.php├── vendor //composer仓库目录└── views //视图层 └── user └── info.php

回复内容： 框架设计目标：
还是mvc结构；
框架只包含路由、db封装以及验证类（适合国情的手机号码、身份证、邮箱验证等）；
干一件事，只有一种方式；比如很多框架会提供很多种方法来从数据库取一条记录，这个框架只有一种方法，比如只有find(array $where)来取一条数据，没有其他封装方法，除非你用底层方法query；
api风格统一，类、方法、变量命名格式统一；
框架基础类继承不超过3层，你可以很容易地看懂框架源代码；
swiftmailer等国外成熟的类库直接通过composer加载即可使用，其他手动加载的类库放在library下面；
还有什么，大家继续补充。。。
框架目录结构：
├── composer.json├── composer.lock├── config //配置文件夹│   └── main.php├── controllers //控制层│   └── usercontroller.php├── library //第三方类库│   └── weibo├── models│   ├── dao //数据访问对象层，封装sql操作为相应的对象方法│   │   └── user.php│   └── data //业务控制层，封装业务逻辑，可以调用dao层、data层│   └── user.php├── public //web访问目录│   └── index.php├── vendor //composer仓库目录└── views //视图层 └── user └── info.php

这个嘛。已经有了，github.com/dangcheng/scene-php
不错，思路清晰，化繁为简，很有实施性。
不过 看起来好像一个 ci 的升级版
我最近也在思考一个框架，既然这样我觉得我可以探讨一下，你思考是这样，但是写着写着你就发现可能不止三层了，我用了一段时间的yii框架，觉得yii框架包含的设计模式思想非常的好，开发起来整个逻辑很清晰。
我最近思考的一种方式就是后端只干后端的事情，纯数据处理，不进行渲染，只提供api，前端就只处理前端的事情，渲染完全靠前端javascript来做。
我觉得这种应该是app的设计思想。
移动端和pc端的适配怎么做呢? 如pc端数据可能是10个字段,但是移动端只需要查3~4个字段, pc端一个页面30条数据或者更多,移动端一页10来条