DuckPhp 1.2.4 发布，终极架构，文档完善了

项目地址： https://github.com/dvaknheo/duckphp
作者 QQ: 85811616
官方 QQ 群: 714610448

phpstan 第 7 级检查通过。php-cs-fixer 代码风格通过。phpunit 全覆盖测试通过。

名称统一成了 DuckPhp，和命名空间一样。

重复一下 DuckPhp 的特性：
+ 可以在不改动库文件下，替换所有实现。
我用 CodeIgniter 的时候，基本上没见到个 CodeIgniter 系统代码是官方原版的。都是各种魔改。
Composer 时代之后，直接改 vendor 的文件确实是不可取的
所以满足在不改动库文件下，替换所有实现这是对现代框架的基本要求。不实现这个目标的框架没存在意义。

+ 可以非固定全站使用的框架。
很多框架都要要求你配置整站才能使用，DuckPhp 很灵活，不需要配置成整站。
甚至启用自带扩展能做到连 Web 服务器都不用配置的单一入口文件模式。
还有一种玩法是 A ,B 两个项目独立开发，然后合在同一个服务器上。
其他框架很麻烦，命名空间都是用 App，路由处理还要折腾很多。
DuckPhp 不同项目不同命名空间，B 项目作为 A 项目的插件使用。

+ DuckPhp 秉着代码和 DuckPhp 关联越少越好的原则
核心工程师写的非业务核心代码才会和 DuckPhp 耦合。
应用工程师写的业务代码是不和 DuckPhp 耦合的。

+ DuckPhp 是无第三方依赖的单一的 Composer Library
这点很重要么？很重要。引用的第三方组件出了 Bug 人家升级了怎么办。
Library 则很方便的插入第三方框架里使用。
DuckPhp 工程的初始化就是复制 template 目录，修改相应模板。
甚至可以直接运行 template 目录。

--

从 CURD 角度的应用工程师角度来看，基本不需要动什么。

使用 DuckPhp 的感觉就是，默认的就已经足够了。

应用工程里那些高级的东西，让核心工程师来做。
而核心工程师呢，如果不满足，那么就调选项。
如果选项还不行，那就入口类里调整。
更高级的是自己做组件和替换默认组件。
对于应用工程师，就看那些 Helper 函数多出来什么就够了。
var_dump(ControllerHelper::GetExtendStaticMethodList());

最高级的玩法是把当前工程 A 作为扩展给 B 工程复用。
也没什么难度，入口类里加额外代码就是。(引入 AppPluginTrait)

1.2.3 版本，我在 yii3 demo 上内嵌了个 DuckPhp 作为实现版本

https://github.com/dvaknheo/yii-demo

在入口 index.php 处拦截如果 DuckPhp 能实现，则用 DuckPhp 的实现版本，否则继续
所有 DuckPhp 版本的实现的文件，都在一个目录下，可以对比一下。
https://github.com/dvaknheo/yii-demo/tree/for_duckphp/app
之前也折腾过 laravel 的 demo，结果丫自己的 auth demo 我看的都绕半天，何况其他小白。

用 phpunit-codecoverage 看了一下 thinkphp 5.1 hello world 。1052 / 19241 行代码。
也就是不干什么事情都至少有 1000 行代码空跑了。DuckPhp 是 339/5252 行，所以 DuckPhp 是高效的。
当然，这只是对性能的粗略估计。比如一个 autoloader 的 file_exists 判断性能上就能顶很多行
（尤其是我在 wsl1 环境下 IO 性能惨不忍睹。
至于 Laravel，我有空看一下是不是跑了一万行代码。

DuckPhp 的 swoole 支持是有的，只不过现在不作为重点了，workerman 有空的话我再看看。
DuckPhp 切换成这些模式是无缝的。只是我不觉得 web 不是 swoole/workerman 该做的主战场。

现在想找个能很好的演示 DuckPhp 的工程来做。演示一下 DuckPhp 的魅力。