TinyMCE粘贴CAD图纸实现SVG矢量图：从转换到集成全攻略

上个月帮一家封装测试厂的文档系统做了个小改造，解决问题一句话就能说清：工程师在TinyMCE里粘贴CAD图纸时，出来的不再是一张放大就糊的马赛克位图，而是随时可缩放、可选中、可检索的SVG矢量图。这个需求在芯片制造企业里不是个例，几乎每条产线的工艺文档、质量报告、设备SOP里都要贴图纸，而“粘贴出来的图能不能看清引脚编号、能不能被文档搜索引擎索引到”，直接影响产线工程师的日常效率。

这篇文章我会把整套方案从头到尾拆开讲，包括图纸格式怎么选型、转换链路怎么搭、TinyMCE怎么拦截粘贴事件、SVG怎么嵌进编辑器，以及我在落地过程中踩过的坑。适合在半导体、电子制造企业做文档系统、知识库、质量管理系统的人参考，也适合任何正在跟“富文本编辑器+工程图纸”死磕的前端和后端工程师。

1. 场景还原：为什么芯片企业会对“编辑器贴CAD图”这么较真

1.1 典型业务场景：工艺文档、质量报告、设计评审里贴图纸

很多人以为芯片企业里只有Fab的机台和光刻机，其实支撑制造的还有大量文档系统。工艺集成工程师要写工艺规范，封装设计工程师要写设计规则，质量工程师要写8D报告，设备工程师要写维护SOP，这些文档全都跑在Web系统里，内容编辑很大一部分用的就是TinyMCE。

这些文档里要贴的图纸，不是普通的JPG示意图，而是正儿八经的CAD图纸——封装框架的尺寸图、引线框架引脚排列图、测试夹具的装配图、设备安装底座的开孔图。拿封装框架图纸来说，引脚间距可能只有0.5毫米甚至更小，工程师写失效分析报告时要标注“第23脚对第24脚短路”，如果粘贴进去的图放大后糊成一团，这份报告基本就废了，对方看完还得去CAD系统里再翻一遍原图。

这些图纸通常由设计部门用AutoCAD、中望CAD或类似工具画好，导出成DWG或DXF文件，然后流转到文档系统里。文档系统的富文本编辑器需要把这些图纸插入到报告正文中，并保持足够高的可读性和准确性。

1.2 直接粘贴的三大痛点：位图失真、无法检索、存档体积失控

最原始的方案是什么？工程师在CAD软件里截个图，Ctrl+C然后Ctrl+V贴到TinyMCE里。这个方案看起来能用，但实际使用有三大痛点。

第一个痛点是位图失真。截图本质是像素图，分辨率取决于屏幕的DPI和缩放比例。普通截图缩放到150%还能看，放大到300%就开始出现锯齿，放大到500%以上连引脚编号都认不出来。而芯片行业的图纸恰恰需要“放大看细节”，这就让截图方案直接出局。

第二个痛点是文字彻底消失。CAD图纸里有大量尺寸标注、料号、备注信息，这些文字一旦变成像素，就失去了文本属性。结果是：文档系统里的全文搜索搜不到标注内容，下游系统也无法从文档中抽取参数，连工程师自己想双击选中一段文字复制都不行。一个承载着大量工艺参数的图纸，变成了一座信息孤岛。

第三个痛点是存档膨胀。高DPI截图一张图纸动辄10-20MB，一个报告插五六张图纸，数据库很快就被撑爆。我见过一个企业的文档库，两年下来占用了几百GB空间，其中大量空间被这些图片填满，备份和迁移都极其痛苦。

还有第四个隐性痛点，位图没法做版本对比。工艺变更时，新版本图纸和旧版本图纸之间往往只差几个引脚的标注位置，如果都是图片，除了肉眼看基本没法自动diff。

1.3 矢量输出到底解决了什么问题，先想清楚再动手

“矢量输出”这四个字，落到TinyMCE里通常指的就是SVG。SVG是浏览器原生支持的矢量格式，缩放不失真、文字可检索、体积相对较小、可以用CSS控制样式，这些特性天然适合工程图纸。

但这里有个重要区分：我们要做的不只是“把图纸变成SVG文件”，而是“把SVG塞进TinyMCE的文档流里，让它在编辑时可见、保存后留驻、导出时可用”。这个链条比单纯的格式转换长得多，涉及编辑器配置、剪贴板拦截、后端转换接口、前端渲染策略、数据库存储方案等环节。后面我把每一环都展开讲，先把概念理清。

