复杂的方案是为了解决复杂的问题。微前端毫无疑问是充满复杂性的技术，但有些时候为了业务、为了研发管理流程，你必须选择！

假如你接手了一个技术栈又老体积又大而同时又不能停下进行更新迭代的项目，如果你要进行重构你会怎么办？微前端可以说是这个问题的满分答案。 总结：结合开头的问题，可知微前端是为了解决中后台项目随着迭代体积不断膨胀导致的各种问题（例如：部署，存储）。 NPM式：子工程以NPM包的形式发…

微前端(QianKun)落地级实施和最后部署上线 历时不到两个月，来到新公司后，接到新需求：“要把ERP系统拆分出来，里面有包括PMS、OMS、WNS等等”模块。 当时的第一个想法就是微前端，那么接下

1、关于文件导入的问题（cdn路径）建议能使用npm方式导入的不要在index.html中去额外的导入了。不谈性能问题，如果上微前端，那么你很可能无法完全掌控全局变量2、关于静态资源字体等404问题1

微前端框架qiankun项目实战（二）--踩坑与部署篇 大家好，我是小黑。 在上一篇《微前端框架qiankun项目实战（一）--本地开发篇》发布后，感谢有网友提出了微应用的缓存问题，的确基于第一篇使用

大家好，我是小黑。 公司使用技术栈是vue，最近遇到了一个需求，要把原有后台管理系统的功能模块搬迁到新的后台管理系统上面去。原本这没有多复杂的事，直接复制粘贴改改就可以，但是有这么几个坑点，我瞬间陷入

当前应用为原vue2.0单体通过 qiankun 微应用方式升级为 vue 3.0 + antd + ts，属于纯前端改造，不涉及后端调整。 实际开发中, 子应用加载配置为本地js文件, 我们需要同时调试或测试多个本地以及线上子应用。既多个子应用的联调， 这里其实就是切换不同子…

项目为旧单体项目, 改造为微前端项目。所以原项目存在大量共享工具及组件。当前方案是将这些共享代码根据功能，拆分为第三方包。这其中就包括http请求对象。而后端API并不参入前端业务的拆分，所以我们需要保证子应用与基座使用相同的请求配置。 这里记录相关的解决思路。 我们希望子应用…

当前存在以vue2.6 开发的单例应用, 我们希望使用qiankun ，将该应用转微应用结构。 在保证原功能可用的情况下，使用vue3.0重构部分功能。 这里记录使用vue做微应用开发时，各个应用数据请求代理的配置方式. 我们知道一般，独立使用vue开发单例应用，可以通过配置 …