企业官网建设流程全解析

上个月封装设计评审会之前，工艺工程师给我发来一条消息：基板图在评审系统里放大根本看不清线间距，能不能把 CAD 图直接贴进去还能缩放？这正是芯片制造企业里最典型的需求场景——CAD 图纸、TinyMCE 编辑器、矢量输出，这三样东西凑在一起，看起来只是"粘贴"这个动作，实际上牵扯到图纸格式选型、转换链路搭建、编辑器插件配置一整套问题。这篇文章就把我踩过的坑和最终跑通的方案完整记录下来，适合正在做研发管理系统、工艺评审系统、文档知识库，并且需要把 DWG/DXF 图纸嵌入 Web 页面的工程师参考。我会从问题根源讲起，再把两条核心转换链路和 TinyMCE 侧的关键改造逐一说清楚。

1. 芯片制造里的"图纸进文档"场景，卡点到底在哪

1.1 为什么芯片企业一定要把 CAD 图贴进 TinyMCE

芯片制造企业里，CAD 图纸不只在设计部流转，还大量出现在跨部门的文档协作场景中：封装设计评审要附基板剖面图，DFM 工艺评审要贴引线框架的尺寸图，异常分析报告要放失效位置的放大图，ECN 变更通知单要在同一份文档里对比改版前后的版图。这些流程普遍跑在企业内部的 OA、PLM 或项目管理系统上，而大量这类系统的富文本编辑器用的就是 TinyMCE。

所以"贴图"不是个人习惯，而是业务流程的硬需求。评审专家需要在文档里直接看到图形内容，而不是下载附件再打开 CAD 软件。但问题在于，图纸一旦被粘贴进网页，几乎所有工程师的第一反应都是截图。截图确实快，可截图是位图，芯片制造领域要看的偏偏是细密的小特征：线间距、焊盘间距、倒角半径、字符高度。位图在 100% 显示时还能看，一旦放大两倍三倍，全是马赛克，评审基本没法做。

更要命的是，图纸里的图层信息、尺寸标注、精确坐标在截图里彻底消失了。评审时有人问"这条线离边框多少毫英寸"，你没法在截图里量，只能回到 CAD 软件里再查一遍，整个评审节奏被打断。所以痛点从来不是"能不能贴上"，而是"贴上了之后还能不能保留矢量信息、能不能放大、能不能量测"。

1.2 直接粘贴的三个瓶颈：位图糊、图层丢、单位乱

很多人第一反应是用 CAD 软件直接 Ctrl+C 复制图纸，然后切到 TinyMCE 按 Ctrl+V。这个动作我从早期项目就开始测试，结论是：这条路基本走不通。

先从剪贴板的角度看。AutoCAD 或 Altium Designer 里复制对象时，往剪贴板塞的是 Windows EMF/WMF 矢量图元格式，部分场景下还会同时放一份位图副本。TinyMCE 拿到这些内容时会怎么处理？它会优先取 HTML 格式的片段，而 CAD 复制出来往往没有规范的 HTML，浏览器最终渲染出来的可能是一张位图。微信截图式体验还是好的，更多情况是粘贴后什么也出不来，或者出来一个无法编辑的 OLE 对象，刷新页面就没了。

就算粘贴成功，图层信息也一定会丢。CAD 图纸的价值一半在图层结构上：哪一层是 TOP、哪一层是 SILKSCREEN、哪一层是 KEEPOUT，评审时经常需要单独看某一层。一旦变成位图，这些结构全没了，只剩一个平面图像。

还有单位问题。CAD 里一个绘图单位可能是毫米，也可能是密尔（mil），图纸出图比例还可能有 1:10、1:20 之类。直接复制粘贴到网页，浏览器不知道原图纸的单位和比例，显示出来可能是 1px 对应 1 个绘图单位，25.4mm 的焊盘显示出来只有 25px。尺寸观感全错，评审人员如果对着它估尺寸，非出事不可。

