1. 从“粘贴一篇工艺文档”说起CAD图纸进TinyMCE的真实困境芯片制造企业的知识管理平台、工艺文档系统、内部Wiki里每天都有大量的作业指导书、流程规范、异常分析报告在流转。这些文档有一个共同的硬需求把CAD图纸贴进去而且不是贴一张能看的图是贴一张能放大、能看清细节、能追溯设计信息的矢量图。早期我们内部用的方案很粗暴让工程师把CAD里的图框选、CtrlC然后切到系统页面里CtrlV。浏览器默认行为下TinyMCE会把剪贴板里的CAD内容转成PNG位图插入。这听起来没什么问题直到你真正面对一张28nm工艺节点的版图切片。位图一旦放大焊盘边缘全是锯齿走线的间距根本量不准更别提图层信息、尺寸标注、器件坐标这些关键数据全部丢失。芯片文档不是PPT图里每个pin脚的位置、每条走线的宽度都可能被下游产线拿去核对你给一张模糊位图等于让操作工带着马赛克上岗。真正的痛点还有一层CAD图纸本身是矢量数据DWG或DXF格式里保存的是坐标、图层、线型、文本、标注。把这些信息塞进HTML文档里主流浏览器和富文本编辑器原生都不认。TinyMCE虽然把图片粘贴、拖拽、上传都做得挺成熟但它的“图片”认知就是位图资源不会平白无故去解析DXF。所以要做这件事本质上不是“粘贴”功能的改进而是要在CAD端和TinyMCE端之间架一条能够保留矢量语义的管道。我当时评估过几条路让TinyMCE直接支持DWG预览浏览器端装WebGL查看器或者把图纸切成瓦片试了一圈都有硬伤。DWG是Autodesk的私有二进制格式浏览器端解析要么引一个巨大的WASM库要么走后端转换实时性很差。WebGL查看器交互是爽但它那套渲染窗口和TinyMCE DOM是两套体系你没法把“图”作为一个合法内容片段存进文档里更没法在文档列表里做全文检索。瓦片方案倒是能解决预览性能但本质上还是图片矢量输出这个目标就实现不了。最后落地的方案是围绕SVG做文章。CAD图纸在编辑端被解析成实体数据经过坐标归一化、图层筛选后生成SVG内容写入TinyMCE。SVG本身就是W3C标准的矢量格式浏览器原生支持能被TinyMCE的DOM当成普通HTML节点处理能缩放、能检索、能局部高亮还能挂自定义数据属性。这个方案走通后我们不只解决了“粘贴”的问题还顺手把图纸版本对比、Pin脚检索、缺陷标注这些原本要单独开发的功能全部在SVG上复用了。说句实在话这个需求的难度不在SVG本身SVG生成、渲染、嵌入都是成熟技术。难的是把CAD那套坐标体系、图层逻辑、文本样式妥帖地翻译成SVG能表达的东西并且在TinyMCE的内容模型里不冲突、不逃逸、不卡顿。整个过程踩了不少坑下面把设计思路、关键实现和改造过程中的教训一并写出来。2. 架构设计与格式选型SVG才是CAD与TinyMCE之间最短的那座桥2.1 三条候选路线的对比最开始评审过三个方案位图粘贴增强、内嵌专用查看器、SVG转写。三条路线的成本和收益完全不同。位图粘贴增强是改动最小的方案工程师粘贴时拦截剪贴板把CAD数据转成高分辨率PNG默认按300dpi渲染。这个方案唯一的好处是开发量小缺点是治标不治本。高分辨率位图能稍微缓解模糊问题但文件体积飙升一张A3幅面的版图按300dpi转出来随便就是20MB以上文档库里存几十篇这样的文章存储和加载都受不了。更关键的是位图丢失了所有设计语义后续做图纸差异对比、Pin脚定位这些需求全部无从谈起等于一次短视的技术负债。内嵌专用查看器是另一条路比如在TinyMCE里嵌一个Canvas渲染器用WebSocket连后端后端实时解析DXF传图元数据。交互体验确实好能做到类似CAD软件的缩放和平移但有几个绕不开的麻烦第一TinyMCE的内容模型不认识这种自定义交互组件保存时要么转成图片要么存一段特殊标记之后编辑、复制、粘贴都会遇到问题第二查看器需要独立消息通道和文档系统本身的保存、审批、版本管理流程很难打通第三性能开销大每个打开文档的人都要建立一个渲染会话对服务器压力不小。SVG转写方案是在“保留语义”和“实现复杂度”之间最均衡的选择。SVG是文本格式本身就活在HTML的世界里TinyMCE可以直接把它当作内容节点来存储、渲染、编辑。它既能表达矢量图形又能携带元数据比如把图层名、实体句柄、坐标范围写进自定义data属性后续做交互就有抓手。而且SVG不用依赖任何专用渲染服务浏览器原生绘制用户打开文档没有额外等待。2.2 SVG方案在芯片场景里的具体价值选定SVG后我在内部评审会上列过三条芯片场景特有的理由第一精度和缩放。版图设计最小的线宽可以到几十纳米级别虽然屏幕分辨率显示不了那么细但SVG的坐标精度是浮点数路径数据在语义上保留了原始设计精度。工程师在浏览器里放大到极限看到的虽然受限于屏幕像素但图形元素之间的几何关系不会被二次压缩破坏。这是位图永远给不了的保证。第二图案与元数据的检索。芯片文档里经常要问“这个物料用到哪些Pin”“这颗电容放在哪个坐标”。如果是位图你必须人工肉眼去找如果SVG里挂了data-pin、data-net、data-x、data-y这些属性前端脚本就能直接检索定位还能批量高亮。这套能力后来直接支撑了“Pin脚导航”功能——点一下文档目录里的引脚名图上自动把对应焊盘描红。第三图纸变更对比。我们在SVG元素上保留了实体的唯一标识符句柄新粘贴一次图纸生成新的SVG后前端可以按句柄做diff把新增、删除、移动的实体用不同颜色标出来。工艺工程师审阅新版图纸时一眼就能看出哪里改了。这个功能在之前位图方案下是不敢想的。2.3 整体架构三段式管道最终架构分三段。CAD端是一个基于AutoCAD .NET API开发的插件工程师选中图纸里要分享的实体区域后点一个“复制到文档平台”按钮插件把所有选中的实体数据抽出来包括几何坐标、图层名、线型、颜色、文字内容。然后这些数据分两部分走一部分序列化成JSON另一部分把原始DXF实体数据整包压缩一起提交给后端的转换服务。后端转换服务用Python写接收CAD端推来的数据包后做三件事第一用ezdxf重新解析DXF实体第二做坐标系归一化把图纸里可能达到十亿纳米级别的绝对坐标转换成一个相对坐标范围同时保留一个偏移量引用第三按预设的图层白名单过滤只导出档控层、标注层、装配层这些生产需要的图层过滤掉辅助线、参考网格之类的冗余内容。最终输出SVG字符串。TinyMCE侧是一个自定义扩展插件。它注册了一个额外按钮和一个onPaste拦截处理。工程师点击按钮后打开侧边面板可以看到从剪贴板读取到的CAD实体摘要确认无误后点击插入插件把SVG字符串安全清洗后写入编辑器光标位置。整个过程走内部接口不走浏览器默认的图片粘贴路径。这套三段式管道的好处是每一段都能独立优化。CAD端负责数据抽取不关心前端怎么渲染转换服务负责语义翻译面向的是纯数据编辑器插件只负责把SVG安全地放进文档。哪一段出问题都能单独定位、单独升级。3. 在CAD端实现“一键复制”坐标系归零与实体提取3.1 CAD侧工具的工作流程CAD端插件我们命名为“图纸采集器”最早用AutoCAD .NET API 写跑在工程师的Windows工作站上。为了让工艺工程师使用门槛降到最低交互流程设计成一个非模态面板用户在CAD里框选要分享的区域面板上自动列出当前选中实体的数量、包含的图层列表以及整块区域的XY范围。工程师按一下“采集并提交”后面的事就全自动。采集动作的核心是遍历SelectionSet。AutoCAD .NET API 里Editor.SelectAll() 或者框选返回一组ObjectId插件逐个取出DBObject再按类型分流。直线、多段线、圆弧、圆这种是基础几何实体文本、多行文本是文字实体尺寸标注是复杂实体内部包含标注线、延伸线、箭头和标注文字需要递归遍历组件对象。每类实体都要转成一个统一的中间结构我把它叫做“图形基元”。不同实体的转换有个容易搞错的点多段线里可能扛着凸度bulge弧线用普通多义线存储如果只取顶点坐标圆弧段全部丢失生成SVG会变成折线在版图里看R角非常明显。所以插件里对多段线做逐段判断遇到凸度非零的段就用顶点坐标和凸度计算圆弧的起点、终点、圆心和弧度转换成SVG的A指令。这一步做不好图纸导出的几何精度就是废的。3.2 坐标系归一化十亿纳米坐标的坑芯片版图的坐标系是真实设备坐标数字大得吓人。一个Die的坐标范围动辄几百万微米转成纳米就是十几次方的量级。SVG的viewBox倒是能接受大数字但浮点精度在这种量级下会悄悄出问题尤其是旋转、缩放之后微小偏差叠加可能让图形对不上。所以采集端必须做坐标归零。具体做法是框选后取所有实体的包围盒记下minX、minY然后构造一个平移矩阵Translate(-minX, -minY)对所有实体坐标做变换。实际传给转换服务的坐标偏移信息里额外保存原始坐标系里的原点参考值方便后续跟其他设计工具对齐。归零操作在CAD端做还是转换服务做我建议在CAD端做。原因有两个一是CAD端是数据源头在这个阶段做一次平移所有实体统一处理逻辑最干净二是在转换服务里做需要先完整解析DXF才能算包围盒多一次全量解析对大型图纸的耗时和内存都不友好。CAD端在遍历实体时就能顺手把包围盒算出来几乎是零成本。3.3 过滤冗余图层与实体筛选芯片图纸一个典型的特征就是图层非常多除了有效的设计层还有大量辅助层、网格层、批注层。全部带出去SVG文件会膨胀到几十MB编辑器直接卡死。采集端因此内置一套图层白名单默认开启档控层、金属层、焊盘层、标注层、组装层、禁布层。工程师可以在面板上临时切换勾掉不想要的图层但白名单之外的图层默认不会导出。除了图层还有一类实体需要特殊处理光栅图像。很多版图里嵌了参考照片或者扫描图这类实体是位图导出成矢量没有意义插件选择默认跳过只记录一个占位标记。在SVG输出里对应一个带说明文字的方框工程师看到后会知道原图里此处有参考图但矢量部分不包含。文本实体的处理同样有讲究。芯片版图里的文本分两类一类是真正的标注比如引脚名、位号、坐标标记必须完整输出另一类是批注、临时说明是设计人员随手打的字跟生产材料无关按图层过滤规则处理。如果图层保留文本就一并保留而且文本样式字体、字高、旋转角会写进SVG的font-family、font-size、transform属性里。3.4 为什么跨出一大步校验文件与人工确认CAD端采集完成后会生成一个压缩包提交给后端。压缩包里包含序列化的图形基元JSON、原始DXF子集只含选中实体、以及一个校验文件。校验文件的格式很轻量只有图层名列表、实体数、包围盒范围、以及所有文本内容的散列值。校验文件的用途是在后端转换完成后做一次“输入-输出一致性校验”。转换服务生成的SVG里应该包含相同数量的实体和相同集合的文本如果比对不通过说明转换过程中有实体丢失后端直接返回错误要求重新采集。这个机制在初期调试时救了很多次因为DXF规范太庞大了总有解析器覆盖不到的实体类型。有了校验链路问题能立刻暴露而不是悄悄生成一张缺东西的图。工程师端的“人工确认”环节也保留着。提交前面板上会显示实体统计如果数量明显不对比如框选了一整层但实体数只有几十个工程师可以取消重新框选。这个看似多余的步骤其实挡住了很多“选了空图层”“没框到目标”的低级错误。4. TinyMCE侧如何“接住”矢量图自定义插件与SVG嵌入4.1 编辑器插件的功能范围TinyMCE这一步要解决的不是“生成SVG”而是“把SVG以合法、安全、可再编辑的方式放进文档里”。它分成三个部分工具栏按钮、粘贴拦截、SVG解析与写入。按钮注册在TinyMCE的工具栏上点击后弹出一个dockable侧边面板。面板里调用后端的“待插入图纸”接口列出当前剪贴板关联的CAD采集任务展示实体数量、范围、缩略SVG预览。工程师确认后点“插入”插件把SVG字符串交给内部处理器处理器做两件事安全清洗和内容包装。清洗环节删除所有script、事件属性、外部引用内容包装则把svg根节点加上一个包裹div赋予class名和data-diagram-id属性。粘贴拦截是另一个入口。工程师从CAD里复制图形后可能直接CtrlV到编辑器里。浏览器剪贴板上没有TinyMCE默认认识的位图数据TinyMCE多半会忽略或者粘出一堆无意义内容。插件注册了paste事件分析剪贴板的CAD私有格式标识如果能匹配合法的CAD采集任务就阻断默认粘贴行为转去调用同一套后台处理逻辑。这样工程师既可以走按钮流程也可以直接CtrlV反正最终都是规范的SVG入库。4.2 从压缩包到SVG后端转换服务的设计后端转换服务是整套管道里技术密度最高的一段。它接收CAD端提交的压缩包后第一件事是解压并按校验文件核对实体完整性然后用ezdxf库载入DXF子集遍历ModelSpace里的所有实体。解析DXF实体时最需要用心的是实体到SVG命令的映射。直线映射成M x y L x y圆映射成三个贝塞尔弧段SVG没有原生圆指令其实有circle但芯片版图里很多圆是从DXF的ARC转换来的统一用path表示更一致多段线逐顶点转成折线或者带弧段的复合路径文本转成text节点尺寸标注递归拆成线、箭头、文本三部分。映射规则跑通后路径优化就可以做了把相邻共线线段合并减少SVG节点数量。图层信息在SVG里怎么保留我采用了一个比较土但非常有效的办法每个图元对应的SVG子元素套一层标签的id设置成layername-xxxstyle里设置该图层的默认颜色和线宽。这样后续CSS可以针对图层统一调整样式比如隐藏辅助层、把标注层的颜色加深。前端diff功能也依赖这些分组的id。坐标归一化在转换服务还会做第二次。虽然CAD端已经做过归零但转换服务拿到的是原始DXF里面坐标仍然是绝对坐标。所以转换服务要重新算包围盒、重新平移。为什么不在CAD端直接生成SVG因为AutoCAD环境里生成SVG要依赖操作系统的图形库输出控制不灵活而用ezdxf在后端解析所有转换逻辑都集中在服务器上CAD端只是一个采集器后续支持DWG格式升级也更容易不用动所有客户端。4.3 SVG内容安全处理不干净的东西不能进DOMSVG最大的安全隐患是脚本注入。一个恶意构造的SVG可以包含script节点、onload属性、外部链接引用。如果直接插入TinyMCE的DOM并保存轻则内容被篡改重则XSS攻击整个文档系统。安全清洗的策略是“白名单重建”。简单说不用“删除危险内容”的黑名单思路因为总有漏网的属性。而是先解析SVG字符串为DOM树然后只允许保留一份白名单标签集合svg、g、path、circle、line、rect、polyline、polygon、text、tspan、defs、use。属性白名单包括d、points、x、y、x1、y1、x2、y2、cx、cy、r、fill、stroke、stroke-width、transform、viewBox、font-family、font-size、text-anchor。白名单之外的一个不留。为了保险清洗后的DOM再序列化成字符串时我们统一用新生成的序列化器不直接保留原字符串。这样任何藏在字符串里的编码绕过、注释逃逸、CDATA包夹都会被破坏掉。清洗后的SVG再经一次XML解析验证如果解析失败说明内容有问题直接拒绝插入并提示错误。还有一层保护是CSP内容安全策略。TinyMCE所在的页面配置了script-src为自建域名不允许inline script。这样即使SVG里混入了脚本浏览器也不会执行。三层防护下来SVG就跟普通HTML一样安全了。这套逻辑虽然比直接insertContent多一点代码但值得花时间写好因为它面向的是全公司几千人共用的文档库。4.4 两个印象深刻的坑XML转义与字体缺失第一个坑是XML转义。芯片版图里文本内容经常出现“5um”“10±0.5”这类特殊字符。DXF解析出来的字符串直接塞进SVG的text节点如果里面带着序列化时XML解析直接报错。这个问题其实很基础但团队里最早写的转换脚本没做统一转义结果一批图纸的标注文字在生成SVG时静默丢失——代码里错误处理直接把含非法字符的文本节点跳过了。后来改成所有文本内容先做XML实体转义再写入SVG问题才根治。第二个坑是字体缺失。CAD图纸里常见字体是AutoCAD自带的SHX字形比如SimSun、HZPLOT。这些字体在浏览器里不一定存在尤其是SVG在服务端生成、前端浏览器渲染的环境里Linux服务器上没有中文字体渲染出来的标注文字全变成了方块。后来摸索出的解决方案是转换服务会把SHX字形里的文本信息提取出来转成一个标准的font-family声明列表优先用网页中文字体比如“Microsoft YaHei”“PingFang SC”实在不行用通用sans-serif兜底。另外文字角度也需要注意CAD里文字有旋转属性SVG的text需要包一层带rotate的transform否则所有标注文字都变成水平排列方向信息就没了。5. 验证、性能与安全大图纸在编辑器里也能流畅滚动5.1 一份典型切片图纸的实测数据方案上线后我们拿生产环境里一份典型的版图切片做了压测。这份图纸大概包含12万个实体其中多数是短线段和小圆弧图层32个。采集端生成的压缩包约8MB后端转换服务处理耗时约4秒生成的SVG字符串约5MB。5MB的SVG直接塞进TinyMCE编辑器的滚动跟帧率只有个位数基本没法用。这个结果提醒我们不能把一次性生成的大SVG直接当文档内容用必须做分层和按需渲染。优化思路分成两块。第一块是SVG层级的简化。转换服务增加了路径合并算法把同图层内相邻且共线的短线段合并成一条长线段。对于芯片版图这类“由大量网格状短线段组成”的场景路径合并能把节点数量砍掉一半以上。第二块是懒加载。编辑器初始化时SVG先渲染成一张自定义的交互占位块只显示一个灰色的图形轮廓和一个“点击加载完整矢量图”的按钮。只有工程师点击占位块前端才通过代理方式请求真正的SVG内容插入到占位块目标位置。这样文档列表、编辑模式都不卡真正的矢量图只有在需要细看时才会载入。5.2 前端渲染优化viewBox与粒度控制即使做了懒加载单次加载5MB的SVG依然不是个轻松活。前端渲染要做两件优化viewBox裁剪和节点池化。viewBox裁剪的意思是SVG里一次性绘制全部12万个实体确实没必要因为一张图在屏幕上最多显示屏幕范围内的部分。我们给SVG的viewBox设定为图纸的实际坐标范围同时在前端监听滚动缩放事件动态调整viewBox的minX、minY、width、height让浏览器只渲染可视区域内的图形。这里要注意的是SVG并没有真正的“裁切渲染”它还是会解析全部DOM节点但对浏览器而言不可见区域内的绘制工作会被跳过帧率能提高非常多。尤其适合芯片版图这类有大量密集短线的场景。节点池化则是一个更彻底的优化只适合数据量极大的场景后端转换服务在生成SVG时把12万个实体按2D网格分片每个网格一个分组。前端初始化时只实例化viewport周边9个网格的节点其余网格的数据存放在JS对象里滚动到哪个网格就动态把那块网格的节点挂进SVG DOM。这套实现稍微复杂但最终效果很理想即使载入一份30MB的超大图纸编辑器内的滚动也能保持30fps以上这已经满足日常查看和标注的需求了。5.3 保存策略与权限控制文档保存时TinyMCE内容里包含的是完整的SVG文本。这个文本可能有几MB直接塞进数据库的TEXT字段可行但后续更新、检索都麻烦。更稳妥的方案是SVG本体存到对象存储服务里数据库中只存SVG的引用IDTinyMCE内容里保留一个占位div。技术实现上保存时插件会把SVG抽取出来上传然后把SVG内容替换成占位div的HTML读取时再反向替换。这样文档库的主表不会因为图纸变大而膨胀全文索引也不用碰超大文本。权限控制也是必须考虑的问题。芯片厂的图纸是有密级的不同项目、不同层级的员工能查看的内容不一样。SVG里如果包含了完整的内部设计信息绝不能允许任何人通过浏览器右键“查看源代码”就把图纸全文拷走。我们为此做了一个轻量方案在SVG根节点上加data-access-level属性前端监听鼠标右键和选择事件如果当前用户的权限级别低于data-access-level右键菜单里的“复制”“查看源码”选项一律禁用并且SVG不允许被框选复制。虽然这个方案防不了真正精通技术的高手但已经能阻止绝大多数普通的误操作和信息泄露。5.4 审批链路的补充说明图纸发到工艺文档系统里不能像普通文章一样随手发布。我们额外接了一条审批流贴入SVG后文档必须提交给版图工程师或部门主管审批审批页面用上面说的“版本对比”功能展示新增、删除和移动的实体审批人在对比图上直接批准或打回。这套流程补上之后才真正符合芯片制造企业的质量追溯要求。审批通过后文档里的SVG进入只读状态。后续任何人再打开编辑SVG被当成一个整体对象处理不能从中间拆开改几个节点。要改图纸工程师必须回到CAD源文件里去改再重新粘贴生成新版SVG这保证了文档内容和设计数据始终能够通过版本号关联起来。这个决策当时有同事觉得太死板但目前看反而是支撑追溯体系的关键设计。6. 这套方案踩过坑之后的复盘与可复用性6.1 踩坑清单如果有人再走一遍这几点能省一周第一CAD端不要试图把SVG直接生成好。最开始我们尝试过在AutoCAD里装一个导出插件直接生成SVG字符串提交后端省去DXF解析环节。听起来更短但实际踩了大坑AutoCAD .NET的图形输出API在特定的显卡驱动环境下会渲染异常导致线条缺失排查非常困难。后来改成只采集实体数据后端统一用ezdxf解析问题彻底消失因为后端不依赖具体的AutoCAD显示环境。第二TinyMCE的content filtering要提前配好。TinyMCE默认配置下插入SVG的某些标签会被过滤因为默认的valid_elements里不包含svg这些节点。如果不在init配置里扩展valid_elementsSVG会被完全剥掉或者残缺。这是一个很容易被忽略的配置项尤其在TinyMCE升级后默认策略收紧时插件的SVG会突然全部失效。第三大SVG的序列化与保存一定要单独处理。如果你直接把几MB的SVG字符串塞进TinyMCE内容并调用getContent()编辑器的序列化器会非常吃力实测一段5MB内容序列化耗时可能超过8秒用户直接以为页面卡死。所以线上保存必须是“提交时抽取SVG”的机制TinyMCE内容里平时只放占位div。第四图层颜色别直接在SVG里写死。CAD图纸里图层的颜色规则是全公司统一的比如走线层是绿色、标注层是黄色。但SVG在网页里展示时背景通常是白色CAD里那些深色背景下的颜色体系会变得刺眼。所以我们把颜色映射放在转换服务端做以一张公司认可的配色表为准而不是直接拿CAD的AutoCAD颜色索引ACI值硬填。这个映射规则要跟设计部门确认不能拍脑袋定。6.2 可以平移到其他领域的部分这套方案虽然出发点是为芯片制造企业服务但它的骨架是可以抽出来的一套面向“专业设计软件”与“Web富文本”之间的矢量数据桥接管道。机械制造行业的BOM文档、装配工艺卡逻辑完全一致换一个行业只需调整CAD端的实体类型映射和图层规则。没有DWG图纸、只有Gerber文件的PCB厂商也一样能用后端把Gerber解析成图元生成SVG然后走同样的TinyMCE插件管线。再往前一步EDA原理图、建筑BIM模型导出的矢量数据都可以用“采集器转换服务编辑器插件”的结构接入。核心可复用的是三块设计一是“坐标归零图层白名单”的数据预处理思路它保证数据源干净二是“SVG白名单重建”的安全清洗方案它保证Web环境可用三是“占位div懒加载节点池化”的前端性能策略它保证大图纸不拖垮编辑器。这三块跟具体CAD产品解耦换任何矢量格式都适用。6.3 还能往哪些方向扩展目前这套管道主要还是服务于“人工粘贴图纸”这个高频场景。往长远看有几个方向值得做。一个是与设计数据管理系统的对接。如果图纸的最终解释权在PDM/PLM系统里那么文档平台里的SVG应该能反查到源文件的版本号。我们正在做的一个扩展是在SVG根节点上增加data-source-url属性点击占位块上的“打开源文件”按钮文案会跳到PDM系统的对应物料和版本页。这能极大缩短“文档与设计不一致”的追溯时间。另一个是自动生成工艺关联属性。既然SVG里已经有实体句柄和图层信息前端可以做一套规则引擎比如检测到特定图层的特定图形组合自动标记为“焊接点”或“测试点”然后在文档里生成结构化清单。这个功能一旦做成文档系统就算有了初步的“图纸数据抽取”能力不再是单纯的图文展示工具。最后一个值得做的是跨文档引用。我们的SVG实体都带唯一ID当两篇文档引用同一份图纸的不同区域时系统可以自动检查两张图的实际内容是否有冲突。比如一份工艺文件说明了装配方法另一份质量文件描述了同一焊盘的检测标准如果底层实体有变动两份文档能同时收到变更通知。这就是把“图”从文档里拎出来做了关联价值远超单纯的“粘贴”功能。从我个人的经验看这种改造项目最怕的不是技术难点而是“差不多能用”的心态。用位图确实也能撑一个季度但芯片制造对数据的精确性和可追溯性要求极高今天省下的开发工作量迟早会变成明天的返工工时。把CAD图纸以矢量形式完整地接进Web文档系统这条路虽然绕了一点但长期来看是唯一不用返工的正确方向。