另外想多说一句，对于芯片企业这类有内网隔离要求的环境，在线云转换服务（比如把图纸传到第三方服务器）基本是行不通的，必须在企业内部自建转换链路。这也是我后面选择Python+ezdxf自建服务的原因。

2. 技术选型：从CAD文件到SVG的转换链路怎么搭

2.1 图纸格式先理清：DWG、DXF、SVG之间是什么关系

动手之前，先把格式关系理顺。

DWG是AutoCAD的私有二进制格式，市面上几乎所有工程图纸的原始文件都是它。但DWG的解析难度较高，开源方案大多只能读取部分版本，而且直接操作DWG生态不友好。

DXF是Autodesk发布的公开交换格式，本质上是文本（或二进制）描述几何实体、图层、块、标注等信息。DXF最大的优势是开放且文档完善，生态里能读能写的库非常多，几乎所有CAD软件都支持导出DXF。

SVG是W3C标准的Web矢量格式，浏览器原生支持，不需要任何插件就能渲染。它用XML描述路径、矩形、圆形、文字等元素，也可以嵌入经base64编码的位图。

它们之间的关系可以类比成：DWG是某个CAD软件的私有源文件，DXF是行业通用的交换格式（像CSV之于Excel），SVG是网页能直接吃的标准格式。

所以转换链路通常长这样：DWG → DXF → SVG。如果你的图纸来源本来就是DXF（很多芯片设备厂商交付的图纸就是DXF），那第一步可以直接跳过，少一层转换就少一个坑。

2.2 转换工具链对比：LibreDWG、ODA、ezdxf、dxf2svg怎么选

我梳理一下市面上主流的转换工具，按我的经验给个对比和选择建议。

• LibreDWG：GNU的开源库，主要能力是把DWG转成DXF，不直接输出SVG。它的GPL协议是个隐患，如果你的企业系统需要闭源部署，直接调用LibreDWG的代码可能引入协议风险，建议通过独立进程或命令行调用来隔离。
• ODA File Converter：Open Design Alliance提供的一款免费转换工具，能把DWG/DXF互转，转换质量很高，对AutoCAD各版本的兼容性做得很好。缺点是它是GUI工具，虽然支持命令行参数调用，但需要在Windows服务器上部署，进程管理和异常处理都得自己写。
• ezdxf：Python生态里最成熟的DXF处理库，读取DXF、写DXF、渲染SVG都支持，文档完善，API稳定，是我个人最推荐的核心转换组件。它不直接读DWG，但配合上面的方案把DWG先转成DXF就能无缝衔接。
• dxf2svg：Node.js生态的DXF转SVG库，轻量，对简单图形处理还行，但遇到工程图里的块、属性、标注样式、HATCH填充时容易出各种毛病，只适合做原型验证，不建议直接上生产。
• Autodesk Forge / Model Derivative：Autodesk官方云服务，转换质量很高，也提供了REST接口。但对于内网隔离的芯片企业来说，把图纸传到公有云这一步就过不了合规审查，仅适合完全没有内网限制的互联网产品。

芯片企业内部最常见的组合是：ODA或LibreDWG做DWG到DXF的预转换，ezdxf负责DXF到SVG的渲染输出，整个链路封装成独立的后端服务。下面这一节我详细说说转换时要处理好的细节。

2.3 芯片图纸转换的特殊考量：单位、图层、块属性、精度

芯片行业的CAD图纸和普通机械图纸相比，有几个很容易被忽略的特殊点，处理不好转换出来的SVG要么没法看，要么精度不对。

第一个是单位问题。DXF本身不强制单位，全靠CAD软件里的设置。机械图纸一般用毫米，芯片封装图纸也常用毫米，但到了晶圆级（Wafer）的版图，可能直接就是微米级甚至纳米级尺寸。转换前必须明确源图纸的单位，并在转换时统一换算。如果单位没对齐，一张本该是10mm宽的封装图纸转换后被浏览器渲染成10像素，看起来可能只是缩放问题，但放到产线系统里做尺寸测量或者后续接入MES时就会出大乱子。

