微前端踩坑实录：Wujie 嵌入后样式错乱，竟是 innerText 惹的祸？

天道kabuto
35 阅读5分钟

微前端踩坑日常：样式怎么又双叒叕乱了？

搞微前端的朋友肯定都有过这种体验：主应用和子应用在本地跑得好好的，一上集成环境，或者换个框架版本，子应用的样式就突然“放飞自我”了。最近我在用 Wujie 微前端框架时，就结结实实地踩了一个坑。

事情是这样的，我们项目升级了某个基础组件库，结果嵌进 Wujie 子应用后，弹窗和对话框的样式全崩了。排查了一圈，发现这锅既不是 Wujie 的，也不全是组件库的，而是两者在某个底层 API 的使用上产生了“奇妙的化学反应”。今天就来跟大家盘一盘这个坑，顺便复习一下浏览器的那些冷门规范。

案发现场：被 <br> 毁掉的 CSS

先来看看出问题的 CSS 代码。原本组件库里有一段很正常的样式（咱们叫它代码 1.1）：

/* 代码 1.1：正常的 CSS */
.orc-dialog-wrap {
  position: fixed;
  top: 0;
  left: 0;
  /* ... 其他样式 ... */
}

但在浏览器里审查元素时，我发现生成的 <style> 标签里的内容简直惨不忍睹。换行符全没了，取而代之的是密密麻麻的 <br> 标签，变成了这样（代码 1.2）：

/* 代码 1.2：被 innerText 改造后的 DOM 结构 */
<br>
.orc-dialog-wrap {
<br>
  position: fixed;
<br>
  /* ... */
<br>
}
<br>

不过在普通的浏览器环境里，<style> 标签内部如果混入了 <br> 这种 HTML 元素节点，浏览器的 CSS 解析器会非常“宽容”地忽略它们，只提取纯文本部分去解析。所以子应用单独跑的时候，样式完全正常。

你以为这就完了？当 Wujie 接管这段代码时，它会对 <style> 标签进行序列化提取。这一提取，直接把 <br> 变成了纯文本字符串（代码 1.3）：

/* 代码 1.3：Wujie 序列化后的最终字符串 */
<br>.orc-dialog-wrap {<br>position: fixed;<br>...<br>}<br>

看到这儿，懂行的兄弟估计已经笑出声了。CSS 解析器看到 <br> 这种玩意儿，直接就罢工了，样式能不崩吗？

揪出幕后黑手：innerText 的“自作聪明”

为什么好好的 CSS 会变成代码 1.2 那样？罪魁祸首是组件库在动态注入样式时，使用了 element.innerText = cssString。

很多开发者觉得 innerText、textContent 和 innerHTML 差不多，都是往 DOM 里塞文本，但浏览器对它们的处理逻辑可谓天差地别。这里必须搬出 WHATWG HTML 规范 来给大家普个法。

根据 WHATWG HTML 规范，当你给一个元素设置 innerText 时，浏览器会执行以下算法：

  1. 按 \n 分割字符串成多行。
  2. 逐行处理：每行创建一个文本节点（Text Node）。
  3. 在行与行之间插入 <br> 元素。

发现问题了吗？innerText 的设计初衷是为了人类可读的纯文本渲染，它会刻意保留视觉上的换行。所以，当你把一段带有 \n 的 CSS 字符串赋给 innerText 时，浏览器非常“贴心”地帮你把换行符替换成了 <br> 标签。

对于普通的 div 来说，这没啥问题；但对于 <style> 或 <script> 这种需要解析原始文本的标签来说，这简直就是灾难。

Wujie 的“神补刀”：innerHTML 序列化

如果仅仅是组件库用错了 API，其实在某些浏览器下，<style> 标签里的 <br> 可能会被容错处理，或者干脆不渲染。但 Wujie 微前端框架在沙箱隔离和样式处理时，补上了致命一刀。

Wujie 在收集子应用样式时，会读取 <style> 标签的内容。它是怎么读的呢？用的是 innerHTML。

当浏览器执行 styleElement.innerHTML 时，它会将 DOM 树序列化回 HTML 字符串。此时，之前由 innerText 生成的 <br> 节点，就被原封不动地序列化成了字符串 "<br>"。

于是，CSS 字符串里就混入了这些非法的 HTML 标签字符。当 Wujie 把这些样式重新注入到主应用或者 iframe 沙箱中时，浏览器的 CSS 解析器遇到 <br> 直接报错忽略，导致后面的样式全部失效。

避坑指南：如何优雅地注入样式？

搞清楚了原理，解决起来就很简单了。核心原则就一条：操作 <style> 和 <script> 标签时，永远不要用 innerText。

1. 组件库/业务代码层面的修复

如果你能修改注入样式的源码，请把 innerText 替换为 textContent。textContent 会原封不动地设置文本节点，不会做任何换行符的视觉转换。

// ❌ 错误示范
styleElement.innerText = cssString;

// ✅ 正确姿势
styleElement.textContent = cssString;

或者，如果你想更稳妥一点，可以直接操作文本节点：

// ✅ 更底层的正确姿势
styleElement.appendChild(document.createTextNode(cssString));

2. 框架层面的兼容（给 Wujie 提个醒）

虽然根源在业务代码，但作为微前端框架，Wujie 其实也可以做一层防御性编程。在序列化 <style> 标签内容时，如果发现里面混入了奇怪的 HTML 标签（比如 <br>），可以尝试过滤或者降级使用 textContent 来读取。当然，这属于锦上添花，最根本的还是得靠咱们写业务代码时规范 API 的使用。

总结一下

这次踩坑给我最大的启发是：不要想当然地认为 DOM API 的行为是符合直觉的。 innerText、textContent、innerHTML 这三剑客，虽然长得像，但底层逻辑完全不同。

  • innerHTML：解析 HTML 标签，有 XSS 风险，性能开销大。
  • textContent：纯文本设置，不解析 HTML，性能最好。
  • innerText：感知 CSS 样式（比如 display: none 的内容读不到），会处理换行和 <br>，性能最差。

下次再遇到动态注入样式或脚本导致的问题，先去看看是不是 innerText 在捣鬼。

avatar
文章
阅读
粉丝