企业官网建设流程全解析

在芯片制造企业里，工艺工程师把一份设备布局图从CAD里拖到文档中，结果第二天QA审核时发现，图纸放大后线条全是锯齿，标注数字糊成一片，而且文件从几百KB膨胀到几十MB。这个问题比你想象中更常见，尤其当你的文档系统基于TinyMCE搭建时。我过去一年在好几家半导体企业的文档管理项目里都撞见过同样的问题：CAD图纸粘贴到TinyMCE后，要么变成一张无法缩放的位图，要么干脆被编辑器过滤得干干净净。今天这篇就专门聊一聊，芯片制造企业到底如何解决CAD图纸粘贴到TinyMCE的矢量输出问题。

先说结论：要让CAD图纸在TinyMCE里以真正的矢量形式呈现，绕不开SVG（可缩放矢量图形）这条技术路线。但SVG怎么来、怎么进编辑器、怎么保证安全和性能，这里面的坑远比想象中多。这篇文章会从问题拆解、方案选型、Python批量转换脚本、TinyMCE侧配置与安全处理、常见故障排查五个角度，把我实测过的时间和方案完整讲一遍，适合CAD管理员、工艺工程师、企业IT和基于TinyMCE做二次开发的前后端工程师参考。

1. 问题解构：CAD图纸和TinyMCE之间差了哪一步？

1.1 芯片制造企业里的CAD图纸，都粘贴到哪里去了

芯片制造企业虽然听起来是"Fab""流片""工艺"这些高大上的词，但落到日常办公，大量工作还是离不开传统的机械、厂务、设备文档。以我接触过的实际场景为例，CAD图纸在这些地方出现频率最高：

• 设备导入部门要把光刻机、刻蚀机、薄膜沉积设备的布局图贴进设备验收报告；
• 厂务部门要把洁净室的风管、水电气路图贴进维护SOP；
• 工艺整合工程师要把在线量测的靶点位置图贴进工程变更通知单（ECN）；
• 质量部门要把治具、夹具的尺寸图贴进检验指导书。

这些文档很多都跑在基于Web的文档管理系统上，编辑器用的就是TinyMCE。于是工程师们最顺手的操作就是：在CAD软件里框选图纸，Ctrl+C，到TinyMCE里Ctrl+V。一开始看着没问题，等文档归档、打印、审批时，问题一个接一个冒出来。

这种"能用但不完美"的状态，其实是最危险的。因为大家默认了这套流程是通的，直到某天有人把图纸放大到局部，发现所有圆弧全部变成多边形，或者打印出来标签糊成一团，这时候才知道要回来改，而文档里可能已经积压了上千份历史版本。

1.2 为什么截图粘贴不是长久之计

先说说"截图粘贴"这条路为什么在芯片制造场景里走不通。

CAD图纸不是普通图片，它包含图层、块、线型、标注样式、颜色索引等结构化信息。当你截图粘贴时，这些信息全部丢失，变成一张位图。位图带来的问题在工程场景里几乎是致命的：

• 缩放失真：把图纸放大到某个局部看细节时，线条变锯齿，圆弧变成多边形，这在设备安装精度要求以微米计的环境里完全不可接受；
• 标注模糊：8号、10号字体一旦被栅格化，打印出来就是一团糊；
• 图层无法交互：想隐藏辅助线、只看设备轮廓？做不到；
• 文件体积失控：一张A0幅面的高分辨率截图，动辄几十MB，塞进TinyMCE后数据库压力直接翻倍；
• 后续修改困难：图纸一旦更新，必须重新截图重新粘贴，历史版本无法追溯。

我见过某企业的一份设备验收报告，里面嵌了18张截图，整个文档达到100多MB，打开要转圈十几秒，审批系统直接卡死。最后IT部门不得不专门写了个脚本，把所有图片压到150DPI以下才能继续走流程。这种"压DPI救急"的办法，恰恰牺牲了工程图纸最重要的细节精度，治标不治本。