所以"直接粘贴 CAD 图纸"这个动作本身就违背了矢量化需求。矢量输出必须在粘贴之前增加一个转换环节，把 CAD 原生格式转成 Web 能理解、TinyMCE 能承载、浏览器能无损缩放的矢量格式。

2. 矢量输出路线选型：为什么是 SVG 而不是 PDF 或 EMF

2.1 四条候选路线横向对比

接到需求后我先列了候选方案，核心评判标准有四条：浏览器兼容性、TinyMCE 可编辑性、矢量保留程度、工程上能不能批量自动化。当时比的方案大概是这几个：

对比下来很清晰：PDF 更适合"整份图纸作为附件预览"的场景，但要嵌进 TinyMCE 并随文档一起编辑排版，体验太差。EMF 在 Windows 浏览器上或许还有用，但它天然是 Windows 生态的产物，跨平台就是灾难。PNG 截图谁都会，但它解决不了评审放大问题，直接出局。

2.2 SVG 方案在芯片图纸场景的三个关键优势

SVG 胜出不是偶然，它有三点对芯片制造场景特别有利。

第一，SVG 是纯文本 XML 格式，这意味着它可以被程序读取、截取、校验。转换链路里我可以写脚本把某些图层过滤掉、把某些颜色统一、把坐标平移到原点，这些操作在 PDF 里很难做，在 SVG 里就是字符串处理加简单数学变换。

第二，SVG 的 viewBox 机制天然支持任意缩放。viewBox 定义的是逻辑坐标系，浏览器会自动映射到实际的显示宽高。评审时放大多少倍，画质都不会下降，边缘永远清晰。这一点对标的是"芯片图纸里全是细密线条"这个特性，位图做不到，PDF 网页里也做不到这么流畅。

第三，SVG 可以按图层拆分成多个独立元素，后续还能继续做标注、超链接、自动读取坐标等自动化操作。举个实际例子，我们后来做了一个功能：把封装基板 SVG 里所有 KEEPOUT 层图形提取出来，自动生成间距检查报告。如果当初用 PDF 或截图，这个功能就没法做了。

3. 核心转换链路实操：DWG/DXF 到可粘贴 SVG 的两条成熟路径

3.1 链路 A：CAD/EDA 端导出 PDF，再转 SVG

这条链路适合完整保留图纸原貌的场景，尤其是图纸里包含了大量填充、剖面线、尺寸标注、复杂块引用的时候。它的思路是：不在源代码层面解析，而是让 CAD 软件自己完成渲染，输出 PDF 后再转成 SVG。

实际步骤分三段。第一段，在 AutoCAD 或 Altium Designer 里用"打印/输出"功能生成 PDF。这一步最关键的设置是打印样式。如果打印样式里把颜色都映射成了灰度或者黑白，转换出来的 SVG 也全是黑白的，评审时想按颜色区分层就很难受。所以我一般建议单独建一个打印样式，保持原始颜色，线宽统一设为 0.18mm 左右，不要让超细线在转换后消失。

第二段，PDF 转 SVG。推荐两个工具，命令行都很短：

# 方式一：pdf2svg，简单直接 pdf2svg source.pdf output.svg # 方式二：Inkscape，控制能力更强 inkscape source.pdf --export-type=svg --export-filename=output.svg

pdf2svg 胜在快、无依赖、一条命令出结果，适合批量处理。Inkscape 适合处理带复杂字体的图纸，它有字体替换和路径转换能力。我在项目里是先用 pdf2svg 批量兜底，遇到文字显示有问题的个别图纸再单独过 Inkscape。

第三段，验证输出。转换完 SVG 后，重点检查三样东西：文字是否正常、图框是否完整、线宽是否可见。PDF 转 SVG 之后，原来 CAD 里的 SHX 字体经常变成路径或特殊字符，后面第 5 章我会专门讲这里面的坑。

这条路线的优点是省心，CAD/EDA 端怎么显示，转出来就是什么样。缺点是全量输出，你没法在转换阶段直接过滤图层，也没法针对某一层专门做处理。所以它更适合贴"最终图纸"的场景。

