提升京东海外商城整体用户体验，适用跨团队的协同开发，提供一套架构来明确系统之间的依赖和边界；此方案已经应用到了印尼M端购物车、结算页、订单等核心模块中；本文将会从背景、问题分析、方案设计、应用接入、总结五个方面全面解析微前端在商城的使用。

伏羲项目商办后台（伏羲CMS），作为服务于58商办C端的后台项目，目前涉及联合办公和写字楼两个类目，提供了相关业务操作、C端广告配置、数据统计、角色权限管理等模块。作为商业地产的新平台，伏羲CMS具有功能迭代灵活、业务扩展迅速等特点。

基于全屏iframe的微前端框架--擎天，解决了iframe UI不同步、URL不同步、数据不共享的难题，并充分发挥了iframe作为页面容器的优势，实现了父子应用异步加载、子应用瞬间切换的能力，从而将微前端项目达到单体应用的体验。

为什么要学习微前端？微前端有什么价值？微前端常见框架有哪些？猪八戒前端项目改造实践是如何的？

什么是可微编程？又有什么作用？

本文梳理了基于阿里开源微前端框架qiankun，实现多页签，并实现子应用的缓存的方案，同时还类比了多个不同方案之间的区别及优劣势。

搭建平台解决方案除了常见的 DSL 还是否有其他解决方案？Code In & Code Out 方案的价值在哪里？搭建平台又如何与微前端进行结合？

微前端（Micro-Frontends）是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。

微前端并不是前端领域的新概念。早期希望前端工程能够像后台的微服务一样，项目分开自治，核心的诉求是：

1、兼容不同技术栈

2、将项目看作页面、组件，能够复用到不同的系统中

早期比较成熟的 single-spa，从早期 React 的现代框架组件生命周期中获得灵感，将生命周期应用于这个应用程序，即将整个页面作为组件。

后来蚂蚁金融团队孵化了基于 single-spa 的 qiankun 架构，将微前端进一步的深耕，目标直指巨石应用业务难题，旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用 (Frontend Monolith) 后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。

本人在深入实践微前端之后，深感 qiankun 受制于前端架构的定位，无法使用 Nodejs 等能力快速解决快速发布，构建，管理的困境，因此在此基础上做了一定程度的 APAAS 探索，将本文的项目作为 APAAS 应用快速集成到其他业务系统。

相比于市面上已经开源的微前端框架，Satum 最重要的特点是面向多实例集成的场景，且诸如沙箱、缓存等功能是可插拔的。展开来说，该框架类似 express/koa 等框架，是微内核化的，支持中间件和插件机制。所以可以基于该内核，定制出适合自己团队的微前端体系。

Qiankun是社区的一种微前端框架；MF是模块联邦的意思，在Webpack 5中流行起来的，也属于一种微前端方案。

许多内部管理系统在迭代过程中，不可避免的变得越来越庞大，并且由多个团队维护开发，对前端来说以传统的一整块页面站点代码进行开发，显然是笨重且低效的，比如：

• 多团队开发、测试和部署不分离，代码混乱，发布有风险
• 代码庞大，页面加载资源多，性能低

收钱吧运营管理系统和许多内部系统一样，拥有复杂、大量的页面，并且不同模块由不同团队维护。为了使各个开发团队独立维护，我们使用了微前端的策略，经过长时间的实践，它也日益成熟。

”微前端”这个词现在对前端同学来说已经比较熟悉了，各种方案也已经落地开花，比较主流如single-spa、乾坤，后来的也有webpack模块联邦。爱番番团队在项目初期后端微服务化的过程中，前端也落地了自己的微前端方案，更好的服务于敏捷开发，提升交付效率。

本文主要围绕了前端录屏工具Hubble在微盟微前端的应用场景，介绍了Hubble的功能点、使用以及简单做了相应的技术解析。

达达快送的运营系统，由各个业务线的子系统组合而成。随着业务的高速发展，子系统数量呈现爆炸趋势，复杂度急剧上升。2018年3月创建时，只有3个子系统。2021年3月拆分时，达到15个子系统。

由于各个业务线的子系统迭代周期不同，所以运营系统每天都有上线。表现出来的现象是：排队上线、无法回滚、构建缓慢。

运用微前端和 uni-render 技术，让商品中台的前端系统变的更加灵活、更加具有可观察性。

iframe是一个天然的微前端方案，但受限于跨域的严格限制而无法很好的应用，本文介绍一种基于 iframe 的全新微前端方案，继承iframe的优点，补足 iframe 的缺点，让 iframe 焕发新生。