第二个是图层问题。芯片图纸的图层命名往往有行业规范，比如金属层叫METAL1、METAL2，多晶硅层叫POLY，接触孔叫CONTACT，这些图层在源图纸里用不同的颜色和线型区分。转换时如果不做任何处理，所有图层汇到同一张SVG里，颜色乱成一团，金属层和介质层分不清，这图基本没法用。所以转换接口必须支持图层过滤和颜色映射，最好保留图层名作为SVG的class或data属性，这样前端还能根据图层做显隐控制。

第三个是块与属性。CAD图纸里的图框、标题栏、管脚符号通常做成了块（Block），块里带着图形和文字属性（料号、版本、设计者、日期）。转换时如果只是简单地把块炸开（Explode），块内的属性文字就会丢失，输出的SVG里只剩一圈轮廓线。务必确认转换工具链能解析并保留块属性，ezdxf在这方面做得不错，但要正确配置。

第四个是精度控制。DXF里的坐标是浮点数，直接原样写入SVG路径会生成很长一串小数，文件体积增大，浏览器解析也慢。建议转换时对坐标做归一化处理，把图形整体平移到原点附近、缩放到合适的尺寸范围，同时对小数位做截断，比如保留2位或3位小数。对于大量高频曲线（比如弧线、样条曲线），要做适当的降采样，否则一个几十万实体的版图文件，转出来的SVG能到几十MB，浏览器直接被拖死。

3. TinyMCE集成实操：拦截粘贴事件，把矢量图塞进编辑器

3.1 TinyMCE初始化配置：不配置白名单，SVG会被编辑器“吞”掉

TinyMCE默认的HTML过滤规则非常严格，它会把所有不在配置白名单里的标签直接丢弃。SVG算得上是“重灾区”，因为<svg>、<path>、<line>、<text>这些标签在TinyMCE默认schema里根本不存在，如果你不做任何配置就直接插入SVG，大概率结果就是标签被剥掉、图形消失，只剩一段空白。

初始化配置里需要给三个关键点做好设置。

第一是扩展valid_elements，把SVG相关标签全部加进白名单。我的配置是这样：

javascript复制tinymce.init({
  selector: '#content',
  plugins: 'paste advlist table lists link image code',
  toolbar: 'undo redo | blocks | bold italic | bullist numlist | table | link | code',
  extended_valid_elements: 'svg[*],g[*],path[*],defs[*],line[*],circle[*],ellipse[*],polyline[*],polygon[*],rect[*],text[*],tspan[*],use[*],desc[*],title[*],marker[*],linearGradient[*],stop[*]',
  valid_children: '+body[svg],+div[svg],+p[svg]',
  paste_data_images: true,
  content_style: 'svg { max-width: 100%; height: auto; border: 1px solid #ddd; } .cad-svg { margin: 10px 0; }'
});

第二是valid_children。SVG是内联元素，实际插入时会放在<p>或者<div>里，需要明确允许这些容器包含<svg>子节点，否则会被TinyMCE的schema校验拦下来。

第三是paste_data_images。这个配置要置为true，否则粘贴的图片（包括后续我们要用到的data URI图片）会被编辑器直接丢弃。

还有一个容易忽视的点：如果走的是editor.execCommand('mceInsertContent', false, svgHtml)这种方式插入内容，TinyMCE同样会走schema过滤，所以上面这些配置对“编程式插入”一样生效，不是只针对用户手工粘贴。

3.2 前端剪贴板拦截：监听paste事件，识别DXF/DWG文件

配置好白名单后，接下来要解决“怎么识别用户粘贴的是一个CAD文件而不是普通图片”。TinyMCE的paste事件里可以拿到剪贴板的数据，我们通过clipboardData.items可以读取到文件对象，然后根据文件扩展名做分流。

下面是我在生产环境里用的监听逻辑：

javascript复制editor.on('paste', function(e) {
  const items = e.clipboardData && e.clipboardData.items;
  if (!items) return;
  for (let i = 0; i < items.length; i++) {
    const item = items[i];
    if (item.kind !== 'file') continue;
    const file = item.getAsFile();
    if (file && /\.(dxf|dwg)$/i.test(file.name)) {
      e.preventDefault();
      uploadAndInsert(file, editor);
      return;
    }
  }
});

拿到CAD文件之后，不建议直接在浏览器里做转换，因为DWG文件动辄几十MB，前端解析非常吃力，而且算法库在浏览器端基本跑不动。正确做法是把文件丢给后端转换服务，拿到SVG后再插回编辑器。

上传和插入的完整流程大概是：