1.3 TinyMCE能识别的矢量格式，其实只有SVG

在Web环境中，说到"矢量输出"，其实选项非常有限。HTML本身支持的矢量图形就是SVG，也就是可缩放矢量图形，以及Canvas，但Canvas是位图操作接口，不是内容，没法作为编辑器里的静态图形元素保存。所以你在TinyMCE里最终想得到一个可缩放的矢量图纸，就只能在SVG上做文章。

TinyMCE作为一个基于DOM的富文本编辑器，对内容的处理本质上是在操作HTML。它默认会过滤掉它认为不安全的标签，SVG恰恰就在默认过滤列表里。所以这里就引出了第一个核心矛盾：CAD图纸源格式是DWG或DXF，TinyMCE能接受的矢量格式是SVG，中间缺的就是一条"矢量桥"。

这条桥怎么搭，直接决定了后续所有工作流的效率和稳定性。在芯片制造企业的内网环境下，还额外多了一层数据安全的限制，很多外部在线转换工具压根不能用。所以我们需要一套能跑在内网、能批量处理、能自动嵌入TinyMCE的整体方案。

2. 方案选型：实现矢量输出的四条可行路线

2.1 路线一：CAD端手动另存为SVG

这是最直接的方式。AutoCAD中有"PLOT"打印功能，选择SVG打印驱动程序；或者在中望CAD、浩辰CAD中直接"另存为SVG"。

优点是不用开发，一条路走到头。但缺点也很明显：需要人工操作，而且不同版本的CAD对SVG支持程度不一样。AutoCAD从2020版本之后对SVG导出做了不少优化，但老版本导出的SVG经常出现中文乱码、线型丢失。在芯片制造企业里，很多工程师还在用2014、2016版的AutoCAD，这些版本导出的SVG质量并不理想，尤其是复杂装配体，导出后图元缺胳膊少腿。另外，手动导出的SVG通常带有很多CAD软件的私有样式和冗余节点，文件体积偏大，插入TinyMCE后渲染速度也不理想。

所以，手动另存为SVG只能作为零散场景的应急手段，比如你临时要给某个纸箱图做一次性的供应商沟通，它没问题。但作为企业级批量方案，它撑不住。

2.2 路线二：服务器端批量转换，Python方案

对于有IT团队的企业，我推荐在服务器上搭建一个批量转换服务。核心思路是：用Python读取DXF/DWG，然后渲染为SVG，最终通过企业内部文档系统或TinyMCE插件把SVG呈现给用户。

具体来说，Python生态里有两套主流方案：

• ezdxf：读取DXF文件的库，可以用addons.drawing模块把图纸渲染为SVG、PNG、PDF；
• LibreDWG + 自绘转换器：读取DWG文件，再通过svgwrite或xml.dom生成SVG。

其中ezdxf的方案我最常用。它基于DXF格式的合法解析，不依赖AutoCAD环境，支持大部分实体类型，比如LINE、LWPOLYLINE、ARC、CIRCLE、SPLINE、HATCH等，还能处理图层、块引用。

这套方案的优点很明显：批量处理，一部脚本可以转换整个目录的图纸；可定制输出，比如指定只导出某个图层、指定颜色映射；可嵌入文档管理系统，用户上传图纸后自动转换；不依赖外部服务，适合有数据安全要求的企业内网。缺点是需要的开发成本不低，而且DWG格式的解析比DXF要麻烦，毕竟DWG是闭源的，开源库的兼容性有限。

2.3 路线三：图纸管理系统集成在线预览

如果你的企业已经有PLM、EDMS或者专门的图纸管理系统，比如Windchill、Teamcenter、国内的天工、华天，这些系统通常自带图纸在线预览功能。它们通过内置的SVG渲染器把CAD图纸动态转成SVG，然后通过iframe或API方式嵌入到其他Web系统。

