### 2018 年 12 月 16 日 发布 `5.2`版本的设计初衷是致力于提供一个更规范、更易用和更高效的轻量级PHP框架，针对这个初衷我们总结归纳了一些新版框架的指导思想，不过由于目前`5.2`版本还是测试阶段，有很多方面的调整会在后续的更新中逐步改进和完善到位，也不排除会有一些额外的调整。 欢迎有更多的开发者加入新版的架构设计中来，给我们提供更多的反馈和建议。 ## 完全依赖`Composer` ThinkPHP从`5.0`开始拥抱`composer`，支持通过`composer`安装，同时也支持单独通过`git`安装，而且有自己的独立的文件自动加载机制，所以说并不依赖`composer`，这也是官方把`thinkphp`目录放到项目根目录的原因之一。 经过两个版本的用户培养工作，`5.2`版本将彻底依赖`composer`安装，并且由`composer`完全接管框架的自动加载，原来的`Loader`类也已经取消了。框架目录按照`composer`的安装规范纳入`vendor`目录。 ## 基于`7.1+`强类型约束 基于PHP`7.1+`版本的设计主要是为了使用PHP7的强类型约束功能，`7.1`对方法变量类型的支持已经很完善了。而且`5.2`版本也率先在主流框架中开启了严格模式，所有的变量和返回值都会强制进行类型检查，此举可以帮助开发者提前发现一些问题隐患，从而更规范的进行变量使用。 >[danger] 基于`7.1+`不等于不支持PHP`7.2`甚至更高版本，因为核心框架内部没有使用`7.2`版本的任何特性。 ## 用法尽量统一 早先版本的ThinkPHP虽然功能强大，但用法太多一直为开发者所诟病。实现同一个功能有太多的用法，每个人都有自己的一套用法，导致项目代码规范不统一。`5.2`在设计之初，就奔着精简和统一用法的决心，让核心的用法尽量统一，便于团队形成一致的使用规范。 一个很典型的例子就是新版的数据查询取消了`get`/`all`，无论是`Db`类还是模型都统一使用`find`/`select`方法（事实上，5.1最新LTS版本已经可以统一使用了，不过没有废除`get`/`all`），这样的例子还有很多，暂时就不一一叙述了。 另外一个用法统一的表现是在一些方法的参数上，不再提供多种用法，例如模板变量的赋值之前版本下面两种方式都支持： ``` $this->assign('name', 'think'); $this->assign(['name' => 'think']); ``` 现在只能使用后者，统一传入数组参数。 ## 惯例重于配置，规范重于灵活 ThinkPHP`5.0`框架在很多方面比较灵活，但这样容易导致缺乏规范，`5.1`版本由于取消了系统常量对框架目录的自定义做了严格的规范，这一现象有所缓解。`5.2`版本更侧重于惯例和规范，而不盲目提供太灵活的设置和调用。 ## 拥抱`PSR`规范，但不盲目 新版会遵循更多的`PSR`规范，但鉴于很多旧的`PSR`官方库的接口定义版本过旧导致没法进行强类型约束，因此不排除会做一些可能的变通。 想必[PHP FIG](https://github.com/php-fig)组织制定PSR规范的同时，给出的接口规范只是一种示例而非强制吧。 ## 提供建议使用的助手函数 对于助手函数的使用，仅提供推荐和允许使用的，清理一些不必要或者不推荐的。 ## 组件化和可组装原则 关于核心是否需要组件化一直在内部争论的部分，在现代开发模式中，已经完全可以基于`composer`里的各种组件组装自己的框架，ThinkPHP也会致力于提供各种组件，但不一定确保核心框架是完全组件化。但可能的处理方式是尽量在内部形成低耦合和高内聚，而非完全的组件化。核心非必需组件可替换及组装，同时低于20%的使用场景内部独立设计为可配置替换，低于5%的功能场景尤其是增加性能开销的则考虑直接从核心移除，需要的时候通过扩展继续使用。 比如，路由检查、请求缓存以及多语言支持功能已经纳入`AppInit`事件监听设计，完全可以在应用中自行控制和替换。 ## 功能精简，性能提升 之前版本的框架设计了很多很多细节的功能，但使用的频率非常之低，占用了内存不说，对于不需要这些功能的开发者来说，阅读文档和理解一堆配置参数也会带来更多的困惑。事实上，很少有项目能用到核心框架超过50%的功能，此次版本的功能精简对于大部分应用开发而言，几乎没有任何的影响，但很明显能够感受到性能的提升。