javascript复制async function uploadAndInsert(file, editor) {
  const formData = new FormData();
  formData.append('file', file);
  // 可追加图层过滤、配色方案等参数
  const resp = await fetch('/api/convert/cad2svg', {
    method: 'POST',
    body: formData
  });
  const result = await resp.json();
  if (result.svg) {
    const wrapper = document.createElement('div');
    wrapper.className = 'cad-svg';
    wrapper.dataset.sourceFile = file.name;
    wrapper.dataset.layerCount = result.layerCount || '';
    wrapper.innerHTML = result.svg;
    editor.execCommand('mceInsertContent', false, wrapper.outerHTML);
  } else {
    editor.notificationManager.open({
      type: 'error',
      text: '图纸转换失败，请检查文件格式后重试'
    });
  }
}

这里有一个细节：前端拿到SVG字符串后，建议包一层带class的div再插入，一是方便样式控制，二是后续可以在div上挂data-*属性记录源文件名、图层数量等元信息，方便保存后做二次检索和展示。

3.3 转换接口对接与SVG插入策略：内联、引用、缩略图怎么选

后端转换接口是整个方案的核心。我推荐用Python写的FastAPI服务，核心依赖就是ezdxf。一个可用的转换接口长这样：

python复制import io
from fastapi import FastAPI, UploadFile
import ezdxf
from ezdxf.addons.drawing import RenderContext, Frontend
from ezdxf.addons.drawing.svg import SVGBackend

app = FastAPI()

@app.post("/api/convert/cad2svg")
async def convert_cad_to_svg(file: UploadFile):
    content = await file.read()
    # 注意：DWG文件需要先用ODA/LibreDWG转换成DXF，此处假定接收的是DXF
    doc = ezdxf.readfile(io.BytesIO(content))
    msp = doc.modelspace()
    backend = SVGBackend()
    ctx = RenderContext(doc)
    Frontend(ctx, backend).draw_layout(msp)
    svg_content = backend.get_string()
    return {"svg": svg_content, "layerCount": len(doc.layers)}

如果前端传的是DWG，接口里要先做一步DWG到DXF的转换。我在生产环境是封装了一个内部工具类，调用ODA的命令行工具做转换，然后用ezdxf读转换结果。这一步务必加超时和异常捕获，因为ODA对某些损坏DWG文件会直接卡住。

SVG插入TinyMCE有几种策略，根据图纸大小和业务复杂度选。

第一种是内联SVG。直接把SVG字符串作为HTML的一部分插入到正文里，保存后连同正文一起存入数据库。优点是编辑时所见即所得，保存后图纸和文档强绑定，导出PDF时不需要额外加载。缺点是SVG过大的时候会让正文HTML变得非常臃肿，数据库字段也可能被撑爆。我建议单张图纸SVG超过2MB就不要再内联了。

第二种是SVG文件引用。转换出的SVG以独立文件形式存储，正文里用<object>标签或者图片占位加载。优点是正文保存的数据量小，SVG文件可以走CDN。缺点是不做额外处理的话，离线导出PDF时可能拉不到SVG。适合图纸数量大、单张图纸特别大的场景。

第三种是内联+缩略图方案。正文里插入一个低精度缩略图（PNG），点击缩略图才加载完整的SVG。好处是编辑、列表、全文检索时性能都很好，代价是实现复杂度更高。这种方案适合以后要做图纸在线预览交互的企业。

我自己的落地经验是：10MB以下的DXF图纸，直接内联SVG，省事、体验好。超过10MB的，按“文件引用+懒加载”处理。再大的（比如上百MB的晶圆级版图），那已经不是TinyMCE编辑器该承载的东西了，建议做成独立在线预览系统，文档里只留个跳转链接，否则浏览器渲染几十MB的SVG会卡到无法操作。

3.4 图层颜色映射与样式注入：让芯片图纸在编辑器里可读

芯片图纸转换后直接在浏览器里显示，和CAD软件里显示的效果往往不一样，原因在于CAD软件默认是黑色背景，图纸里图层用的颜色是专门为黑底设计的（白色、黄色、青色、绿色等）。到了白底网页上，白色线条直接隐形，黄色也变得很浅。

所以转换接口里必须有一张“图层颜色映射表”，把CAD黑底配色映射到白底Web配色。我的做法是：

