dvaknheo

我现在 提了个 pr，想再提交第二个 pr 不知道怎么处理。
听说最快的方案是 删掉重新 fork，然后修改提交

@reiji vanillajs 确实是个好东西，不用编译，比 vue 快多了。
用 vanillajs 的可以一起握爪

@stardustree 文档不应该是产品的产出么？

@ywisax 谢谢
workerman 4 已经有 request/response，psr 的标准似乎有点问题，各家的 request/response 都没和官方的实现一致
我这简单封装，没屏蔽 request/response.

workerman 只是 fork 子进程，没和 swoole 那样搞协程。 所以内存管理要比 swoole 省事得多？
或者我理解有误么

用 pageant 那个小东西管理 不同的密钥？

v2ex 抽风也是这个原因？

补一下，fastadmin 代码其实也没那么难对付，毕竟我的新后台连 thinkphp 都不用。数据库结构也轻型，就是前台代码有点多。
当然，比那些前端代码多得搞前后端分离的还是好的

最近正准备抄个好后台。

由此去看了一下 pear-admin-think 。layui 不是问题。主要
[现在很多后台存在的一个重大问题] ：
我希望出问题的时候，编辑小妹截图，丢个链接我就能打开所在页面。 现在的好些后台都没满足这个条件。

fastadmin 的问题是太古老。
thinkadmin 的 thinklib 命名空间和官方的混淆。

我记得有谁的是 分成几个模块 composser 载入的，忘记了。 这模式才是好模式。

我并不喜欢前后端分离的后台，干起来太折腾，本来后端一人搞定的，变成要前后端配合。
（好吧，这也不好抄，或许更好抄，把 api 层替换就是

后台的基本功能 不要太多，其他的可以再加就是

必要的功能：

1 后台记录 ——哪个小妹对价格动了什么手脚。
2 管理员权限——客服和销售看不同的部分。
4 菜单显示， 可操作的权限

这就基本的了
什么其他东西，可以在这之上再折腾。

MVC 缺层， 很欣慰，现在大家都意识到了这个问题， 都加了 service 层。
虽然我规范是第一方 business 后缀，第三方用 service 后缀明确是第三方的还是不错的
但是问题在于 service 层分出来后，C 层还是有好多业务逻辑代码，V 层还是 做额外计算。

作为库的类，一定要让方便用户修改。
static function foo() // 反正 new 一个 model 没意义 魔改的话是会连表都改过的哦。