样式隔离实战：微前端与CSS模块化解决方案
UX子谦先看效果，再看代码
我最近在搞一个微前端项目，主应用用 Vue，子应用有的是 React，有的还是老掉牙的 jQuery 项目。样式冲突直接炸了——点个按钮，整个页面排版乱飞。最离谱的一次是子应用的一个 .button 把主应用所有按钮都变绿了，客户当场打电话过来问“你们网站中毒了吗”。
后来干脆上了样式隔离，亲测有效的方式就三种：CSS Modules、Shadow DOM、和 build-time 加前缀（比如 PostCSS 插件）。下面直接上实战代码，谁用谁知道。
/* 传统写法，危险！ */
.button {
background: green;
padding: 10px;
}/* CSS Modules 写法 —— 推荐新手直接用 */
.container {
display: flex;
}
.title {
font-size: 18px;
color: #333;
}// 组件里 import 进来的是对象
import styles from './MyComponent.module.css';
function MyComponent() {
return (
<div className={styles.container}>
<h2 className={styles.title}>Hello World</h2>
</div>
);
}Webpack 或 Vite 默认支持 *.module.css 后缀自动启用 CSS Modules。注意别忘了配置，否则你写的类名根本不会被哈希化。
我踩过坑：一开始没改文件名，还是叫 style.css，结果打包出来类名原封不动，白忙活一通。改成 style.module.css 瞬间生效，建议新人直接照抄命名规则。
这个场景最好用 Shadow DOM
如果你要做高内聚的独立组件，比如弹窗、富文本编辑器、或者嵌入第三方小工具，Shadow DOM 是真香。
它不只是样式隔离，连 HTML 都给你包得严严实实。外面改 h1 字体？不好意思，我里面完全不受影响。
class ModalComponent extends HTMLElement {
constructor() {
super();
this.attachShadow({ mode: 'open' });
}
connectedCallback() {
this.shadowRoot.innerHTML =
<style>
.modal {
position: fixed;
top: 50%;
left: 50%;
transform: translate(-50%, -50%);
background: white;
padding: 20px;
border-radius: 8px;
box-shadow: 0 4px 12px rgba(0,0,0,0.1);
z-index: 1000;
}
h1 { color: #000; } /* 外面改不了 */
</style>
<div class="modal">
<h1>这是内部的标题</h1>
<slot></slot>
</div>
;
}
}
customElements.define('my-modal', ModalComponent);<my-modal>
<p>这段内容会被塞进 slot 里</p>
</my-modal>这里注意下，mode 设成 'open' 才能通过 el.shadowRoot 访问，方便调试。上线可以考虑 'closed'，但其实意义不大，别人稍微折腾下照样能打进去。
坑点来了：Shadow DOM 里的事件默认会冒泡到外部，所以 click 监听是可以捕获的，但样式绝对出不去。这点很关键，别担心交互断了。
PostCSS 自动加前缀，适合老项目
有些项目你没法上 CSS Modules，比如一堆 legacy CSS 文件，或者团队还没准备好改写方式。这时候我建议用 postcss-prefixwrap，build 时自动给整个文件加前缀。
npm install postcss postcss-cli postcss-prefixwrap --save-dev// postcss.config.js
const prefixWrap = require('postcss-prefixwrap');
module.exports = {
plugins: [
prefixWrap('.my-widget-v2') // 所有样式都包一层
]
};/* 原始 CSS */
.header {
background: blue;
}
.button {
color: white;
}/* 构建后输出 */
.my-widget-v2 .header {
background: blue;
}
.my-widget-v2 .button {
color: white;
}这个方案的好处是：你不用改任何 JS 代码，也不用拆分 CSS 文件。坏处是选择器层级变深了，万一外面也套了个同名类，可能还是有风险。不过比起全局污染，这点代价完全可以接受。
我之前在一个后台系统里用了这招，把子模块全部包进 .subapp-report-center 下，上线后再也没收到样式冲突的 bug 报告，爽。
踩坑提醒：这三点一定注意
- 字体和全局 reset 不要被隔离过头：比如你用 Normalize.css 或现代
reset-css，这些应该放在主应用加载，不要也被包进某个 scope 里。否则子应用可能看起来“没样式”，其实是基础样式没了。 - 动态注入的样式要手动处理：有些 UI 库（比如 Ant Design）会 runtime 动态插入 CSS 到
<head>，这种不会被 CSS Modules 或 PostCSS 处理到。解决方案要么改用静态引入 CSS 文件，要么自己监听并重写规则——但后者太折腾，不如直接上 Shadow DOM。 - 预处理器嵌套别滥用：用 SCSS 的时候，我见过有人这么写：
// 千万别这么写！
.my-component {
.my-component {
.title {
font-weight: bold;
}
}
}结果编译出来成了 .my-component .my-component .title，匹配不到元素。尤其配合前缀工具时更容易出问题。建议扁平一点，一级就够了。
iframe？不是最优解，但有时真得靠它
我知道很多人一听样式隔离第一反应就是 iframe。说实话，iframe 隔离是最彻底的——DOM、CSS、JS 全部独立。
但我只在一种情况下推荐用：你要嵌入完全不受控的第三方页面，比如合作伙伴的营销页、或者客户自己上传的 HTML 包。
<iframe
src="https://jztheme.com/widget/report"
style="width:100%; height:600px; border:none;"
sandbox="allow-scripts allow-same-origin"
></iframe>注意加上 sandbox 属性，不然安全审计直接挂掉。但这也意味着你要显式允许脚本、同源等行为。
缺点也很明显：通信麻烦，SEO 不友好，移动端滚动经常卡顿。所以我的原则是：能不用 iframe 就不用，优先走 JS 框架级隔离。
最后说点大实话
没有银弹。CSS Modules 适合新项目，Shadow DOM 适合独立组件，PostCSS 加前缀救老项目，iframe 是最后的保险丝。
我现在做微前端的标准流程是：
- 子应用能改代码 → 上 CSS Modules
- 子应用是独立 Web Component → Shadow DOM + Custom Elements
- 子应用是遗留系统 → PostCSS 包一层前缀，外加文档约定禁止新增全局样式
- 子应用是外部链接 → iframe + sandbox 控制权限
有一次我图省事直接把一个 jQuery 插件的 CSS 放进了全局，结果它里面的 !important 把整个系统的表单都毁了。折腾了半天发现，还不如一开始就老老实实用前缀包裹。
以上是我踩坑后的总结，希望对你有帮助。这个技巧的拓展用法还有很多，比如结合 Babel 插件做动态作用域、或者用 constructable stylesheets 优化性能，后续会继续分享这类博客。
暂无评论