python复制COLOR_MAP = {
    "METAL1":   "#C0392B",
    "METAL2":   "#2980B9",
    "POLY":     "#16A085",
    "CONTACT":  "#8E44AD",
    "PAD":      "#D4AC0D",
    "OUTLINE":  "#2C3E50",
    "TEXT":     "#34495E",
    "DIMENSION": "#7F8C8D",
    # 其他图层走默认
}

实际做的时候，不一定是靠图层名精确匹配，因为不同企业的命名规范不一样。更好的做法是在转换服务里维护一张“名称模式→颜色”的映射表，支持通配符和正则，比如所有以METAL开头的图层都映射到红色系。

另外，给内联SVG加一点CSS样式也很有用。我碰到过的典型问题是：SVG里字体没有指定，浏览器默认使用宋体，标注文字不仅丑，而且某些特殊字符显示为方块。解决办法是在TinyMCE的content_style里加上对SVG text元素的字体控制，或者在SVG生成时给<svg>元素设置内联的font-family和font-size。

css复制svg text {
  font-family: "Noto Sans SC", "Microsoft YaHei", "PingFang SC", sans-serif;
  font-size: 14px;
}

4. 落地部署中的常见问题与排查实录

4.1 粘贴后SVG被编辑器吞掉了，常见原因与排查步骤

这是踩过最多人坑的地方。现象是：后端转换一切正常，SVG字符串也拿到了，mceInsertContent执行后编辑器却干干净净，或者只剩一个空div。

排查顺序建议是这样：

第一步，打开浏览器控制台，看插入的时候有没有报错。如果直接报invalid HTML或者被TinyMCE的schema拒绝，那基本就是extended_valid_elements配置没生效，重点检查TinyMCE的plugins里是否加载了paste插件，以及是否有全局配置覆盖了你的白名单。

第二步，检查valid_children配置是否存在。TinyMCE严格模式下，<svg>放进<p>里是会被拒绝的，即使你把<svg>加入了valid_elements也没用。必须明确声明+body[svg]或+div[svg]这样的父子关系。

第三步，看TinyMCE是不是开启了forced_root_block的默认行为，导致SVG被包在奇怪的标签里。我遇到过<svg>被包进<a>标签导致渲染异常的案例，根源就是schema校验自动给裸内容套父标签。

第四步，如果用的是老版本TinyMCE 5，要注意paste事件里onPaste和paste_preprocess配置的区别。有些情况下SVG在过PastePreProcess时还没问题，但在后续的PastePostProcess阶段被内部的DOM清理逻辑干掉了，这种情况需要单独调整paste插件的过滤规则。

4.2 大图纸转换超时、页面卡死，性能问题怎么优化

这一节必须单独拿出来说，因为芯片图纸的大小不是开玩笑的。一个封装图纸可能只有几百KB，但一块带完整金属层、焊盘、走线的PCB或引线框架图纸，DXF轻松上几百MB，实体数量几十万甚至上百万。

遇到这种图，核心思路是“别想着一次转完全图”。我建议分三层做优化。

第一层，前端限制。上传前先检查文件大小，超过阈值的文件直接提示“需要先切图或使用区块转换”。同时让用户选择要转换的图层，很多时候报告的正文里只需要金属层和标注层，结构层和隐藏层完全可以过滤掉。

第二层，后端转出策略。对于超大DXF，不要直接全量渲染成SVG，而是做两步：先分析DXF文件的边界范围，然后只转换用户在预览框（或者参数里指定的）矩形区域内的实体。ezdxf的modelspace().bbox()方法可以快速拿到模型空间的范围，再通过实体查询接口按包围盒过滤。这样做之后，即使原始图纸是1GB，最终转换的区域SVG也能控制在合理范围内。

第三层，异步任务化。转换耗时超过5秒的，前端就不能一直等同步接口了。应该改成异步任务模式：前端上传文件后立刻返回一个任务ID，浏览器通过WebSocket或轮询查询任务状态，转换完成后通知前端插入SVG。这样不仅接口不超时，用户也不会一直盯着转圈。

还有个经验是：转换服务一定要设置CPU和内存上限。因为ezdxf一次性把整个DXF读进内存解析，遇到超大文件，内存瞬间能吃掉几个GB。我在生产环境用的是每个转换任务独立进程，任务结束后立刻释放，避免内存泄漏拖垮整个服务。

4.3 字体丢失、坐标偏移、图层颜色错乱，转换结果不对怎么办

