1. 从“粘贴一篇工艺文档”说起：CAD图纸进TinyMCE的真实困境
芯片制造企业的知识管理平台、工艺文档系统、内部Wiki里，每天都有大量的作业指导书、流程规范、异常分析报告在流转。这些文档有一个共同的硬需求：把CAD图纸贴进去，而且不是贴一张能看的图，是贴一张能放大、能看清细节、能追溯设计信息的矢量图。
早期我们内部用的方案很粗暴：让工程师把CAD里的图框选、Ctrl+C，然后切到系统页面里Ctrl+V。浏览器默认行为下，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里复制图形后，可能直接Ctrl+V到编辑器里。浏览器剪贴板上没有TinyMCE默认认识的位图数据，TinyMCE多半会忽略，或者粘出一堆无意义内容。插件注册了paste事件，分析剪贴板的CAD私有格式标识，如果能匹配合法的CAD采集任务，就阻断默认粘贴行为，转去调用同一套后台处理逻辑。这样工程师既可以走按钮流程，也可以直接Ctrl+V，反正最终都是规范的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子元素，套一层
坐标归一化在转换服务还会做第二次。虽然CAD端已经做过归零，但转换服务拿到的是原始DXF，里面坐标仍然是绝对坐标。所以转换服务要重新算包围盒、重新平移。为什么不在CAD端直接生成SVG？因为AutoCAD环境里生成SVG要依赖操作系统的图形库，输出控制不灵活，而用ezdxf在后端解析，所有转换逻辑都集中在服务器上，CAD端只是一个采集器，后续支持DWG格式升级也更容易，不用动所有客户端。
4.3 SVG内容安全处理：不干净的东西不能进DOM
SVG最大的安全隐患是脚本注入。一个恶意构造的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网格分片，每个网格一个
5.3 保存策略与权限控制
文档保存时，TinyMCE内容里包含的是完整的SVG文本。这个文本可能有几MB，直接塞进数据库的TEXT字段可行，但后续更新、检索都麻烦。更稳妥的方案是：SVG本体存到对象存储服务里，数据库中只存SVG的引用ID，TinyMCE内容里保留一个占位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_elements，SVG会被完全剥掉或者残缺。这是一个很容易被忽略的配置项，尤其在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文档系统，这条路虽然绕了一点，但长期来看是唯一不用返工的正确方向。
