企业官网建设流程全解析

上个月帮一家做功率半导体晶圆的制造企业处理文档系统改造，工程师们反映最集中的问题，就是往TinyMCE里粘贴CAD图纸。粘贴几次，要么变成位图，放大就模糊；要么直接粘贴失败，留下乱码。企业要求很明确：图纸进编辑器必须是矢量输出，能缩放、能标注、能量尺寸。基于这次实施，我整理出一套完整可落地的方案，从剪贴板原理到后端转换，再到TinyMCE的坑位填充，一步步说清楚。

1. 先把问题撕开：TinyMCE到底把CAD图纸“吃”成了什么

1.1 从复制粘贴的动作，看懂剪贴板里的数据博弈

你对着CAD软件按下Ctrl+C，内心觉得“我复制了一张图纸”。实际上，CAD软件往系统剪贴板里塞了一堆东西：EMF/WMF图元文件、BMP位图，还有CAD自定义格式的图元数据，甚至可能带一段PDF预览。如果你在Windows上同时复制过文本，剪贴板里也会有纯文本格式。

问题就出在这个“一堆东西”上。TinyMCE本质上是ContentEditable封装成的富文本编辑器，它只认HTML能描述的内容，图片最终也是以base64的PNG形式嵌进文档。浏览器从剪贴板读取数据时，会优先挑选自己能处理的格式：看到位图就转成PNG，看到HTML就解析DOM，看到WMF/EMF这类老图元格式，支持不好就直接忽略。

CAD图纸在这个过程中被一层层“降维”。最原始的矢量坐标数据只有CAD软件自己能读懂，浏览器读不出来；浏览器能读到的，只剩下位图；TinyMCE再把位图转成base64存进文档。等到用户保存文档时，图纸已经不是图纸，只是一张固化在像素里的照片。我见过最典型的案例：一个工艺异常分析单里贴了一张版图局部截图，负责审核的老工程师想按比例测量两个图形之间的间距，结果软件里根本没有尺寸标注信息，只能拿屏幕尺子大概估算，这就是位图带来的悲剧。

1.2 为什么位图会让图纸精度归零

一张A4幅面的图纸，如果按300dpi扫描，像素规模大约是2480×3508，听起来不小，但对应到真实图纸上的物理尺寸，一个像素也只能表达0.085毫米。CAD图纸里记录的坐标是双精度浮点，芯片制造场景下标注动辄微米级、纳米级，两者完全不在一个数量级。

位图的本质是点阵采样，它只记录“哪个位置是什么颜色”，不记录“这条线从哪到哪、是什么线型、属于哪个图层”。你在CAD里把一条金属走线加粗，位图里体现为几个像素的变化；你在矢量图里把这条线旋转45度，位图只能重采样一遍，边缘出现锯齿。更严重的问题是放大：位图放大到200%就开始糊，放大到800%就是马赛克。工程师在文档里核对一张光刻层细节图，放大两三次就已经没法看了。

矢量图则完全不同。SVG保存的是坐标、路径、图元属性，无论放大多少倍，边缘始终平滑，坐标与原始图纸一致。对芯片制造这种精密行业来说，图纸矢量输出不是体验问题，是基本的可用性问题。一旦被转成位图，这张图纸就失去了工程价值，充其量算个参考插图。

1.3 在芯片制造场景里，丢掉矢量信息会造成什么连锁反应

芯片制造企业的图纸来源通常有两类：一类是通用机械、设备、治具的CAD设计图；另一类是版图和光罩设计导出的GDSII/OASIS数据，经过格式归一化之后变成DXF等可处理格式。两类图纸最终都会进入工艺文档、工程变更单、异常分析报告里，跟着流程在MES、EDM等系统中流转。

当这些图纸被压缩成位图，第一个连锁反应是“不可测量”。工程变更评审时，评审人需要核对图纸上的关键尺寸，位图完全没有参考坐标。第二个连锁反应是“图层信息丢失”。CAD图纸里TOP_METAL、PASSIVATION、ScribeLine这些层在位图中变成同一张RGB色块图，想单独查看某一层做不到。第三个连锁反应是“追溯困难”。质量审计时要求文档能关联到原始设计文件，位图把这种关系切断了，后面再想反查到源头版本，得靠人工记忆。