3.2 链路 B：Python ezdxf 定向解析 DXF 生成 SVG

如果需求是"只要 TOP 层和 SILKSCREEN 层""去掉图框""把颜色统一成带图层的规范色"，那就不能走打印路线了，直接解析 DXF 是更好的选择。Python 生态里有现成的 ezdxf 库，它对 DXF 文件的读写和渲染支持很完整。

核心代码可以精简成这样：

import ezdxf from ezdxf.addons.drawing import RenderContext, Frontend from ezdxf.addons.drawing.svg import SVGBackend doc = ezdxf.readfile("baseboard.dxf") msp = doc.modelspace() backend = SVGBackend() ctx = RenderContext(doc) Frontend(ctx, backend).draw_layout(msp, finalize=True) backend.save("baseboard.svg")

这样一行 Row 就能把一个 DXF 的模型空间完整渲染成 SVG。但这个库默认是全量渲染，如果你想过滤图层，需要在画之前对实体集合做筛选：

keep_layers = {"TOP", "BOTTOM", "SILKSCREEN", "KEEPOUT"} # 这里不等于真正的过滤，但可以用遍历方式控制需要保留的实体 for e in msp: layer = e.dxf.layer if layer not in keep_layers: # 移到隐藏层或从临时文档删除 pass

我试过的更稳妥做法是：用 ezdxf 读原图，新建一个空白 DXF，把符合图层条件的实体 copy 过去，再对临时文档做 SVG 渲染。这样既控制了输出内容，又不会污染原文件。

再补充一个坐标归一化的处理：CAD 图纸里实体的坐标常常是几百、几千甚至几万，直接渲染进 SVG 后 viewBox 可能是一个巨大的数值范围，浏览器解析虽然没问题，但后续编组、注释、打印很别扭。推荐先算一下所有保留实体的包围盒，然后做一次平移，让图形从原点附近开始：

from ezdxf import bbox ext = bbox.extents(list(msp)) min_x = ext.extmin.x min_y = ext.extmin.y # 在渲染前对坐标做平移变换，或者渲染后在 SVG 根元素上平移

这条链路的问题是：DXF 解析对复杂实体的渲染能力不如 CAD 软件自身。HATCH 填充、尺寸标注、块嵌套、代理实体这些内容，ezdxf 虽然支持但效果可能和原图有偏差。所以我的经验是：全图优先走链路 A，图层筛选和坐标整理优先走链路 B，两条链路互补使用。

3.3 Altium Designer / Cadence 场景的补充

芯片制造企业的图纸不完全是 AutoCAD 的 DWG/DXF，很多封装、板级图纸来自 Altium Designer 和 Cadence Allegro/OrCAD。这些工具的图纸要进 TinyMCE，思路是一样的：先导出为中间格式，再走 SVG 转换。

Altium Designer 里最直接的方式是打印预览导出 PDF，等于走链路 A。并且要注意，Altium 的 PCB 图导出 PDF 时，铜皮和走线会保留矢量，这正是后面转 SVG 后还能放大看细节的基础。如果你拿到的是已经转成 DXF 的文件，就正常走链路 B 就行。

Cadence Allegro 的导出逻辑类似，File 菜单里 Export 成 DXF，然后在 Python 侧统一处理。有一点要提醒：热词里常看到"ad20 怎么把 CAD 导入的特殊形状转换成铜皮""Altium Designer 21 CAD 制作异形封装"这类问题，这属于 EDA 设计阶段的操作，应该在图纸导出之前解决。转换链路接收的应当是最终成品图，而不是半成品。我们做文档系统时，明确要求设计部门输出的 DXF 必须是"展开且已闭合"的图形，避免到了 SVG 阶段发现图形是孤立的散线，评审时还以为是断线。

4. TinyMCE 落地改造：粘贴 SVG 的三个关键细节

4.1 让 TinyMCE 认识 SVG：内联与 img 两种姿势

拿到 SVG 文件之后，下一个问题是怎么让它进 TinyMCE。我试验过两种姿势，各有适用场景。