这种方式的优点是：不重新造轮子，直接用成熟的系统能力；图纸版本管理、权限控制都跟着走。缺点是：费用高，且如果你用的是TinyMCE自建文档系统，数据要跨系统获取，交互链路变长。在我的经验里，很多芯片制造企业其实是两种系统并存：图纸管理在PLM里，文档编辑在TinyMCE里，两边没有打通。这时候，IT团队往往会选择写一个Web服务，在TinyMCE中通过文件选择器调用PLM的预览接口，把返回的SVG插入到编辑器。

这个方案做得好，用户体验可以非常流畅，但前期的系统对接工作量很大，而且PLM厂商的接口文档往往写得比较敷衍，需要踩一段时间坑才能稳定。

2.4 路线四：专业绘图组件

还有一些偏前端方案，比如使用专业CAD/CAM的Web组件，如Autodesk Forge Viewer，它可以直接在浏览器中渲染DWG，并提供SVG导出接口。这种方案适合需要"在文档里直接查看和操作图纸"的场景。工程师不需要下载CAD软件，直接在浏览器里旋转、缩放、测量，然后一键导出一个SVG快照插入文档。

但要注意，Autodesk Forge Viewer这种在线查看器通常需要公网接口或者独立部署的云服务，而芯片制造企业出于数据保密需求，车间布局、设备参数都属于企业级机密，不太可能把图纸传到第三方云上。所以这条路在企业里落地起来限制很多。私有化部署的话，成本又比较高。

2.5 四条路线对比

我整理了四条路线的对比，方便你根据企业实际情况选择：

从芯片制造企业普遍的核心诉求来看，批量、稳定、不泄露数据、和TinyMCE无缝集成，服务器端Python批量转换是性价比最高的路线。下面我重点拆解这条路线。

3. 核心实操：用Python把DXF图纸批量转成SVG

3.1 环境准备与工具选择

我们先用最简单的方式搭一个转换服务。

首选工具是ezdxf，它是目前Python生态里最成熟的DXF解析库，当前稳定版本是0.18以上，对DXF R12到R2018都有支持。安装方式很简单：

pip install ezdxf

如果你还要处理更复杂的填充对象或者需要更精细的渲染控制，可以加装matplotlib作为渲染后端：

pip install matplotlib

如果要渲染成SVG，ezdxf自带一个addons.drawing模块。它有多个后端，包括matplotlib后端和svg后端。matplotlib后端渲染效果更接近CAD软件的显示效果，但生成的SVG是matplotlib风格，可能包含较多冗余节点。如果想要更轻量、更可控的SVG输出，可以自己写一个简单的后端，或者用ezdxf.addons.drawing的默认SVG后端。

我在项目里用的是matplotlib后端，足够稳定，且中文支持相对友好。不过也要说明一点：matplotlib后端生成的SVG，本质上是从matplotlib的图形对象导出的，所以它会保留matplotlib的一些样式信息，对于CAD图纸来说，这些额外信息会增加文件体积，但对最终显示效果没有负面影响。

3.2 实体转换的核心逻辑

直接看一个最小可行示例。假设我们有一份DXF图纸，想把它的模型空间数据渲染成SVG：

import ezdxf from ezdxf.addons.drawing import RenderContext, Frontend from ezdxf.addons.drawing.matplotlib import MatplotlibBackend import matplotlib.pyplot as plt doc = ezdxf.readfile("layout.dxf") msp = doc.modelspace() fig = plt.figure(figsize=(20, 20), dpi=100) ax = fig.add_axes([0, 0, 1, 1]) ax.set_aspect('equal') ax.axis('off') ctx = RenderContext(doc) backend = MatplotlibBackend(ax) Frontend(ctx, backend).draw_layout(msp) fig.savefig("output.svg", format="svg", bbox_inches='tight', pad_inches=0) plt.close(fig)

这段代码的核心逻辑是：读取DXF文件，拿到模型空间，也就是图纸里实际画图的地方，然后创建matplotlib画布，把DXF实体渲染上去，最后保存为SVG。