这也是“矢量输出”这件事在芯片厂远比普通办公场景重要的原因。普通公司把CAD图贴成图片也许还能接受，芯片厂不行，图纸质量直接影响产线判断。需求侧就是这么刚性，技术侧才值得认真投入。

2. 矢量输出的技术路线：四种方案，各有各的命

2.1 方案A：服务端将CAD文件转为SVG再插入编辑器

这是目前最稳妥、也是我最终采用的主方案。思路不复杂：CAD图纸不直接塞进TinyMCE，而是上传到后端转换服务，后端用解析库读取DXF数据，重新绘制成SVG字符串，返回给前端，前端把这个SVG节点插入编辑器光标位置。整个过程对用户来说还是“从CAD复制，到网页粘贴”，但中间多了一个专业的转换环节。

选择这个方案的核心原因是精度保留和浏览器解耦。后端转换用的是专业解析库，读的是DXF文本格式里的原始坐标，生成SVG时坐标不经过任何像素化处理，精度没有任何损耗。而且这种方案完全不依赖浏览器对剪贴板的支持程度，不管是Chrome、Edge还是企业内网老掉牙的IE兼容模式，只要能发HTTP请求就能用。缺点是需要多维护一个转换服务，但这个服务本身很轻，一台2C4G的机器跑几千人同时转换都够用。

2.2 方案B：浏览器端解析DXF直接渲染SVG

浏览器端用JavaScript解析DXF也是一个可行路线。前端拿到DXF文件后，通过解析库把实体数据读出来，再用SVG元素动态绘制。不用走后端，部署成本低，适合图纸量不大、复杂度不高的场景。

我测试过这个方案后发现它有几个现实问题。第一，DXF版本兼容性非常折腾，从R12到2018，不同版本的关键字、实体类型、组码都有差异，纯前端解析库对这些边界情况处理得并不完美，稍微复杂一点的块引用或者代理实体就可能渲染出错。第二，大文件性能扛不住，一个几十MB的DXF文件在浏览器里解析加渲染，页面会卡到无法操作。第三，安全上也存在风险，一些DXF文件里可以嵌入外部实体或脚本内容，浏览器端直接解析等于把不可信内容放进了渲染环境。因此这个方案我用来做轻量预览可以，做正式文档编辑还是不够稳。

2.3 方案C：人工导出EMF再从源头统一转换

企业内部总有那么几个老工程师，习惯从CAD里导出EMF格式再贴到文档里。EMF是Windows图元格式，保留了一部分矢量信息，Word里显示效果不错，但Web端支持很差，TinyMCE根本不会把EMF当矢量内容解析，最终还是会退化。

我们最后做了一件事：在内部做一个“图纸上传转换”工具，允许工程师直接拖入EMF、DXF、DWG，后端统一处理成SVG，再复制到剪贴板或直接插入文档。这个方案适合已经习惯手动导出的团队做平滑过渡，不用改变工程师的操作习惯，但自动化程度不高，需要人主动做“导出-上传”这个动作。如果企业有PLM系统，建议把这个工具嵌到PLM的文档编辑界面里，让工程师在统一入口完成操作。

2.4 方案D：大图纸不硬塞编辑器，改用独立图纸查看器

有些版图文件动辄上百MB，全量转成SVG塞进TinyMCE，就算浏览器能渲染，编辑器也会被拖到卡死。这种场景就别强行矢量化，更不要尝试位图化，两条路都走不通。正确的做法是保留原始CAD文件在图纸管理平台，在TinyMCE文档里嵌入一个查看器链接或iframe占位。

用户点击占位区域，新窗口打开高清矢量预览，支持缩放、测距、图层开关。文档里保存的是一段包含图纸ID和版本号的引用数据，而不是图纸本体。这种方案不会把TinyMCE拖垮，也保证了图纸来源可追溯。芯片制造厂里很多光罩图和整厂设备布局图，就适合走这条路。技术方案不要搞一刀切，小图转SVG进编辑器，大图走独立查看器，两者结合最合理。

2.5 四种方案对比选择

从我的实施经验看，企业内部没必要一上来就追求单一方案全覆盖。先用方案A解决80%的普通图纸；遇到一个文件超过50MB的，直接走方案D。两个方案加起来，已经能覆盖芯片制造企业文档系统里几乎全部CAD图纸场景。

3. 实操落地：给TinyMCE装上“CAD矢量粘贴”能力