姿势一：SVG 以真实标签内联到编辑器里。TinyMCE 默认的 valid_elements 规则会过滤掉它不认识的标签，直接贴 SVG 经常出现"标签被吃掉"的情况。解决办法是在初始化时扩展允许的元素：

tinymce.init({ selector: '#editor', extended_valid_elements: 'svg[*],path[*],g[*],rect[*],circle[*],ellipse[*],line[*],polyline[*],polygon[*],text[*],defs[*],use[*]', // 其他配置... });

[*]表示允许该标签的所有属性，这在 TinyMCE 的 valid_elements 语法里是支持的。但实际用下来，内联 SVG 在编辑状态下的体验并不好：光标会进入 SVG 内部，按删除键可能把图形拆散，还有一些旧版浏览器会对text标签的渲染产生兼容问题。结论是：内联 SVG 适合"几乎只读"的文档系统，不适合需要频繁编辑富文本的环境。

姿势二：把 SVG 作为 img 的 data URI 插入。这是我在项目里最终采用的方案。原理是把 SVG 文件读成 DataURL，然后以图片的形式插入编辑器：

tinymce.init({ selector: '#editor', paste_data_images: true, setup: function (editor) { editor.on('paste', function (e) { const clipboard = e.clipboardData || window.clipboardData; if (!clipboard) return; const items = clipboard.items; for (let i = 0; i < items.length; i++) { if (items[i].type === 'image/svg+xml') { e.preventDefault(); const file = items[i].getAsFile(); const reader = new FileReader(); reader.onload = function (ev) { editor.insertContent( `<img class="svg-vector" src="${ev.target.result}" alt="CAD SVG 图纸">` ); }; reader.readAsDataURL(file); break; } } }); } });

以 img 形式插入后，TinyMCE 把它当普通图片管理，光标不会进入 SVG 内部，删除、拖动、排版都正常。关键点在于：SVG 作为 img 的 src 时，浏览器会禁用其中的 JavaScript 和外部资源加载，这反而是安全特性，评审系统里不用担心 SVG 里藏脚本。

4.2 从剪贴板拦截 SVG 与手动上传兜底

上面的代码处理的是从文件管理器复制 SVG 文件再粘贴的情况，但用户更自然的习惯是"在 CAD 里复制完图纸，切到浏览器粘贴"。问题在于 CAD 复制出来的剪贴板里往往没有image/svg+xml这一项，拦截逻辑不会触发。

我项目里的妥协方案是分两条路配合。一是把上面接线做成一个独立的转换工具，用户用快捷键或者按钮把 CAD 图纸拖进去，工具直接输出一个复制按钮，点一下就复制了 SVG 二进制内容，然后用户回到 TinyMCE 粘贴。二是在 TinyMCE 工具栏加一个"插入 SVG 图纸"按钮，手动选择本地 SVG 文件，走 FileReader 读入。

按钮方式的事件处理可以这样写：

editor.ui.registry.addButton('insertSvg', { text: '插入SVG图纸', onAction: function () { const input = document.createElement('input'); input.type = 'file'; input.accept = '.svg,image/svg+xml'; input.onchange = function () { const file = input.files[0]; if (!file) return; const reader = new FileReader(); reader.onload = function (ev) { editor.insertContent( `<img class="svg-vector" src="${ev.target.result}" alt="SVG图纸">` ); }; reader.readAsDataURL(file); }; input.click(); } });

这里有个细节值得强调：如果 SVG 文件本身很大（超过 1MB），我用 DataURL 插入会导致编辑器内容和文档库体积迅速膨胀。我们后来做成了上传到独立文件服务，插入的是文件 URL，而不是 DataURL。保存时文档里只有一个/uploads/xxx.svg链接，数据库压力小很多，图片加载也更快。DataURL 只用于临时预览或小图。

4.3 viewBox、宽度与显示比例的统一

SVG 插入编辑器后，最常见的问题是尺寸乱掉。原因很简单：SVG 根元素上同时有viewBox和width/height。viewBox表示逻辑坐标范围，width/height决定显示的物理尺寸。如果转换脚本只写了viewBox没写width，行为由浏览器默认值决定，插入进 TinyMCE 后经常撑满整个编辑区，或者缩成一个小图标。

我后来总结出的规范做法是：转换工具输出 SVG 时，固定设置width和height，让它对应当前图纸的预期显示尺寸，同时保留完整viewBox。比如，一张 A4 横版图框，转出来可以是这样：

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 11692 8268" width="800" height="566"> </svg>

这样处理的好处是：编辑器里第一眼看到的是一个接近真实阅读体验的图片大小，放大缩小由浏览器的图片缩放机制接管，矢量细节不丢。如果再想统一约束文档里所有 SVG 图片的宽度，写一行 CSS 就够：

img.svg-vector { max-width: 100%; height: auto; }

再补充一个单位关系：SVG 在网页上显示，长度单位最终都会换算成 CSS 像素，96px 约等于 1 英寸。CAD 的 1 个绘图单位如果代表 1mm，那么 1mm 显示在屏幕上约等于 3.78px。如果你要图片里的一毫米在屏幕上实测也接近一毫米，width 就得按毫米值乘 3.78 来设置。评审场景下一般不做这种硬性缩放，更常用的做法是保留一个比例尺标注，让人知道图纸的真实尺寸关系。

5. 芯片制造场景专项避坑：图层、字体、精度、性能

5.1 图层过滤与颜色规范化

芯片制造企业的图纸有严格的图层管理体系，层名一般是固定的：TOP、BOTTOM、SILKSCREEN、KEEPOUT、MECHANICAL_1 之类。转换时如果没有做过滤，所有层都混在一起，SVG 里线条颜色杂乱，评审基本没法用。

我在链路 B 中固定做了一步图层白名单过滤：业务上需要看哪些层，就只保留哪些层。比如贴到评审报告里通常只需要 TOP 层、BOTTOM 层和丝印层，机械层、尺寸层、图框层可以根据场景取舍。

颜色规范化同样重要。CAD 图形里实体颜色经常随手画的，红色、黄色、青色什么都有。转 SVG 之后，如果不统一，文档里花花绿绿，打印出来更乱。我一般按层规约：

在 ezdxf 阶段做颜色替换比在 SVG 阶段做简单得多，因为每个实体的dxf.color都是明确的整数值，可以直接映射。

5.2 中文标注与 SHX 字体缺失

这是整个转换链路里翻车率最高的问题。CAD 图纸里大量使用 SHX 字体（AutoCAD 的单线字体）或自定义的中文字体，这些字体在 Web 环境里几乎都不存在。PDF 转 SVG 后，文字的常见表现是：

• 中文变成一坨方框或问号
• 文字位置错乱，叠在线条上
• 文字整体变成路径但字形残缺
• 字体名称在 SVG 里引用了一个不存在的字库

我排查这类问题的经验是分三档处理。第一档，CAD 源文件可控的情况下，要求前端人员不要用特殊 SHX 字体，改用 Windows 自带的宋体或黑体，它们转 PDF 和 SVG 的成功率很高。第二档，图纸已经定型不允许改字体时，在打印前把文字炸开成线段（AutoCAD 里TXTEXP或类似工具），这样 PDF 里文字就是纯矢量曲线，SVG 输出也稳定。第三档，已生成 SVG 后发现文字异常，用 Inkscape 打开 PDF 再导出 SVG，并手动把文字转成路径，命令类似：

inkscape source.pdf --export-type=svg --export-filename=output.svg --convert-text-to-path

--convert-text-to-path这个参数能强制把文字转成路径，彻底绕开字体依赖。代价是 SVG 体积变大，文件小几十倍的文本就膨胀成几 MB 的路径数据，但评审场景图的可读性优先于体积。

5.3 坐标精度、科学计数法与单位换算

为什么 CAD 画直线的时候会显示2.1616e+...这种奇怪的东西？很多人第一次看到这个都被吓到，以为是软件出错了。其实这不是 bug，是 AutoCAD 命令行坐标显示的科学计数法。出现这种情况的原因基本是两个：一是坐标数值太大，图形远离原点几百万个单位，命令行自动切到科学计数法显示；二是图形里存在极小或极大的几何元素，比例失衡。

这件事在 SVG 转换场景里也有对应版本。如果你把 DXF 实体坐标原封不动写进 SVG 的d属性，坐标范围大到一定程度时，部分 SVG 解析器或后续工具会对1e+07这种写法产生歧义。所以我强烈建议转换前做好坐标归一化：先算包围盒，然后把所有坐标平移，让图形最小点落在原点附近。这样不仅 SVG 里数字更干净，后续做自动化测量时也不容易出错。

单位换算也在这里一并解决。DXF 本身不携带"1单位等于多少毫米"的强制信息，它只是一个逻辑坐标。通常企业约定俗成是 1 单位=1mm，但也有用 mil 出图的部门。转换工具里我做了可配置的单位选项：

• 如果源图纸是毫米，输出 SVG 时 viewBox 就是原始数值，width 按屏幕像素比例设置
• 如果源图纸是 mil，先乘以 0.0254 转成毫米再进 viewBox，这样后续所有测量都统一到公制

统一单位后，评审系统里就能实现"点击 SVG 上的两点，直接读出实际距离"的功能，这是位图方案永远做不到的。

5.4 大型版图的性能对策

芯片基板、引线框架这类图形的线条数量经常几万条起步，转换出的 SVG 可能到 5MB、10MB。直接插进 TinyMCE，编辑和保存都会卡，浏览器渲染时帧率直线下降。

我的压测结论放在一张表里：

实战中对大型图纸我有两个推荐做法。第一是分层切片：把 TOP、BOTTOM、SILKSCREEN 分别转成独立 SVG，文档里贴三个小图，而不是贴一整张"全家福"。评审时按需看层，性能压力小得多。第二是抽稀简化：单纯看大概布局时，把圆弧和样条线抽稀成多边形，肉眼几乎无感，文件体积能压缩一半以上。

6. 整体流程整理与落地体会

把前面的方案串成一整条流水线，我们最终在内部实现的流程是这样的：

1. 设计部门输出统一的 DXF/DWG 原始图纸，约定图层命名和单位（毫米）
2. 转换服务定时扫描图纸目录，普通图纸走链路 A（PDF 中转），需要筛选图层的走链路 B（ezdxf 解析）
3. 转换脚本输出规范化的 SVG 文件：包含明确 viewBox 与 width、统一图层颜色、坐标归一化、文字转路径
4. 小尺寸 SVG 以 DataURL 插入 TinyMCE，大尺寸 SVG 上传文件服务器后以 URL 插入
5. TinyMCE 工具栏提供"插入 SVG 图纸"按钮，粘贴拦截逻辑兜底处理复制文件的情况
6. 保存后在前端做一次渲染校验，确保 SVG 能正常显示、尺寸比例无异常

这里特别想提醒一件事：CAD 加密插件在转换链路上是个隐形杀手。企业内部为了保护图纸往往会装各种加密插件，这种加密后的 DWG 文件用任何第三方库都读不出来，转出来是一片空白。我们踩过一次这个坑，排查了半天最后发现是安全部门在客户端装的加密工具把文件挡住了。解决办法是冲突隔离：转换服务器上只放解密后的受控文件，转换完成后的 SVG 进入文档系统后，靠访问权限控制来保证安全，而不是靠文件本身加密。

如果让我重来一遍，我会在动 TinyMCE 之前先花时间统一全公司的图纸输出规范——图层命名、单位、字体、打印样式，一次性定好。工具层面相反是最省事的环节，PDF 转 SVG、ezdxf 解析这些方案都非常成熟，真正的成本在输入数据的规范性上。现在这套流程跑下来，工艺评审文档里贴图从"看不清"变成了"随便放大"，后续还可以继续扩展自动标注、距离量测、图层显隐切换这些功能，SVG 作为中间格式给这些自动化工具留足了空间。