@dvaknheo 你暴露了，就凭你不知道 guard 和 attempt 方法还说自己弄懂了 laravel auth....，guard 和 attempt 就是 auth 的组成部分。

@dvaknheo

```php
public function postLogin(Request $request)
{
$vaptcha = Vaptcha::make();

// 验证验证码是否正确
if (! $vaptcha->validate()) {
// 验证不通过，返回错误提示信息到前端
return $this->error($vaptcha->getError());
}

$credentials = $request->only([$this->username(), 'password']);
$remember = (bool) $request->input('remember', false);

// 验证参数
$validator = Validator::make($credentials, [
$this->username() => 'required',
'password' => 'required',
]);

if ($validator->fails()) {
return $this->validationErrorsResponse($validator);
}

// 登陆并返回成功信息
if ($this->guard()->attempt($credentials, $remember)) {
return $this->sendLoginResponse($request);
}

// 返回失败信息
return $this->validationErrorsResponse([
$this->username() => $this->getFailedLoginMessage(),
]);
}
```

这里我截取一段使用 laravel auth 实现的登陆功能，换成你的说法，就是你口中“应用工程师”该写业务代码，多简洁易懂，这代码不好维护吗？跟业务无关吗？

而其中$this->guard()->attempt 这样的 auth 底层实现，就是你口中“核心工程师”写的登陆的轮子，框架内置的轮子不比大部分“核心”工程师写的优质、好用许多吗？

laravel 这样设计的更强大之处在于，“应用工程师”甚至不必关心登陆验证的数据存储细节，例如你是想使用 session 登陆、还是 auth2.0 登陆、还是缓存 token 之类的等等，都可以通过配置文件和中间件随意切换，不需要改动一行业务代码，这不是更简单了吗？而登陆到底是要用 session 还是 auth2，这个可以交给“核心工程师”去实现。

而且不仅如此，laravel 的几乎所有组件都是这样的模式，系统把大部分功能都抽象成了一个统一的简单易用的功能接口，“应用工程师”写业务代码并不需要关心这些功能的具体实现，只需要简单的调用数行代码就行，可以把专注点放在业务上，而这些底层组件可以采用第三方扩展包也可以由“核心工程师”自己编写，然后通过配置文件切换而不用影响业务代码。

你所考虑的，laravel 早就想到了。

@dvaknheo

不是说核心工程师造轮子，是核心工程师调轮子。应用工程师一个 DuckPhp 命名空间的东西也用不到。
DuckPhp 用 phpstan 检查过规范，phpunit 单元覆盖测试 100% 。
--------------------------------------------------------
“应用工程师一个 DuckPhp 命名空间的东西也用不到”，你这句话翻译一下就是：这个框架基本什么基础功能都不提供。

那你让“核心工程师”调什么？你有提供 HTTP 请求和响应处理功能有吗？配置文件功能有吗？文件处理功能有吗？缓存工具有吗？参数表单验证工具有吗？还有更多基础功能你都没有，那你怎么让“核心工程师”不造轮子？

最终的结果就是各种所谓的“核心工程师”拿到你的框架就是群魔乱舞各种瞎写，最后出来的就是惨不忍睹、很难维护的糟糕代码，这也是很多所谓自研框架公司的现状。


+ blade 模板 违背了 PHP 代码就是视图的原则
+ 滥用 ArrayIterator foreach, 使得没法 dump
+ orm 使得调试更麻烦了
+ 退化到路由表了。有简单的文件路由不用。
+ 中间件使得调用关系复杂化。
--------------------------------------------------------
PHP 代码是视图的原则？？这都 2020 年了，您还崇尚 HTML 和 PHP 混编呢？这写出来的代码能维护？大清早就灭亡了亲；
orm 使得调试更麻烦了，laravel 提供了多种方式可以让 ORM 转化成 sql 调试，调试虽然麻烦了一点，但 ORM 带来的便利程度远远大于麻烦程度；
退化到路由表了。有简单的文件路由不用，中间件使得调用关系复杂化，从这个描述就说明，你根本没理解 laravel 路由和中间件的好用之处。

