ThinkPHP5开发的正确姿势
0、本篇的建议旨在让你的ThinkPHP5开发更规范和顺利，但仅仅是建议，而不是必须。
关键字：
操作方法的参数绑定功能
Request属性注入
用Request类的getInput方法替代file_get_contents('php://input')；
永远不要在操作方法中（事实上是任何代码中）使用exit；
使用composer，是趋势
应用仓库并非必须；
把web根目录指向public目录而不是根目录；资源文件不要放到public目录以外；
TP5完美支持PHP7，TP5正常运行需要PHP5.4+，建议版本为PHP5.6+；
不要使用普通URL模式访问；
变量篇
避免直接获取系统变量，用Request对象的相关方法替代；
不管get还是post请求，统一用param方法获取当前请求（任何请求类型）变量；
不要直接操作改变当前请求的系统变量；
使用操作方法的参数绑定功能，而不是自己手动获取请求参数；
使用依赖注入（TP5的依赖注入非常的简单）；
对于一些请求用到的公共属性可以使用Request属性注入；
用Request类的getInput方法替代file_get_contents('php://input')；
模板中输出系统变量使用{$Request.param.name}的方式；
多使用Request类的only和except方法获取多个请求变量；
不要直接操作$_SESSION变量；
任何变量必须事先定义才能操作或者赋值给模板；
路由篇
用动态注册方法而不是路由配置；
不要在路由配置文件之外定义路由；
用get/post/delete/put等路由注册方法明确指定请求类型；
保证路由变量和操作方法的参数绑定命名一致（包括可选）；
路由地址保持和实际的控制器名和方法名一致（包括大小写）；
为每个路由变量明确指定变量规则；
用路由分组简化路由定义和公共参数；
尽可能使用强制路由并配合MISS路由；
优先考虑资源路由尤其是API开发的时候；
考虑在路由后置行为中进行统一的权限检测；
部署后记得执行路由缓存指令；
了解下路由的请求缓存对你会有帮助；
控制器篇
建议开启controller_suffix配置参数，并采用IndexController命名控制器类；
原则上控制器类不需要继承think\Controller；
给你的控制器类继承一个公共的基类例如Base便于统一调整；
需要的话在你的基础控制器类中引入traits\controller\Jump；
API开发尽量使用资源控制器（命令行php think create:controller 可以快速生成）；
控制器类中避免写太多的业务逻辑，交由模型类完成；
尽量避免直接操作数据库类，而是在模型类中做好封装；
可能的话尽量在控制器层完成数据验证；
不要试图在初始化方法中调用redirect助手函数，而用$this->redirect方法替代；
始终在控制器方法中return而不是echo以免影响请求缓存；
用json、view以及redirect助手函数进行响应输出；
用abort助手函数抛出HTTP异常；
遵循驼峰法命名你的控制器类和文件名；
永远不要在操作方法中（事实上是任何代码中）使用exit；
数据库篇
千万不要用驼峰法命名数据表和字段；
如非必要避免直接操作Db类；用Db类的name方法而不是table方法；
用视图查询view方法替代join方法；
查询操作尽可能的使用field方法，哪怕是field(true)；
如果要批量执行SQL语句使用batchQuery方法；
用value方法获取单个记录的某个字段值；
用column方法获多条记录的某个（或者某些）字段值；
灵活使用cache方法进行查询缓存处理和删除（不仅是查询可以用cache方法）；
使用fetchSql方法直接返回sql语句而不实际执行CURD；
部署之后记得执行命令行的php think optimize:schema指令；
strict方法可以避免多余的数据字段抛出异常；
关于日期和时间的查询不妨试试whereTime方法；
数据库的大多数操作都是自动参数绑定的，一般情况下无需手动使用bind方法；
insert方法返回的是影响的记录数而不是主键；
使用insertGetId方法插入数据并返回主键；
delete(true)可以无条件的删除数据；
select和find方法支持闭包，但尽量不要和链式操作混用；
需要查询大量数据并且分批处理的话使用chunk方法；
对find方法使用主键查询并且cache(true)的话缓存是自动更新的；
模型篇
不要以为模型性能比Db差，这点差别还不抵不过一条SQL查询，而带来的便利是可观的；
模型的好处千言万语抵不过两个字：对象（明白人都会懂）；
模型类一般直接继承think\Model，如有必要也可以继承一个公共模型基类；
如果你的模型类没有任何的数据库操作的话不需要继承任何类库；
模型类不需要使用类后缀Model（对应前面的控制器类后缀）；
模型的save方法既可以新增也可以更新（而且是自动识别）；
模型没有链式操作，所有链式操作都是调用的数据库类Db；
模型支持事件而数据库类的操作不支持事件；
统一在模型的init方法（静态方法）中注册模型事件；
模型没有数据表前缀的概念只有对应数据表（完整表名）的概念；
每个模型对应一个数据库查询对象Query，彼此独立；
每个模型可以单独定义自己的数据库连接信息；
模型名不一定就是数据表名，而且可以单独定义数据表名称；
模型查询的数据返回永远都是当前模型对象实例（而不是数组，Db类查询才是数组）；
模型对象可以直接进行数组操作并不需要使用toArray转换（包括模板输出）；
模型的查询操作建议使用get和all方法（静态方法）；
要在模型查询中使用链式查询可以定义查询范围或者使用闭包；
用save方法新增数据的返回值是影响的记录数而不是主键值，获取主键直接获取当前模型对象的属性值即可；
如果仅仅是需要主键之外的查询条件的话，可以在get或者all方法的第一个参数使用数组；
要模型查询后的原始数据可以使用getData方法；
模型的关联操作可以让你省去很多的关联查询；
鉴于性能考虑，关联预载入查询绝对是关联查询的首选；
一对一的关联关系，尤其是主表和附表的关系考虑使用聚合模型；
软删除必须使用模型的delete方法（而不是数据库类的delete）才有效；
不要在修改器中修改多个属性；
修改器是模型才有的功能，调用数据库Db类的写入操作方法是不会触发的；
不要在同一个模型实例中多次调用save新增数据，一旦新增数据成功后，再次save就是更新数据了，除非你显式调用isUpdate(false)；
用模型事件取代自动完成；
其它篇
开发过程中开启调试模式，部署后记得关闭；
如果不是API开发的话开启页面Trace显示；
不要轻易忽视异常页面的任何信息，它们不是摆设；
开发中一定要严格注意大小写，这是基本素质；
如果是接口开发尝试使用 postman 进行调试；
使用命名空间和自动加载，避免直接 require 及 include ；
不建议使用 import 和 vendor 方法；
应用目录下面的common.php（注意不是command.php）可以添加应用的函数，并且实时生效；
不要手动下载扩展包放入vendor目录，不支持composer安装的扩展类库直接放入extend；
只要是使用命名空间的第三方类库，都是可以直接在TP5下面使用的；
尽可能的采用MVVM设计架构来替代MVC架构，充分发挥TP5的API优势；
如果使用模板，避免在模板中使用过多的数据逻辑；
模板继承和模板布局是可以配合使用的；
关键字：
操作方法的参数绑定功能
Request属性注入
用Request类的getInput方法替代file_get_contents('php://input')；
永远不要在操作方法中（事实上是任何代码中）使用exit；
使用composer，是趋势
应用仓库并非必须；
把web根目录指向public目录而不是根目录；资源文件不要放到public目录以外；
TP5完美支持PHP7，TP5正常运行需要PHP5.4+，建议版本为PHP5.6+；
不要使用普通URL模式访问；
变量篇
避免直接获取系统变量，用Request对象的相关方法替代；
不管get还是post请求，统一用param方法获取当前请求（任何请求类型）变量；
不要直接操作改变当前请求的系统变量；
使用操作方法的参数绑定功能，而不是自己手动获取请求参数；
使用依赖注入（TP5的依赖注入非常的简单）；
对于一些请求用到的公共属性可以使用Request属性注入；
用Request类的getInput方法替代file_get_contents('php://input')；
模板中输出系统变量使用{$Request.param.name}的方式；
多使用Request类的only和except方法获取多个请求变量；
不要直接操作$_SESSION变量；
任何变量必须事先定义才能操作或者赋值给模板；
路由篇
用动态注册方法而不是路由配置；
不要在路由配置文件之外定义路由；
用get/post/delete/put等路由注册方法明确指定请求类型；
保证路由变量和操作方法的参数绑定命名一致（包括可选）；
路由地址保持和实际的控制器名和方法名一致（包括大小写）；
为每个路由变量明确指定变量规则；
用路由分组简化路由定义和公共参数；
尽可能使用强制路由并配合MISS路由；
优先考虑资源路由尤其是API开发的时候；
考虑在路由后置行为中进行统一的权限检测；
部署后记得执行路由缓存指令；
了解下路由的请求缓存对你会有帮助；
控制器篇
建议开启controller_suffix配置参数，并采用IndexController命名控制器类；
原则上控制器类不需要继承think\Controller；
给你的控制器类继承一个公共的基类例如Base便于统一调整；
需要的话在你的基础控制器类中引入traits\controller\Jump；
API开发尽量使用资源控制器（命令行php think create:controller 可以快速生成）；
控制器类中避免写太多的业务逻辑，交由模型类完成；
尽量避免直接操作数据库类，而是在模型类中做好封装；
可能的话尽量在控制器层完成数据验证；
不要试图在初始化方法中调用redirect助手函数，而用$this->redirect方法替代；
始终在控制器方法中return而不是echo以免影响请求缓存；
用json、view以及redirect助手函数进行响应输出；
用abort助手函数抛出HTTP异常；
遵循驼峰法命名你的控制器类和文件名；
永远不要在操作方法中（事实上是任何代码中）使用exit；
数据库篇
千万不要用驼峰法命名数据表和字段；
如非必要避免直接操作Db类；用Db类的name方法而不是table方法；
用视图查询view方法替代join方法；
查询操作尽可能的使用field方法，哪怕是field(true)；
如果要批量执行SQL语句使用batchQuery方法；
用value方法获取单个记录的某个字段值；
用column方法获多条记录的某个（或者某些）字段值；
灵活使用cache方法进行查询缓存处理和删除（不仅是查询可以用cache方法）；
使用fetchSql方法直接返回sql语句而不实际执行CURD；
部署之后记得执行命令行的php think optimize:schema指令；
strict方法可以避免多余的数据字段抛出异常；
关于日期和时间的查询不妨试试whereTime方法；
数据库的大多数操作都是自动参数绑定的，一般情况下无需手动使用bind方法；
insert方法返回的是影响的记录数而不是主键；
使用insertGetId方法插入数据并返回主键；
delete(true)可以无条件的删除数据；
select和find方法支持闭包，但尽量不要和链式操作混用；
需要查询大量数据并且分批处理的话使用chunk方法；
对find方法使用主键查询并且cache(true)的话缓存是自动更新的；
模型篇
不要以为模型性能比Db差，这点差别还不抵不过一条SQL查询，而带来的便利是可观的；
模型的好处千言万语抵不过两个字：对象（明白人都会懂）；
模型类一般直接继承think\Model，如有必要也可以继承一个公共模型基类；
如果你的模型类没有任何的数据库操作的话不需要继承任何类库；
模型类不需要使用类后缀Model（对应前面的控制器类后缀）；
模型的save方法既可以新增也可以更新（而且是自动识别）；
模型没有链式操作，所有链式操作都是调用的数据库类Db；
模型支持事件而数据库类的操作不支持事件；
统一在模型的init方法（静态方法）中注册模型事件；
模型没有数据表前缀的概念只有对应数据表（完整表名）的概念；
每个模型对应一个数据库查询对象Query，彼此独立；
每个模型可以单独定义自己的数据库连接信息；
模型名不一定就是数据表名，而且可以单独定义数据表名称；
模型查询的数据返回永远都是当前模型对象实例（而不是数组，Db类查询才是数组）；
模型对象可以直接进行数组操作并不需要使用toArray转换（包括模板输出）；
模型的查询操作建议使用get和all方法（静态方法）；
要在模型查询中使用链式查询可以定义查询范围或者使用闭包；
用save方法新增数据的返回值是影响的记录数而不是主键值，获取主键直接获取当前模型对象的属性值即可；
如果仅仅是需要主键之外的查询条件的话，可以在get或者all方法的第一个参数使用数组；
要模型查询后的原始数据可以使用getData方法；
模型的关联操作可以让你省去很多的关联查询；
鉴于性能考虑，关联预载入查询绝对是关联查询的首选；
一对一的关联关系，尤其是主表和附表的关系考虑使用聚合模型；
软删除必须使用模型的delete方法（而不是数据库类的delete）才有效；
不要在修改器中修改多个属性；
修改器是模型才有的功能，调用数据库Db类的写入操作方法是不会触发的；
不要在同一个模型实例中多次调用save新增数据，一旦新增数据成功后，再次save就是更新数据了，除非你显式调用isUpdate(false)；
用模型事件取代自动完成；
其它篇
开发过程中开启调试模式，部署后记得关闭；
如果不是API开发的话开启页面Trace显示；
不要轻易忽视异常页面的任何信息，它们不是摆设；
开发中一定要严格注意大小写，这是基本素质；
如果是接口开发尝试使用 postman 进行调试；
使用命名空间和自动加载，避免直接 require 及 include ；
不建议使用 import 和 vendor 方法；
应用目录下面的common.php（注意不是command.php）可以添加应用的函数，并且实时生效；
不要手动下载扩展包放入vendor目录，不支持composer安装的扩展类库直接放入extend；
只要是使用命名空间的第三方类库，都是可以直接在TP5下面使用的；
尽可能的采用MVVM设计架构来替代MVC架构，充分发挥TP5的API优势；
如果使用模板，避免在模板中使用过多的数据逻辑；
模板继承和模板布局是可以配合使用的；