你的问题的答案实际上在下一句话中给出，然而，我承认，当我开始在拉腊维尔时，我会非常困惑。所以基本上：
由于外观非常容易使用，并且不需要注入，因此可以很容易地让类继续增长，并在单个类中使用许多外观。
这意味着过多地使用外观（不仅在Laravel中，而且在一般情况下）可能会使代码更加臃肿，更难阅读。（违背了为什么应该使用外观背后的要点）
门面也可以成长为做许多事情超出其最初的目的，作为refactoring guru（没有从属关系）说，门面-当使用不当-可以变成god objects。
如果你打算使用外立面，但你仍然不清楚如何使用它们，我建议你仔细阅读Single-Responsibility principle和（未来的意见），如果有疑问，不要使用外立面。

示例

本部分是一个“不要这样做”的指南，适用于快速阅读《所以，不要这样做！》的读者

我已经编辑了我的答案，包括一个相当荒谬的例子，门面过度使用在两个不同的方式。
1.您意识到外观确实解决了依赖项注入模式的问题，谁愿意担心作用域、静态和特征的所有问题呢？所以您开始使用外观来处理所有问题。需要在前面的查询中添加where？很简单！为它创建一个外观，并将其命名为Scope::where($model, $column, $equals)，想要与数据库对话，但DB::query太长了？外观支持您，把它们放在一个DataModel::longQuery()中，然后在任何地方使用它们。厌倦了一直调用ProductResource::collection吗？把它放在一个新的名为Resource::collection($model)的外观中。
1.您已经添加了一个外观，可以帮助您生成支付链接，因此您将其命名为Payment，最初将其与Payment::generateLink()一起使用，过了一段时间，您会发现还需要为网站内支付小部件生成视图，因此您添加了一个Payment::view()，几个月后，当您需要与支付提供商讨论发票历史时，您只需将其添加到Payment::getReceipts方法中，您的支付外观现在是一个巨大的类，在同一个地方处理太多不相关的事情。
在这两个例子中，你可以通过常见的编码错误清楚地看到对外观的过度使用。虽然我的例子有点夸张，但我认为很容易想象这些事情在真实的生活中几个月的时间里是如何发生的。