字体丢失是最常见的“结果不对”问题。DXF里的文字标注分两种：一种是真正的TEXT/MTEXT实体，文字内容是可读的；另一种是SHX字体在CAD里渲染后已经被“炸开”成几何线段，文字内容早就丢了。

对于第一种，转换时把文字渲染成SVG的<text>标签，保留文字内容。但字体映射经常出问题，DXF里的字体名和服务器上装的字体名不一致，渲染出来就是方块或者错误字体。稳妥做法是转换时就把文字转换成路径（矢量轮廓），这样SVG在任何机器上都显示一致，代价是文件体积变大、文字不可搜索。如果对“文字可搜索”有刚需，就用<text>标签，但一定要在content_style里设置好fallback字体列表。

坐标偏移这块，我遇到过最隐蔽的问题是：DWG里用了图纸空间和视口（Model Space和Paper Space），直接转换模型空间得到的SVG和CAD里打印出来的效果完全不一样。解决办法是明确以打印布局或模型空间作为转换基准，并且在转换前调用ezdxf的doc.audit()修复图面问题，消除孤立实体和异常块。

图层颜色错乱则多半是颜色映射表的问题。工程图纸里的颜色索引（ACI）和RGB颜色不是一回事，CAD的1号色是红色、2号色是黄色、7号色是白色/黑色，不同版本CAD对7号色在不同背景下的处理还不一样。转换时如果不处理ACI颜色而是直接取RGB值，白底网页上就会看到一堆浅色线条。我处理的方法是先解析ACI颜色索引，再用统一的灰度和色相映射规则转换到Web配色，最后再叠加图层名级别的特例覆盖。

4.4 浏览器兼容性：不同浏览器的剪贴板行为差异

最后说一个很容易在验收阶段被测试打回来的问题——不同浏览器的剪贴板行为不一致。

Chrome和Edge对剪贴板文件的读取支持最好，clipboardData.items里能正确拿到File对象，而且文件名、扩展名都齐全。Firefox的基础特性也支持，但在通过“复制文件”直接粘贴的场景下偶尔会拿不到文件名。Safari则是重灾区，它的Safari 14之前的版本根本不支持从剪贴板读取File对象，用户从Finder复制一个DXF文件再粘贴，页面上什么都收不到。

针对Safari，我的建议是：不要指望它能从剪贴板读文件，保留一个“上传CAD文件”的入口按钮作为兜底。用户在Safari里点击上传按钮选择文件，走的就是和粘贴一样的转换插入流程，体验差别不大。

还有一个细节：用户从CAD软件里复制的往往是复制图形内容，而不是复制文件。这种情况下剪贴板数据可能是位图（这是CAD软件决定的），它不会触发我们前面写的文件识别逻辑，就会被TinyMCE当成普通图片粘贴。如果不想让用户看到“位图粘贴成功但模糊”的无效反馈，可以在paste拦截逻辑里额外判断：如果剪贴板里是图片，并且图片尺寸异常大（比如超过2000像素），就把编辑器默认粘贴行为拦截住，提示用户使用文件上传方式导入CAD图纸。

我做了一个排查速查表，在实际排查问题时可以对照着看：

写在最后：从“能贴图”到“好用”的几步建议

这套方案从最初“把CAD粘贴成图片”的简单替换，到后来上线SVG矢量输出，中间迭代了好几轮。如果你们企业也在做同样的事，我建议先别急着把所有图纸类型都支持，按优先级来：

第一优先做DXF直转SVG，覆盖芯片封装设计、测试夹具、设备安装这80%的常见图纸场景。第二优先接通DWG转换链路，用ODA做预转换。第三优先做图层过滤和颜色映射的配置化，让不同事业部可以自己调配色。这样每一轮迭代都有可交付的价值，不会一上来就背一个“什么图纸都能转”的大包袱。

另一个经验是：转换服务尽量独立出来，不要和文档系统的Web应用耦合在同一进程里。独立服务的好处是方便扩容、独立发布、独立维护，将来换富文本编辑器或者对接别的系统的时候，这个转换能力可以直接复用。

最后分享一个小技巧：给SVG保存时追加一个自定义元素储存元数据，比如<desc>标签里写入源文件名、图纸版本、转换时间。这样文档归档到知识库之后，仍然能追溯到底用的是哪个版本的图纸，质量和合规审核时会省很多事。