背景目前社区比较关注微前端应用样式的“隔离”。网上已经有很多文章介绍微前端的风格隔离方案。但是，如果微应用的风格只有“隔离性”而没有“可控性”，那么微应用的风格就是固定的：就像一个不接受外部参数的函数，永远只做预先定义好的事情并且不接受用户的呼叫控制和配置。在这种死板的微应用架构下，宿主应用很难控制整个站点的风格主题，因为微应用本身就具有封闭性和顽固性。应用场景将大大减少。例如，以下需求很难实现：主题品牌颜色从橙色升级为浅蓝色，浅色/深色主题在线切换。同一个微应用在多个主机中使用。在某些主机中，它显示为橙色；在其他情况下，它看起来是蓝色的。以往的实现方式需要巨大的成本：比如对每个微应用，为每个主题构建一个css，然后根据宿主当前的主题状态，使用js切换每个微应用的css。而且，任何涉及主题的修改都需要开发者修改、重建、发布多个微应用，非常繁琐。根本原因在于微应用的样式是硬编码的（并实现了样式隔离），无法通过宿主的配置来改变，主应用和子应用之间缺乏信息传递。因此，风格控制的需求就诞生了：当来自不同项目（不同团队，或者不同时期开发的应用）的UI集成在一起时，需要风格控制来实现风格的封装性和可控性。样式控制理论也适用于业务组件和块。样式控制方案介绍本文分享一种通过CSSVariable实现微应用样式控制的方案：微应用的样式不再是固定的，宿主应用可以通过“传参”的方式进行控制。在这个方案中，微应用的样式就像一个带有可选参数的函数：functionrenderStyle(cssVar1=defaultVar1,cssVar2=defaultVar2){//使用cssVar1,cssVar2,cssVar3来渲染样式//其中cssVar3来自环境捕获通过闭包，调用者无需显式传入}在封装内部样式的同时，对外提供了可配置的API。更灵活地满足各种场景的需求。根据样式变量的默认来源，样式控制方式可以分为两种：隔离优先：微应用有自己的默认主题。默认情况下，它使用自己的主题，不受宿主环境的影响。开箱即用，无需任何配置。主人在掌控之中。当宿主想要控制风格时，可以准确、按需、显式覆盖每个微应用的主题变量，确保整个应用和谐一致。继承优先级：微应用的样式变量默认继承宿主环境的值。主机不需要显式覆盖。下面通过几个简单的例子来介绍本方案的实现思路。隔离优先模式的微应用默认使用自己的主题，不受托管环境的影响。宿主可以显式覆盖其中的样式变量。开箱即用的默认主题是微应用挂载的样式：/*microappcss*/.widget-k7na5-default-theme{--button-bg:orange;}.widget-k7na5-btn{background-color:var(--button-bg);}其中widget-k7na5为微应用的类名前缀，实现样式隔离。可以使用网上各种实现样式隔离的方法（如css模块、css-in-js），都可以与本方案结合使用。其DOM结构如下：
