支持自动升级的架构

所有的逻辑和控制器，都放置恰当的钩子，以便开发者“定制底层代码”，钩子将达到的效果，是完全覆盖底层。

然后内置一个更新代码的脚本，将固定的文件更新到本地。

部分文件建议锁定，不修改，在开头注释中写清楚。

自动升级的意义不在于无缝的底层升级，实际上，任何底层的升级，都有可能破坏现有的上层的代码调用方式。自动升级的意义在于，大多数的功能都在优化底层、修复bug、增加底层方法、扩展底层方法，此类更新，下游用户应当积极跟进。框架更新的基本类型有：

以上类型的更新，下游用户应当积极跟进。对于底层代码，提供扩展机制，以供下游用户定制同时不妨碍更新。对于系统功能，提供适当的事件机制，以供下游用户以扩展的方式定制，而不妨碍更新。

面对破坏性更新，即改变了原有方法用法的更新，应当提供完善的更新说明，让用户自行决定。

根据作者的经验，作者使用本框架实现了很多内部使用的项目，当面对新特性时，一般其他的项目也会需要这些特性，例如：

本特性的另一个意义在于，随着框架的更新，后期的破坏性更新会越来越少，对于只是基于框架开发而没有对框架进行定制的用户来讲，自动升级很有用处。

事件埋点整理：

事件埋点中，纯扩展功能，不影响主流程的，无需任何返回。

影响视图的，需要返回view_content，包含：

比如：

return ['view_content'=>xxx->fetch('login/ext/demo_login')];
return ['view_content'=>xxx->fetch('login/ext/ulthon_login')];
];

影响主流程参数的，需要返回vars，包含：

比如：

return [$vars=>[xx=>xx]]

想要完全重写页面的，返回response，包含：

比如：

return [response=>Response]

但注意，此种方式会等所有时间执行完，返回最后一次的响应。

想要中断页面的，抛出指定的exception，此时按正常业务返回。

注意，并不是任何返回都有用，需要参考埋点针对返回内容做了哪些适配，比如在视图中的事件，只会处理视图的返回，其他类型不考虑。但一般情况下，抛出响应和相应参数都有效。

升级流程的基本功能：

临沂奥宏网络科技有限公司 / ulthon_admin