随着前段业务场景越来越复杂，业界很多团队都开始探索实践一种可以解决工程膨胀，开发维护困难，团队合作开发效率低下等问题的工程拆分治理方案。微前端这个概念也越来越多的被提及，并在各个项目中落地。
各个团队面对各种各样的问题也有着各自不同的处理方案。诚然，任何技术的实现都要依托业务场景才有意义。我们团队近期由于需要集成前端到统一的门户网站，为了能够独立的开发部署提升效率，减小团队合作的摩擦，就对微前端的进行了落地。
其实，就微前端的概念而言，就是将web应用由单一的大单体转变为多个小型前端应用聚合为一的应用，让各个开发团队应用可以独立开发，独立部署。不同团队就各自的应用场景探索出了不少实现方案。例如iframe、Web Components、应用路由分发、Nginx路由转发等等。
为了获得良好的用户体验，实现无感切换，我们最终采用了应用路由分发的解决方案，也就是说我们的前端应用，集成到一个父应用上，通过父应用来进行路由管理。由于一些原因，我们没有选择主流的微前端框架（qiankun、single-spa）来实现，于是我们也不得不面临微前端架构方案中有两个非常关键的问题，即JS隔离和CSS隔离。
关于JS隔离，我们并没有为子应用创建独立的JS沙盒环境，JS的作用域和闭包机制已经能够满足我们现在的应用需求。在开发过程中面临的主要问题来自CSS隔离的问题。由于是跨团队，跨时区的合作开发，经常会发现开发代码的样式被其他团队开发的样式给强行覆盖了。Google Chat里经常会有人声讨样式问题，开发人员需要时刻在线，为!important而战。
通常避免这种冲突的实践是通过约定 css 前缀的方式来避免样式冲突，即各个子应用使用特定的前缀来命名 class，或者直接基于 css module 方案写样式。约定的方式也有一个无法解决的问题，我们在项目中引入了第三方组件库antd，父组件里也引用了antd。各自页面中又有一些定制化的需求，需要修改那些不支持定制化的全局样式，这样最终也会演变成!important之争。
同时，父组件开发团队认为一些全局样式应该他们掌握，会直接在body h1、body a等样式上打上!important，导致子应用的样式出现问题。其实MDN文档上面早有说明：
一定要优先考虑使用样式规则的优先级来解决问题而不是
!important只有在需要覆盖全站或外部 CSS 的特定页面中使用
!important永远不要在你的插件中使用
!important永远不要在全站范围的 CSS 代码中使用
!important
css优先级是基于不同种类选择器组成的匹配规则，文档树中元素的接近度对优先级没有影响。这样就导致子组件中的在样式声明在竞争中并没有优势。
那么我们认为在合作开发中，该怎样保证css污染呢？
其实要彻底隔离 css 污染，当前有两种方法，iframe 和 shadow dom。iframe 缺点颇多，此处不再赘述。shadow dom确实天生隔离样式，我们很多的开源组件库都使用了shadow dom。但是要把整个应用挂在shadow dom风险还是太大了。会出现各种各样的问题。
因此，在应用路由分发这种语境下，基层程序员现身说法，希望这里我们可以采用一定的编程约束：
尽量不要使用可能冲突全局的 class 或者直接为标签定义样式；
约定全局样式，由父组件负责维护；
定义唯一的 class 前缀，project_name-xxx；
修改第三方组件样式，使用更精确的css选择器
当然，现在有许多优秀的微前端框架，也很贴心的帮我们实现了JS隔离和CSS隔离，大家根据自己项目需求选择就好了。
