php 健全,DuckPhp 1.2.4 发布，终极架构，文档完善了

项目地址： 作者 QQ: 85811616官方 QQ 群: 714610448phpstan 第 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 作为实现版本在入口 index.php 处拦截如果 DuckPhp 能实现，则用 DuckPhp 的实现版本，否则继续所有 DuckPhp 版本的实现的文件，都在一个目录下，可以对比一下。之前也折腾过 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 的魅力。