中间件最大的好处就是能把各种与业务无直接关联的代码抽象出来，放在中间件里面，每个业务控制器 action 就可以通过配置轻松增减、切换各种不同的中间件，而不需要改动业务的一行代码。比如日志收集、登陆验证、接口权限判断等等，我甚至可以实现各种逻辑不同的登陆中间件，随意切换，如果你把这些跟业务无关的代码放在控制器中，那最终只会造成你代码杂乱、臃肿和难以维护。
那么 laravel 的路由结合中间件的配置，简直不要太好用，我可以轻松给各种路由进行分组；尤其是方便了开发者写扩展包，可以以最大的自由度定义扩展包路由，以及其实用的中间件，简直太牛逼了。其他的大部分框架，都没有这么好用的路由，也难怪 laravel 的生态如此强大，可以说 laravel 的高质量的第三包扩展包的数量可以吊打任何一款 PHP 框架。

可见一个成熟的设计是多么重要，细节和生态才是一个框架的根本。laravel 的方方面面的设计，其实都是兼顾了普通开发者和第三方扩展包开发者的需求的，但很可惜，很多人并不理解其中的意义。

而楼主说的中间件使得调用关系复杂化，这完全可以说是你的水平不够，中间件的配置入口就是公共配置和路由配置两种，能复杂到哪去？堆栈调用复杂？我宁愿看多几十行堆栈调用，也不愿写业务代码和与业务无关代码混杂在一起像乱麻一样的代码。


之前在我本机弄了 laravel 自带的 auth 的版本，发现 laravel auth 连我都没能弄清楚，怎么可能会有国内项目用他那套做验证
--------------------------------------------------------
你这个把我看笑了，你是看不起其他程序员，还是太看得起自己？？ laravel auth 你都整不明白，还好意思大言不惭说这个不行那个不行？建议楼主保持谦逊的态度，对不懂的东西不要乱评判，看了楼主的发帖纪录，就是一直在评判自己没搞懂的东西

+ DuckPhp 秉着 代码和 DuckPhp 关联越少越好的原则
核心工程师写的非业务核心代码才会和 DuckPhp 耦合。
应用工程师写的业务代码是不和 DuckPhp 耦合的。
------------------------------------------------------------
这样做的意义在哪里？用框架不就是为了不重复造轮子吗？框架提供稳定成熟的基础功能，让工程师专注于业务的开发，你让核心工程师去造这些轮子我敢说大部分质量都是很糟糕的，至少我待过的公司中使用自研框架（无框架）的公司，代码质量都是不怎么样的。毕竟一个成熟的开源框架，每个细节的设计都是经过成千上万个项目检验提炼后的成果，很多公司所谓自研核心组件就是想当然和幼稚无意义的重复实现。

ControllerHelper::GetExtendStaticMethodList()
-------------------------------------------------------------
还自创代码风格？？这么多千奇百怪的风格不累吗？自动加载都知道用 composer PSR4 规范了？编码风格也不能统一一下？

至于 Laravel，我有空看一下是不是跑了一万行代码。
--------------------------------------------------------------
现在还有纠结代码行数的，实际上绝大多数用 PHP 的公司都没必要纠结这点代码行数，开发效率和稳定性才是重中之重

@HANXIAO1996 这个确实很难，fastadmin 毕竟已经经过了这么多年的积累，不过梦想总是要有的，不是吗？在开发体验上，我们还是有信心能做得比 fastadmin 做得更好的，甚至好很多。

目前这个项目已经与国内最大的 laravel 社区达成合作，已经是个不错的开始了，毕竟正式版发布到现在才一个月时间而已，后续我们也会不断完善这个项目，并且在生态构建方面也会吸取 fastadmin 的经验。

@ohao 一个 tp 的 fastadmin 打包好，不管去哪个公司，去了先搭环境，下载 wamp，配 fastadmin，然后就埋头苦干...


这个程序员虽然有问题，但从你的这段描述来看，你作为技术 leader 没有尽到自己的责任，公司技术方案的选项是需要经过团队尤其是 leader 仔细研究权衡利弊后才拍板决定的。

如果是你选的 fastadmin，你需要对新人给予上手引导和培训，让新手可以快速熟悉公司的技术体系；

如果不是你选的 fastadmin，那说明你们公司本身就很随意各方面都不完善，新人上来就要求用它自己最熟悉的技术快速出活，看着像一个外包公司，只管实现功能而其他一概不管。简而言之，新手上来埋头苦干而没有任何规划和技术提升的欲望，也是迫于你们公司的现状导致的。