有几处细节需要说明。第一，figsize和dpi不影响SVG的矢量性质，但会影响坐标精度和渲染时的线宽比例。对于CAD图纸，通常你希望输出尺寸和原始图纸尺寸保持1:1的比例，所以figsize的宽高应该按照DXF的extents来动态设置，而不是写死。第二，ax.set_aspect('equal')是必须的，否则图纸会被拉伸变形。CAD图纸的坐标是等比例的，如果aspect不相等，圆变成椭圆，正方形变成长方形。第三，bbox_inches='tight'可以把空白裁掉，但也会导致坐标原点和图框偏移，这个问题我在后面第5章还会详细讲。

3.3 批处理脚本设计

单张图纸转换只是第一步，芯片制造企业里动辄几百上千张图纸，必须上批处理。

一个比较实用的批处理脚本模板：

import os import ezdxf from ezdxf.addons.drawing import RenderContext, Frontend from ezdxf.addons.drawing.matplotlib import MatplotlibBackend import matplotlib.pyplot as plt from pathlib import Path def dxf_to_svg(dxf_path, svg_path, dpi=300): doc = ezdxf.readfile(str(dxf_path)) msp = doc.modelspace() # 获取图纸范围，ezdxf 0.18+ 支持 bbox 方法 extents = msp.bbox() if not extents.has_data: print(f"跳过空图纸: {dxf_path}") return False min_x, min_y = extents.extmin max_x, max_y = extents.extmax width = max_x - min_x height = max_y - min_y # 按比例设置画布大小，scale单位对应英寸 scale = 100 fig_w = max(width / scale, 1) fig_h = max(height / scale, 1) fig = plt.figure(figsize=(fig_w, fig_h), dpi=dpi) ax = fig.add_axes([0, 0, 1, 1]) ax.set_aspect('equal') ax.axis('off') ctx = RenderContext(doc) backend = MatplotlibBackend(ax) Frontend(ctx, backend).draw_layout(msp) fig.savefig(svg_path, format="svg", bbox_inches='tight', pad_inches=0) plt.close(fig) return True def batch_convert(input_dir, output_dir, file_ext=".dxf"): output_dir = Path(output_dir) output_dir.mkdir(parents=True, exist_ok=True) for dxf_file in Path(input_dir).glob(f"*{file_ext}"): svg_file = output_dir / (dxf_file.stem + ".svg") print(f"转换中: {dxf_file.name}") try: dxf_to_svg(dxf_file, svg_file) except Exception as e: print(f"转换失败: {dxf_file.name}，原因: {e}") if __name__ == "__main__": batch_convert("/data/cad/dxf", "/data/cad/svg")

这个脚本有几个细节值得展开。msp.bbox()在ezdxf旧版本里可能不可用，需要手动遍历实体求包围盒。比如可以这样：

from ezdxf import bbox extents = bbox.extents(msp)

另外，不是所有实体都有几何包围盒，比如某些扩展属性或虚拟实体，所以代码里要加has_data判断。如果图纸里有块引用，ezdxf会自动展开块内的实体进行渲染，这一点很方便。但如果块里嵌套了外部参照（XREF），默认情况下不会加载外部文件，需要在读取时显式处理：

doc = ezdxf.readfile(str(dxf_path)) doc.audit()

对于包含外部参照的图纸，这个操作不是万能的，如果参照文件路径变了，还是会加载失败。所以批量转换之前，最好先做一轮完整性检查，把缺少外部参照的图纸单独列出来。

3.4 从SVG到TinyMCE的嵌入方式

转换好的SVG文件，接下来要进入TinyMCE。这里有两种主流方式。

方式一：上传SVG文件，用img标签引用

这是最稳妥的方式。把SVG文件上传到文档系统的文件存储，比如Nginx静态目录或者对象存储，然后在TinyMCE里插入一个<img>标签：

editor.insertContent('<img src="/uploads/cad/20240101_layout.svg" alt="设备布局图" />');