3.1 核心配置：先让TinyMCE别把图变成base64

TinyMCE默认的粘贴行为，是把粘贴进来的图片转成base64字符串嵌到文档里。我们要做矢量输出，首先就要禁用这个默认行为，否则CAD图还没走到我们自己的转换逻辑，就已经被它呼吸一样自然地“吞”成了位图。

初始化配置里最关键的两个参数是paste_data_images和paste_preprocess。paste_data_images设成false，告诉TinyMCE不要自动把外部图片转成内嵌图片；然后我们自己在paste事件里拦截剪贴板数据，判断是不是CAD文件或CAD自定义格式，再走自己的流程。基础初始化配置如下：

tinymce.init({ selector: '#docEditor', plugins: 'paste preview searchreplace', toolbar: 'undo redo | pastespecial | preview', paste_data_images: false, extended_valid_elements: 'svg[*],defs[*],g[*],path[*],line[*],polyline[*],polygon[*],rect[*],circle[*],ellipse[*],text[*],tspan[*],clipPath[*],mask[*],use[*]', valid_children: '+body[svg],+div[svg],+p[svg],+td[svg]', setup(editor) { editor.on('paste', (e) => { // 这里做CAD数据识别 }); } });

注意extended_valid_elements这行，它是要给TinyMCE扩充白名单的关键，后面第3.4节还会专门讲。先把配置放这里，后面用的时候不会忘。

3.2 拦截粘贴事件，识别CAD剪贴板数据格式

paste事件触发时，我们可以从e.clipboardData.items里读到剪贴板内容。CAD文件最常见的识别方式是看文件扩展名：DXF或DWG。当用户在系统里拖入或复制了一个CAD文件时，items里会有一个kind为file的对象。完整的拦截逻辑如下：

function isCADFile(file) { return /\.(dxf|dwg)$/i.test(file.name || '') || file.type === 'application/x-dxf'; } setup(editor) { editor.on('paste', (e) => { if (!e.clipboardData) return; const items = e.clipboardData.items; if (!items) return; for (let i = 0; i < items.length; i++) { const item = items[i]; if (item.kind === 'file') { const file = item.getAsFile(); if (file && isCADFile(file)) { e.preventDefault(); uploadAndInsertCad(file, editor); } } } }); }

这里要老实说一句：直接从CAD软件里Ctrl+C复制的图元，在浏览器剪贴板里通常拿不到DXF文件对象，因为CAD自定义格式是Windows私有MIME，浏览器跨不过权限边界。这个问题在第四章坑里还会细说，实操时我的建议是“复制粘贴识别”和“拖拽上传识别”两手准备。拖拽上传时前端也能拿到File对象，逻辑完全一样。

uploadAndInsertCad函数负责把文件交给后端，拿到SVG后插入文档：

async function uploadAndInsertCad(file, editor) { const formData = new FormData(); formData.append('file', file); formData.append('layerMode', 'preview'); try { const resp = await fetch('/api/cad2svg', { method: 'POST', body: formData }); const data = await resp.json(); if (data.svg) { const svgNode = new DOMParser() .parseFromString(data.svg, 'image/svg+xml') .documentElement; const wrapper = document.createElement('div'); wrapper.className = 'cad-vector-wrapper'; wrapper.appendChild(svgNode); editor.insertContent(wrapper.outerHTML); } } catch (err) { editor.notificationManager.open({ type: 'error', text: 'CAD图纸转换失败，请确认文件格式后重试' }); } }

如果工程图纸相对简单，用户使用“拖拽上传”而不是“复制粘贴”，这套代码已经能独立工作。从CAD复制后直接粘贴那种体验，需要后端配合CAD插件做深度定制，见第四章。

3.3 后端转换服务：DXF到SVG的转换实现

后端我用FastAPI写了一个极简接口，核心库用ezdxf。选择它是因为开源、文档全、对文本DXF兼容性好，而且自带绘图前端，可以输出SVG。下面是一套可运行的代码骨架，兼容了文件损坏自动修复：

from fastapi import FastAPI, UploadFile import os import tempfile import ezdxf from ezdxf import recover from ezdxf.addons.drawing import RenderContext, Frontend from ezdxf.addons.drawing.matplotlib import MatplotlibBackend app = FastAPI() @app.post("/api/cad2svg") async def cad2svg(file: UploadFile): suffix = os.path.splitext(file.filename or "")[1].lower() with tempfile.NamedTemporaryFile(suffix=suffix, delete=False) as tmp: tmp.write(await file.read()) tmp_path = tmp.name try: # 使用recover模式：DXF文件有损坏时先修复再读取 doc = recover.readfile(tmp_path, audit=True) msp = doc.modelspace() ctx = RenderContext(doc) backend = MatplotlibBackend() Frontend(ctx, backend).draw_layout(msp, finalize=True) svg_path = tmp_path + ".svg" backend.save_svg(svg_path) with open(svg_path, "r", encoding="utf-8") as fp: svg_text = fp.read() return {"svg": svg_text} finally: os.remove(tmp_path) if os.path.exists(tmp_path + ".svg"): os.remove(tmp_path + ".svg")

这里必须补充一句：ezdxf.addons.drawing的API在不同版本之间有过调整，上面的写法基于常见的1.x版本，如果你的运行环境版本不同，以官方文档为准。核心思路不变：读取DXF实体，交给绘图后端，生成SVG字符串。

对于DWG文件，Python生态里直接解析DWG比较费劲，DWG是二进制私有格式，版本差异大。我们的做法是在源头统一转DXF：给工程师发一条规范，要求所有进文档系统的图纸统一输出DXF版本。自动化批转可以使用常见的DWG转DXF命令行工具，在公司内网布一个定时任务，把旧DWG批量转换到DXF目录。芯片制造企业如果源头是版图工具导出的GDSII/OASIS，同样要增加一个“格式归一化”环节，先用EDA工具链导出一版DXF，再进TinyMCE的转换服务。

3.4 SVG白名单：防止TinyMCE把SVG标签“吃”掉

这是整个改造里最容易忽略、也是坑最深的一个环节。TinyMCE内部维护了一套HTML schema，凡是不在白名单里的标签，保存文档时都会被过滤掉。SVG标签默认不在白名单里，这就导致一个诡异现象：你插入SVG时编辑器预览里看着好端端的，保存后再打开，SVG整个消失了，只剩一个空div或一段残缺代码。

解决方案就是在init配置里往上一步写过的extended_valid_elements和valid_children里补内容。extended_valid_elements用来声明哪些标签允许出现，valid_children用来声明这些标签可以挂在哪些父节点下。SVG涉及的自闭合、子元素较多，我直接把可能用到的元素都声明上：

extended_valid_elements: 'svg[*],defs[*],g[*],path[*],line[*],polyline[*],polygon[*],rect[*],circle[*],ellipse[*],text[*],tspan[*],clipPath[*],mask[*],use[*]', valid_children: '+body[svg],+div[svg],+p[svg],+td[svg]',

一个容易踩的点是：如果你的TinyMCE通过content_css或者自定义样式给SVG做了隐藏或宽度限制，还要额外加一段自定义CSS，确保SVG默认能撑开显示。我们当时在预览里SVG显示成一条线，排查了很久，最后发现是全局样式里给svg加了max-width: 100%，但没给高度，导致它缩成了一条几乎不可见的线。

3.5 完整流程串联：从CAD到SVG的端到端链路

把这几个环节串起来，最终用户感知到的操作流程就是一个标准的上传转换链路：

1. 工程师从CAD软件导出DXF文件，或者在我们的“图纸上传”入口直接拖入原始文件。
2. TinyMCE在paste或drop事件里捕获File对象，识别文件名后缀是.dxf/.dwg后preventDefault，禁止默认粘贴。
3. 前端把文件POST到/api/cad2svg接口，后端用ezdxf读取DXF，生成SVG字符串。
4. 前端把SVG字符串解析成DOM节点，包一层div.cad-vector-wrapper，插入编辑器光标位置。
5. 用户保存文档时，TinyMCE因为白名单已经放行SVG相关标签，SVG内容被完整存进数据库或文档文件。
6. 再次打开文档时，SVG节点原样渲染，所有矢量信息都在。

整个链路核心就两步：上转下收，中间统一格式。高精度取决于后端转换时没有做栅格化，TinyMCE这边的稳定性取决于白名单配置有没有漏项。

4. 真实踩坑记录：我们实现过程中遇到的几个深坑

4.1 坑一：SVG插入后被编辑器偷偷砍掉一半

第一个遇到的坑就是第3.4节说的白名单问题。当时我们在开发环境插入SVG，预览正常，刷新之后SVG里的path全部不见了，只留下一个空壳。排查过程花了不少时间，最终确认是TinyMCE保存时按schema清理了未声明标签。

解决办法是同时配置extended_valid_elements和valid_children，两者缺一不可。只放行标签但不说清楚父节点，TinyMCE不知道SVG该放在哪，还是会处理掉。填完配置后，我们又写了一个RPA脚本做了100轮“插入-保存-重开-比对”的自动化验证，确认SVG标签不再丢失，才敢上线。

4.2 坑二：剪贴板识别在不同浏览器下行为分裂

Chrome里从AutoCAD等软件复制图元后，clipboardData.items能读到image/png和一些自定义MIME格式；同一操作换到Firefox，items里可能只有text/html和text/plain，CAD图元包装后的自定义格式完全读不到。TinyMCE在不同浏览器里的paste行为也不一致，导致我们最开始“从CAD复制后直接粘贴”的设想直接落空。

最后我们调整了设计预期：不追求纯浏览器端识别CAD私有剪贴板格式，改为主推“文件上传”方式。为了保住“复制粘贴”体验，我们在CAD软件里装了一个轻量插件，工程师框选要发布的图元后执行宏，插件自动把局部DXF导出并通过内网HTTP POST上传到转换服务，返回SVG后再自动填写进TinyMCE。这个方案跨浏览器完全一致，因为根本不依赖浏览器剪贴板。教训就是：企业场景里浏览器是一道铁墙，撞不破就要绕路。

4.3 坑三：图纸太大，编辑器直接卡死

一套完整的光罩DXF文件转成SVG后，可能会产生数万个SVG节点。TinyMCE编辑区要维护光标、选区、撤销栈，每插入一个复杂节点都会引发重排。我们实际测过，一个包含三万个图元的SVG插进去，编辑器输入字符直接变“幻灯片”，卡顿到让人怀疑人生。

应对策略是分层预览。转换服务支持一个layerMode=preview参数，后端在绘图前端渲染时只保留关键图层：外框层、顶层金属、主要标注层、字符层，其余的填充层、辅助层全部过滤掉。预览SVG节点数能下降一个数量级，编辑器操作恢复流畅。在SVG旁边放一个“查看完整图纸”按钮，点击后打开独立图纸平台展示全量版本。这样既保证了文档里的矢量语义，又不牺牲编辑性能。

4.4 坑四：字体缺失导致标注乱码

DXF文件里的文字实体通常记录了字体名称，但在Linux容器里没有对应的中文字体时，后端渲染SVG会出现方块乱码或字体错位。芯片厂的图纸标注里中英文混杂，问题被放得很大。

解决方法是给转换服务所在容器预装常用工程字体，并在后端做一个字体映射：DXF声明的字体名映射到容器里实际安装的字体路径。中文字体至少准备仿宋、宋体、黑体，西文准备Arial和Times New Roman。转换时如果遇到未映射字体，统一落到默认字体，不要直接抛异常。这个问题在Windows开发环境很难暴露，部署到Linux之后就藏不住了，属于典型的环境差异问题。

4.5 常见问题速查表

5. 顺带分享一下：这个方案还能往哪些方向扩展

5.1 把转换能力做进TinyMCE插件里

我们最开始是直接改初始化时的paste回调，代码全堆在页面里，后来觉得还是太散，就把整个逻辑抽成了一个名叫cadVector的TinyMCE插件。插件通过editor.ui.registry.addButton注册一个“插入CAD图纸”按钮，点击后弹出自定义的对话框，里面既可以拖拽文件，也可以从图纸库直接按图纸编号检索并插入。插件内部统一处理paste、drop和按钮三条入口，避免同一套逻辑到处复制。

做成插件之后，文档里的SVG样式、加载状态、错误提示也统一收敛了。以后要升级转换逻辑，只需要替换插件内部调用的接口，TinyMCE主体配置不用动。如果企业用微前端架构，这个插件可以继续拆成独立组件，通过编辑器暴露的API对外集成。

5.2 配合PLM系统的版本追溯

图纸转换成SVG之后，如何与原始设计版本建立关联，是一个很快就浮出水面的需求。我们在每次转换请求时给SVG加了一个不可见属性>