php项目目录的合理划分以及Pipeline组件的使用场景一开始就喷我。首先，你可以先阅读下面这篇文章，这将有助于你提高代码质量。Laravel的18BestPracticesSingleResponsibilityPrinciple很流行介绍的重点是一个函数为一个函数做一些事情。比如我们需要获取用户信息，那么简单来说，写的getUserInfo只用它来做一件事。当然，这只是一种方法。如果它是一个类，我们如何定义它？大多数人遵循MVC规范。现在的开发流程下，大概v，也就是view层早就消失了。mc之间的关系怎么处理好，我建议如下types-app--Model//模型层--Controller//控制器层--Traits--Stores//处理类--Tools//工具类--Routers//扩展路由Traits这个词对于models和controllers的解释就不用说了。关于Traits的书不多。可以看官方手册：https://www.php.net/manual/zh...这里有一些可以复用的。公共函数方法，如getters、validators等，Stores用于存放一些不方便写在models或controller中的代码，比如返回一个产品信息，需要从其他数据库或数据表中完成productlist购买人数、成交额等信息。这个时候，这些东西既不适合controller，也不适合model层Tools工具类。这里存放了一些工具和方法，比如public或者某个数据集。各个组件功能需要用到的常用方法有response方法、logging方法等，在后台管理中，一个function可能会产生5条左右的路由。这时候就需要拆分路由文件了。以上操作当然不能一概而论，应该针对业务场景适当处理，比如简单的后台，管理用户的能力就不需要那么复杂。当不好管理的功能越来越多的时候，它才能恰到好处地发挥出它最大的作用。重要文章什么是Pipeline组件参考文章：【单篇】LaravelPipeline组件的实现原理这是一个很有意思的功能，你应该或多或少用过中间件，你以前是不是没了解过中间件？实际上，中间件背后的逻辑及其实现就是简化版的Pipeline。在第一张图片中，我们的代码非常非常少。最后一张图，返回的数据字段非常非常大，查询语句查询的东西不多。使用场景大致如下。有一批商品信息，我们只知道它的商户id和商品。id(商品表)所以我们需要返回(订单成交订单表)(品类信息标签表)(交易用户属性信息用户表)(折扣信息优惠券表)。这时候，按照前面的逻辑，我们有几种解决方案foreachforeach+class处理可能大多数人会用到第二种方法，循环商品信息，当if需要交易值的时候，去交易值表中查询,然后把第一个方法填进去，不用管嘛，都写在一个方法里给foreach了。极不推荐此时使用Pipeline。通过给它传输数据，给Pipeline的dispatcher添加一个类，比如完成订单周转，可以添加Order::Class等待，最大的好处就是函数和函数耦合，这样即使我们需要修复以后订单成交的代码逻辑，我们不需要修改为这整个逻辑设计的代码。好处是可读性强符合单一职责和低耦合度原则PHP学习交流群：735713840