这种方式的好处是，编辑器内容里只包含一个URL，体积小；浏览器加载SVG作为图片文件，自动支持缩放；用户可以在TinyMCE中调整图片尺寸。坏处是，如果SVG文件被删除或者路径变化，文档里就只剩一个裂图。

方式二：内联SVG代码

如果你希望SVG内容直接嵌入文档里，可以在TinyMCE初始化时配置extended_valid_elements，允许SVG相关标签通过：

tinymce.init({ selector: '#editor', extended_valid_elements: 'svg[*],g[*],path[*],polyline[*],line[*],circle[*],rect[*],ellipse[*],polygon[*],defs[*],text[*],tspan[*]', valid_children: '+body[svg]' });

然后通过insertContent把SVG字符串插入编辑器：

const svgString = '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1000 800"> ... </svg>'; tinymce.activeEditor.insertContent(svgString);

但内联方式有一个非常关键的问题：安全。SVG本质上是XML，里面可以携带<script>、<foreignObject>、<a>等标签，如果不对SVG进行消毒，等于在文档系统里开了一个XSS后门。芯片制造企业的文档系统通常都有严格的CSP（内容安全策略）要求，所以必须把消毒工作做在前面。下一节我会专门讲TinyMCE侧的配置和安全处理。

4. TinyMCE侧的配置与安全处理

4.1 允许SVG标签的配置项

TinyMCE默认配置下，会把SVG标签过滤掉，因为SVG的复杂性和默认的valid_elements不匹配。如果你走内联SVG路线，必须显式放开。

我的建议是不要一次性放开所有SVG属性，而是根据实际需要来。比如CAD图纸转换来的SVG通常需要以下的标签：<svg>根元素，需要xmlns、viewBox、width、height；<defs>、<clipPath>、<mask>用于裁剪；<g>用于分组；<path>、<line>、<polyline>、<circle>、<rect>、<ellipse>、<polygon>是图形实体；<text>、<tspan>是标注文字。

一个相对安全的配置：

extended_valid_elements: [ 'svg[onload|onclick|xmlns|viewbox|width|height|preserveaspectratio]', 'defs[*]', 'g[transform|id|class|style|fill|stroke|stroke-width]', 'path[transform|id|class|d|style|fill|stroke|stroke-width|fill-rule|clip-path]', 'line[transform|id|class|x1|y1|x2|y2|style|fill|stroke|stroke-width]', 'polyline[transform|id|class|points|style|fill|stroke|stroke-width]', 'circle[transform|id|class|cx|cy|r|style|fill|stroke|stroke-width]', 'rect[transform|id|class|x|y|width|height|style|fill|stroke|stroke-width]', 'ellipse[transform|id|class|cx|cy|rx|ry|style|fill|stroke|stroke-width]', 'polygon[transform|id|class|points|style|fill|stroke|stroke-width]', 'text[transform|id|class|x|y|style|font-family|font-size|fill|stroke|stroke-width|text-anchor]', 'tspan[transform|id|class|x|y|style|font-family|font-size|fill|stroke|stroke-width]' ].join(',')

注意，这里显式排除了on*事件属性和<script>、<iframe>、<foreignObject>这些高危标签。这是底线。有些工程师图省事，直接用svg[*]放开所有属性，结果就是SVG里的onload事件也进来了。虽然TinyMCE本身不执行SVG里的JavaScript，但浏览器在渲染DOM时会执行，风险是实打实的。

4.2 粘贴场景的处理

工程师在CAD里直接Ctrl+C，到TinyMCE里Ctrl+V，这个场景要不要支持？我的答案是：技术上可以做，但不要强求。

因为浏览器剪贴板在这时候拿到的内容通常是EMF或WMF格式，也就是Windows增强图元文件，只有Windows平台加Chrome或Edge才能通过paste事件读取到clipboardData.items里的文件类型。而且EMF转换成SVG，前端并没有成熟的库，通常还是要上传到后端转。

