在日常技术写作或学术排版中，我们常面临一个尴尬的断层：上游内容用 Mermaid、LaTeX 等标记语言高效编写，下游交付却要求规范的 .docx 格式。手动截图、粘贴、调整不仅耗时，还容易出错。最近出现的在线工具 aitoword.chat 尝试打通这一断层。本文从技术实现角度，拆解其核心模块与可能的技术选型。

一、整体工作流

用户在前端文本框内输入多段 Mermaid 代码和/或 LaTeX 公式，实时预览渲染结果，确认无误后导出单个 .docx 文件。后端（或前端部分能力）承担解析、渲染、文档生成三大任务。典型流程如下：

1. 前端收集用户输入的标记代码；

2. 调用渲染引擎生成图片（Mermaid）或中间格式（LaTeX → MathML）；

3. 将图片和公式嵌入文档构建器；

4. 输出 .docx 文件供下载。

二、Mermaid 代码转图片：无头渲染与批处理

Mermaid 本身基于 JavaScript，依赖 DOM 和 SVG 渲染。在浏览器端，可以直接引入 Mermaid.js 并借助 <svg> 或 Canvas 渲染，再通过 toDataURL 导出为 PNG。但在后端（Node.js）环境下，需要无头浏览器（如 Puppeteer、Playwright）模拟浏览器环境完成渲染。

批量处理的关键点：

• 对每段 Mermaid 代码独立渲染，避免样式冲突；

• 控制渲染并发数，防止内存溢出；

• 输出图片格式通常选择 PNG（有损但兼容性好）或 SVG（矢量但部分 Word 版本渲染异常）；

• 图片尺寸可通过 CSS 预设或根据图表内容自适应。

若工具完全在前端完成（不经过后端服务器），则用户浏览器本地执行渲染和文档生成，隐私性好，但受限于客户端性能。工具采用何种模式尚不可知，但考虑到文档生成库（如 docx）在前端也可运行，完全前端实现是可行的。

三、LaTeX 公式无损迁移：从 TeX 到 MathML 再到 Word

Word 原生支持的公式格式是 Office MathML（OMML）或 UnicodeMath。LaTeX 公式要无损迁移，通常有两条技术路径：

1. LaTeX → MathML（标准） → OMML：使用 MathJax 或 LaTeX2MathML 将 LaTeX 转为标准 MathML，再通过 XSLT 转换或库（如 mml2omml）转为 Office 可识别的 OMML。这条路保真度最高，支持大部分基础符号和结构。

2. LaTeX → 图片：将公式渲染为高清 PNG 或 SVG 再插入 Word。虽然简单，但缩放会失真，且不便于后续编辑。技术解析风格的工具显然应优先采用第一种路径。

实际挑战在于 LaTeX 宏包的多样性。工具只能覆盖常用宏包（amsmath、amsfonts 等），对于 tikz 绘制的复杂公式或自定义宏，很可能转换失败，需降级为图片方案。

四、Word 文档生成：docx 库的典型用法

无论是前端还是后端生成 .docx 文件，目前最成熟的库是 docx.js（JavaScript/TypeScript）。其基本模式是：

const { Document, Packer, Paragraph, ImageRun } = require('docx');

const doc = new Document({
  sections: [{
    children: [
      new Paragraph({ children: [new ImageRun({ data: imageBuffer, ... })] }),
      new Paragraph({ children: [new MathRun(ommlXml)] })
    ]
  }]
});
const buffer = await Packer.toBuffer(doc);

对于 Mermaid 生成的图片，需将其转为 Buffer 或 base64 嵌入 ImageRun。对于 LaTeX 转换后的 OMML，则需构造 MathRun 对象。需要注意的是，docx.js 对 OMML 的支持需要手动构造 XML 树，复杂度较高。一些工具会直接操作 officegen 或更低层的 JSZip + 模板替换，但维护成本更大。

五、实时预览的交互设计

实时预览是提升用户体验的关键。前端监听文本框输入，节流触发渲染：

• Mermaid 预览：动态创建 <div>，调用 mermaid.render()，将生成的 SVG 插入 DOM。若用户调整了代码，旧图表被替换。

• LaTeX 预览：可使用 MathJax.typesetPromise() 或 Katex.renderToString() 将公式转为 HTML/CSS 展示。注意 MathJax 3 支持 output: 'svg' 或 'html'。

预览和最终导出必须保持一致。如果导出时重新在后端渲染，前后端渲染引擎版本不同可能导致差异。因此稳妥的做法是：预览即使用最终导出的渲染逻辑（例如前端直接生成最终要嵌入 Word 的图片或 OMML 并缓存），导出时复用缓存。

六、技术局限与改进方向

• Mermaid 复杂图表：极大或包含自定义样式、交互的图表，在静态图片中可能丢失信息（如 tooltip、点击事件）。Word 本身不支持交互式 Mermaid，这是工具无法逾越的限制。

• LaTeX 宏包覆盖率：学术论文中可能使用 physics、braket 等高级宏包，转换工具通常不支持。一个可行的增强方案是允许用户上传自定义宏定义文件。

• 批量文档结构：当前工具仅将多个图表顺序排列，不支持目录、页眉页脚、样式模板等。未来可增加模板上传功能，让用户将渲染结果插入指定占位符。

七、总结

aitoword.chat 这类工具本质上是将 Mermaid.js 渲染引擎、LaTeX-to-OMML 转换管道、以及 docx 文档构建器三者串联成一个自动化工作流。它的价值在于屏蔽了底层技术细节，让用户从“截图-粘贴-调整”的重复劳动中解放出来。当然，对于极度复杂的图表或非常规 LaTeX 语法，任何自动化方案都有边界。但对大多数日常技术文档和标准数学公式，这类工具已经能提供足够可靠、高效的转换体验。