微前端开发常见问题总结。前端应用程序可以独立运行、开发和部署。微前端不是一个简单的前端框架或工具，而是一套架构体系。它的发展会遇到各种各样的问题。今天整理出来分享给大家！1、微前端只是Web端。为什么只有网络？到目前为止，我们主要接触的是Web，但它的概念和思想可以应用于任何类型应用程序的微前端（移动应用程序、客户端应用程序......甚至CLI工具）只是“插件架构”的一个奇特名称”。但是，插件界面如何设计，使用插件运行应用程序需要什么条件，则是另外一回事。图1显示了一个非常通用的插件架构（来源：OmarElgabry）。该架构没有运行位置的概念。它可以运行在手机上，也可以运行在Windows上，甚至可以运行在服务器上。2.微前端需要大团队。如果解决方案超级复杂，那么我一定会找到一个简单的。有些问题需要复杂的解决方案，但好的解决方案通常很简单。根据具体情况，甚至可能不需要分布式团队。拥有一个分布式团队是采用微前端的首要原因之一，但不是唯一的原因。另一个很好的理由是特征的粒度。如果您从业务角度看待微前端，那么您会发现启用和禁用特定功能的能力是有意义的。针对不同的市场，使用不同的微前端。回到简单的权限模型是有意义的。无需编写代码来根据特定条件打开或关闭某些东西。所有这些都留给公共层，可以根据（可能是动态的）条件激活或停用。不能或不应该使用的代码也不会交付。虽然这不应该是一层保护，但它肯定是一层便利性和性能。用户不会感到困惑，因为他们所见即所得。他们看不到未交付的功能，因此不会在无用代码上浪费字节。3.微前端不可调试对于任何类型的实现（或讨论的底层架构），都可能削弱开发体验。处理这种情况的唯一方法是将开发人员放在首位。实现的首要原则应该是：让调试和开发成为可能。使用标准工具。一些微前端框架根本不接受这一点。有些需要在线连接、专用环境、多种服务等，这不应该是标准的，也绝不是常态。4.微服务需要微前端（反之亦然）解耦的模块化后端可能为解耦前端打下良好的基础，但通常情况并非如此。后端单一，前端模块化也是完全可行的。例如，为了简化个性化，可能需要结合授权、权限和市场。同样，微服务后端并不能证明将类似的模式应用于前端是合理的。许多微服务后端由单一用途的应用程序操作，这些应用程序没有添加任何功能，只是表面上的变化。5.微前端需要一个单一的存储库要创建一个微前端解决方案，你需要利用一个单一的存储库，最好使用像Lerna这样的工具。我不同意这一点。当然，单一存储库有一些优点，但也有明显的缺点。虽然有一些微前端框架需要联合CI/CD构建，但大多数不需要。联合CI/CD构建通常会产生单一存储库，因为它们的设置要简单得多。但对我来说，这是整体重新包装。如果你在单个存储库上进行联合构建，你将失去两个非常重要的优势，这两个优势使微前端具有吸引力独立部署和独立开发如果你看到一个需要单个存储库的微前端解决方案：就那样做吧。一个设计良好的单体系统可能会更好，没有分布式系统的所有问题。以上就是微前端开发常见问题和误区的介绍，希望对大家有所帮助。