我能给出的一个比较务实的做法是：在TinyMCE的paste_preprocess钩子里拦截粘贴的图片，如果检测到文件是EMF/WMF后缀，就提示用户用系统内的"上传SVG"功能替代。

paste_preprocess: function(plugin, args) { if (args.content && (args.content.indexOf('emf') > -1 || args.content.indexOf('wmf') > -1)) { args.content = '<p style="color: #c00;">请使用文档系统的"插入图纸"功能上传SVG文件，直接粘贴EMF格式无法正确显示。</p>'; } }

但说实话，这个提示对工程师来说还不够友好。更好的做法是企业内网集成一个"CAD图纸选择器"：工程师上传DXF/DWG，后端自动转换SVG，前端自动插入。这样用户根本不需要关心格式问题。我见过一个落地比较好的方案，TinyMCE里加了一个自定义工具栏按钮，点击后弹出一个内部系统弹窗，展示最近上传的图纸列表，选中即插入。这个方案前端其实不难，核心工作量还是在后端转换服务的稳定性上。

4.3 安全过滤：为什么必须消毒SVG

如果你直接用内联SVG的路线，消毒这一步绝对省不掉。

想象一下：某个工程师拿到一份来自外部的DXF图纸，里面被人为嵌入了SVG的<a>标签，指向恶意链接；或者更恶劣的，<script>标签里写了一段窃取Cookie的代码。如果系统不做任何过滤，一旦有人打开这篇文档，恶意脚本就执行了。在芯片制造企业这种安全合规要求极高的环境中，这种漏洞是审计过不了关的。

所以，即使TinyMCE的valid_elements配置了，前端过滤仍然不够，因为valid_elements只是过滤HTML标签，SVG内部嵌套的XML内容它管不了那么细。建议后端对SVG内容做一次完整的XML解析和消毒。

常用做法是用Python的defusedxml或lxml解析SVG，移除所有<script>、事件属性、javascript:协议引用。或者在前端挂载一个sanitizer库，比如DOMPurify，对插入的SVG进行清理。

// 在插入SVG前使用DOMPurify消毒 const cleanSVG = DOMPurify.sanitize(svgString, { USE_PROFILES: { svg: true, svgFilters: true } }); editor.insertContent(cleanSVG);

DOMPurify的USE_PROFILES: { svg: true }会保留SVG的图形元素，但剥掉脚本和事件。这个组合是我目前用得最顺手的。要注意，DOMPurify默认是处理HTML的，处理SVG时要把USE_PROFILES显式设置成svg，否则它会把SVG当HTML解析，结果可能丢掉很多合法图形属性。

4.4 性能优化

SVG文件虽然比位图小得多，但如果图纸特别复杂，比如一个洁净室平面图包含几万个图元，生成的SVG文件也可能达到十几MB。TinyMCE的DOM解析再快，处理这么大的内联SVG也可能导致编辑器卡顿。

我的建议是：对于超大图纸，优先使用<img src="/uploads/xxx.svg">方式，而不是内联SVG。浏览器对SVG图片的渲染和缩放有独立的优化路径，不会阻塞编辑器的DOM操作。如果一定要内联，可以在SVG进入编辑器之前做一次简化。比如去掉不可见的图层、合并相邻的相同属性路径、高精度坐标四舍五入到2位小数。这些优化可以在转换脚本里做，也可以在插入之前用Python脚本统一处理。

另外要严格控制SVG的viewBox，避免出现过大或过小的数值。比如一个坐标范围在1e9级别的DXF图纸，直接转换出来的SVG viewBox也会是1e9级别，这会导致浏览器在渲染时出现精度问题。解决办法是在转换前把模型空间的坐标整体平移，让原点归零。这个操作在ezdxf里可以这样做：

msp = doc.modelspace() # 拿到包围盒 extents = msp.bbox() min_x, min_y = extents.extmin # 平移所有实体 for entity in msp: entity.translate(-min_x, -min_y, 0)