如果是你选的 fastadmin，你需要对新人给予上手引导和培训，让新手可以快速熟悉公司的技术体系；

如果不是你选的 fastadmin，那说明你们公司本身就很随意各方面都不完善，新人上来就要求用它自己最熟悉的技术快速出活，看着像一个外包公司，只管实现功能而其他一概不管。简而言之，新手上来埋头苦干而没有任何规划和技术提升的欲望，也是迫于你们公司的现状导致的。

我是欧皇

@onion606 哈哈哈，现在开放了自定义主题配色功能，用户如果对现在的主题配色不满意，可以随意更改，很方便

@onion606 是的，手机页面用的人很少，暂时没有时间适配，后面会专门优化

@omghonor 哈哈哈，你为什么不让皇受露脸

@bugsnail 后面会找更多志同道合的小伙伴一起维护，生态这个我也会比较重视，fastadmin 就做得不错，这个也是我学习的目标。

laravel-admin 的生态我个人感觉做得比较一般，laravel-admin 的第三方插件大部分插件开发出来之后就不更新了。一方面是因为缺少关注度开发者渐渐丧失动力，另一方面也是因为 laravel-admin 的升级版本差异太大的原因。

@fuxkcsdn 嗯嗯我看了下这个插件，我现在这个系统的功能已经跟这个插件差不多了，后面也会继续优化

content 完全释放出来，你是指自定义页面吧，其实这个挺简单的，$content->body(view(xxx)) 就行了

@bugsnail 感谢建议，那两个按钮只是放出来演示自定义导航栏功能的，这个用过 laravel-admin 的同学会懂。

之所以写这个项目并不是单纯的炫技之类的或者是三分钟热度，主要还是因为太喜欢 laravel-admin 的这个设计，写后台的体验真的是 PHP 后台系统中我没找到第二个能与之匹敌的，基本只要简单的几行代码就能实现一个完善的后台系统，而且每个功能基本都可以以组件化的形式进行扩展非常灵活。

但是 laravel-admin 虽然设计非常棒，功能细节上却有非常多的不足，而且作者又比较忙，很多问题都没时间处理。所以我才花大力气写这个项目，在 laravel-admin 的基础上做了非常多的细节优化，并且增加了非常多实用的功能，简单的说就是功能更多更完善更好用了。

这个项目正式版发布还不到一个月目前反响算是还不错的，既然都花这么多时间写出来了，后续也肯定会坚持维护下去，并且根据用户的反馈与实际场景结合不断完善。
但是 laravel-admin 虽然设计非常棒，功能细节上却有非常多的不足，而且作者又比较忙，很多问题都没时间处理。所以我才花大力气写这个项目，在 laravel-admin 的基础上做了非常多的细节优化，并且增加了非常多实用的功能，简单的说就是功能更多更完善更好用了。

这个项目正式版发布还不到一个月目前反响算是还不错的，既然都花这么多时间写出来了，后续也肯定会坚持维护下去，并且根据用户的反馈与实际场景结合不断完善。

@bugsnail

@fuxkcsdn 很好奇你用了哪个第三方的报表功能，方便发个链接看看吗？

如果你是定义所有模板的话的确非常麻烦，特别是升级，你逐个功能都得重新测试一遍，而且 laravel-admin 版本差异比较大那就更难受了。所以我推荐的是 $grid->setView('xxx') 这样只自定义一个 view 模板，这样就没啥问题了。

@fuxkcsdn 报表功能我也考虑到了，所以支持了双表头报表功能，并且使用也非常简单，只需增加几行代码就行了。

其实你这个都不需要重写源码，只需要自定义 grid 的 view 模板就行了。

@EmptyDX 是的，这个数据统计卡片是模仿 nova 的截图写的

@hst001 前端代码是独立的，在 resource 目录，用 webpack 打包的

@GTim 哈哈非常感谢你的支持，先不必了

@fuxkcsdn 不知道你主要是什么需求改源码？我也是因为对 laravel-admin 的许多细节不满意才开发这个项目，现在对 laravel-admin 做了非常多的细节优化，增加了更多实用的功能