平移之后再转换，viewBox就会落在合理的数值范围内，浏览器渲染精度问题也就不存在了。

5. 常见问题与排查技巧实录

5.1 典型问题速查表

我在实际项目里踩过的坑，整理成一张速查表，遇到问题可以直接对照。

5.2 一次"图纸位置偏移"的排查记录

我记得有一次，设备部门反馈转换出来的SVG图纸，在TinyMCE里看和CAD软件里看，位置总是偏了大概5毫米左右。排查了半天，最后发现是bbox_inches='tight'导致的。

bbox_inches='tight'会把SVG的viewBox改成"内容刚好容纳"的范围，这个范围可能与CAD图纸里的图框、标题栏位置不对应。如果在CAD里图框本身就是严格的原点坐标，但页面空白被裁剪后，SVG的viewBox起点已经不是0,0，浏览器渲染时就会产生偏移。

解决方法是：转换时不裁边，或者手动计算一个固定边距。比如在savefig之前固定：

fig.savefig(svg_path, format="svg", bbox_inches=None, pad_inches=0)

不裁边虽然会让SVG文件略大一些，但坐标关系保持不变，对于要求严格的工程图纸来说，这个代价是值得的。那次排查给我最大的教训就是：不要为了"看起来整洁"去做空间裁剪，工程图纸的坐标系本身就是信息的一部分。

5.3 关于字体和标注乱码的处理

CAD图纸里的文字标注，尤其是中文，是转换过程中的重灾区。matplotlib渲染文字时，它并不知道CAD里用的是哪个SHX字体，只能匹配系统字体。

我的经验是三步走：

1. 在转换脚本中指定中文字体，比如SimHei、Microsoft YaHei，避免matplotlib默认字体里没有中文字符而变成方块。可以这样做：

import matplotlib matplotlib.rcParams['font.sans-serif'] = ['SimHei', 'Microsoft YaHei'] matplotlib.rcParams['axes.unicode_minus'] = False

2. 如果图纸里有特殊符号，比如螺纹符号、直径符号∅、公差符号，建议在CAD端把文字属性设置为TrueType字体保存，再导出DXF时不会转成形文件。

3. 如果文字数量大且对精度要求高，最稳妥的做法是在CAD里直接使用"文字转多段线"插件，提前把文字变成矢量轮廓，SVG转换时就不会有字体缺失问题了。

在芯片制造企业的环境里，很多工程图都是从上游设计院拿来的，字体五花八门，我这里强烈建议部署一套企业统一字体库，把常用的AutoCAD SHX字体映射到TrueType，降低后期转换成本。

5.4 批量转换时的并发控制

如果你要把这个方案推广到整个企业，注意批量转换不能直接无脑并发。

先说一个我踩过的坑：用Python的多进程池并发转换DXF时，ezdxf底层对同一个文件并发读取会锁冲突，特别是文件里引用了外部字体或图块。后来我改成了线程池加进程内单文件串行读取，转换速度虽然慢一点，但稳定很多。

再就是资源限制。DXF文件解析和matplotlib渲染都比较吃内存，一张大型DXF可能占用500MB内存。如果服务器内存不大，建议每次只转换3到5个文件，或者设一个队列，一个接一个处理。

我通常的配置是ThreadPoolExecutor(max_workers=4)，每个worker独立处理自己的DXF，转换完成后写一个日志文件，方便追踪失败原因。日志里至少包含文件名、耗时、错误信息，这样即使批量过程挂了，也能快速定位是哪张图出的问题。

还有一点要提醒：如果图纸文件名包含中文或特殊字符，在Windows和Linux下的处理方式不一样，建议在脚本开头统一处理成UTF-8，并且对路径中可能存在的空格做转义，否则在Windows Server上部署时经常出现莫名其妙的路径错误。

5.5 内网环境的部署细节

芯片制造企业通常有严格的内