KindEditor文档中CAD图纸批量提取与转存全流程指南

芯片制造文档用KindEditor排版，工程师习惯了把CAD图纸截图贴进正文，或者把dwg文件作为附件挂到文章里。等到质量体系要统一收口图纸、或者新产线建设需要把工艺文件里的设备布局图、治具图全部迁移到工程图库时，麻烦一下就上来了：一个几千字的芯片制造文档正文里，图纸链接和CAD附件会被富文本编辑器处理成各种各样的格式，靠人工打开文档、右键图片另存、再在CAD里重画，效率完全没法看。

这篇内容就把我实际走过的一条链路完整分享出来：从KindEditor生成的HTML正文里把CAD图纸识别出来、批量下载，再按图片类图纸和DWG/DXF文件类图纸分别转存。整个过程不需要改系统，不需要开发特权，纯粹靠导出正文和几个脚本就能跑完。另外，针对很多人问到的“新装CAD打开图纸会很多线”，我也会把排查经验一并整理出来，因为图纸转存后第一步验证就是打开看，这个坑不解决，后面全是浪费时间。

1. 先搞清楚一件事：KindEditor里的“图纸”到底以什么形态存在

1.1 一个让我下决心写脚本的现场

之前接到一个活儿：某条封装产线的SOP文档要全部换版，旧文档里有将近3000张设备治具图、贴片坐标图、局部放大图需要迁移到工程图库服务器。文档系统本身是基于Java那套常见的自研CMS做的，正文编辑器就是KindEditor。我最初的方法很笨，登录后台打开一篇文档，找到里面的图片，鼠标右键“图片另存为”，遇到dwg附件还要先下载到本地再用CAD打开另存。第一天干了四个小时，处理了不到30篇，照这个速度，3000张图纸得干到明年去。

后来我切到后台数据库看了一眼表结构，发现KindEditor其实并没有把图纸本身存成什么特殊格式，它就是在content字段里存了一段HTML。那些看起来规规矩矩排在正文里的图纸，无非就是img标签、a标签或者内嵌的base64数据。图纸能不能被自动化转存，关键不是KindEditor这个编辑器怎么操作，而是你有没有办法把一整段HTML内容拿出来做结构化解析。

1.2 KindEditor正文里图纸的三种常见形态

我把经历过的文档系统翻了一遍，KindEditor里保存的图纸资源基本只有下面这三种形态，判断方法很简单，直接看HTML源码就行。

第一种，是上传后插入的图片，也就是img标签。KindEditor上传图片后，默认会在正文里生成一段类似<img src="/uploadfile/2024/0901/xxx.png" style="width: 600px; height: 400px;">的代码。这种图占了绝大多数，芯片制造文档里的工艺截图、显微镜照片、设备面板指示图基本都是这个格式。只要能从src属性里拿到图片的URL，下载就完成了百分之八十。

第二种，是作为附件插入的CAD原始文件。很多工程师会在KindEditor工具栏里点“插入附件”，然后把dwg或dxf上传上去。这种情况下正文里通常是一个a标签，比如<a href="/uploadfile/2024/0901/xxx.dwg" target="_blank">治具图纸下载</a>。判断标准就是href里带有.dwg、.dxf这类后缀。这种附件是真正的CAD可编辑文件，也是最需要优先转存的对象。

第三种，是直接粘贴进来的截图。这种情况最隐蔽，工程师从CAD里复制一个区域，粘贴到KindEditor正文里，如果编辑器配置了base64存储，content里会出现<img src="data:image/png;base64,iVBORw0K...">这么一长串字符串。这类图片并没有真正上传到服务器目录，它们只是躺在了数据库字段里。后面转存时，需要用正则把base64内容单独解码出来写成本地文件，不能像前两种那样直接按URL下载。

1.3 判断哪些图值得“转存”

不是所有从正文里抠出来的图片都有必要转成CAD格式。我在第一轮批量处理时就犯过这个错，把公司Logo、表格截图、人员签名扫图全部当成图纸下载下来，结果图库目录里堆了一堆无意义的文件。

后来我定了一套分类规则，根据扩展名和插入上下文来判断：

关键点在于：KindEditor只是个网页编辑器，它没有解析DWG或者DXF的能力。你在KindEditor的编辑框里看到一张图，不代表那是一个CAD文件，它可能只是位图预览。所谓“快速转存CAD图纸”，在绝大多数企业系统里的真实语义是：把文档中引用的CAD资源完整抠出来，再按图纸类型做下一步处理。

2. 把文档正文从系统里“端出来”：导出HTML的方式决定了自动化能不能跑通

2.1 先确认正文存在哪个字段，导出时注意编码

KindEditor整合进不同系统后，正文内容可能存放在不同的地方。有的是单独的文章表content字段，有的是放在流程表单的某个字段里，还有的是直接存成了HTML文件。我建议先在后台数据库里做一次侦查，找到你目标文档所在的数据表，把一条记录完整SELECT出来看。

以常见的文档表结构为例，可以这样查询：

sql复制SELECT id, doc_no, title, content 
FROM cms_article 
WHERE module = 'chip_process' 
  AND title LIKE '%治具%'
LIMIT 50;

最关键的是编码问题。数据库连接要显式加上UTF-8字符集参数，不然中文文档标题导出到本地后，在脚本里打开会出现乱码。如果是从MySQL导出的，执行SQL前先设置：

sql复制SET NAMES utf8mb4;

导出到本地文件时，我习惯直接让SQL客户端把结果存成.sql或.csv文件，但CSV方案很容易踩坑：Excel默认打开CSV会按GBK转码，正文里的中文和特殊字符会乱掉。最稳妥的方法，是让后端提供一个只读接口，按文章ID循环把content字段返回到文件里，每一篇单独存一个html文件，文件名就可以直接用doc_no。没有开发接口权限的话，也可以到文档管理后台找到某篇文章的“HTML源码”按钮，复制整段HTML，粘贴到本地文本文件保存。虽然笨一点，但语法结构完全一致，后面的脚本完全不受影响。

2.2 用脚本从HTML里找出全部图纸资源

拿到了HTML正文，下一步就是把里面的资源地址全部提取出来。这里我用的是一套很常规的解析组合：Python的BeautifulSoup负责结构化解析HTML，再用正则把一些非标准的写法捞干净。

下面这段脚本可以一次性把img的src、a标签的href、还有base64字符串全部收集出来：

python复制import re
import os
import json
from urllib.parse import urlparse, urljoin
from bs4 import BeautifulSoup

def extract_resources(html_content, base_url):
    resources = {
        'images': [],      # 普通图片
        'attachments': [], # dwg/dxf/pdf等附件
        'base64_images': [] # 内嵌base64图片
    }
    
    soup = BeautifulSoup(html_content, 'html.parser')
    
    # 处理img标签
    for img in soup.find_all('img'):
        src = img.get('src')
        if not src:
            continue
        if src.startswith('data:image'):
            resources['base64_images'].append(src)
        else:
            resources['images'].append(urljoin(base_url, src))
    
    # 处理a标签附件
    for a in soup.find_all('a'):
        href = a.get('href')
        if not href:
            continue
        if re.search(r'\.(dwg|dxf|pdf)$', href, re.I):
            resources['attachments'].append(urljoin(base_url, href))
    
    # 兜底：正文里可能有不标准写法，比如直接把图片地址写在文本里
    raw_urls = re.findall(r'(?:src|href)="([^"]+\.(?:png|jpg|jpeg|gif|dwg|dxf|pdf))"', html_content, re.I)
    for url in raw_urls:
        if url.startswith('data:'):
            continue
        full_url = urljoin(base_url, url)
        if full_url not in resources['images'] and full_url not in resources['attachments']:
            if re.search(r'\.(png|jpg|jpeg|gif)$', full_url, re.I):
                resources['images'].append(full_url)
            else:
                resources['attachments'].append(full_url)

    return resources

# 使用示例
with open('ASM_20240831_001.html', 'r', encoding='utf-8') as f:
    content = f.read()
res = extract_resources(content, base_url='http://doc.internal.test')
print(json.dumps(res, ensure_ascii=False, indent=2))

解析逻辑本身不难，但有一点值得单独强调：kindeditor在上传图片后给img标签加的style里可能包含了缩放尺寸，而原图URL是完整的。所以不要被style属性里的width: 300px迷惑，把src完整提取出来，下载到的就是上传时的原图分辨率，不会被宽高属性影响。

2.3 相对路径与站点URL拼接，避开最常见的下载失败

很多文档系统里，KindEditor上传后生成的src并不是完整的绝对URL，而是像/uploadfile/2024/0901/abc.dwg这样的根相对路径，甚至可能是../../upload/image/2024/xxx.png这种带两级回退的相对路径。直接用这个路径去下载，requests库会报URL格式错误。

处理这类问题，用urljoin是最省力的。只要在解析阶段传入一个base_url，比如文档系统的前台域名或后台域名，Python会自动帮你把相对路径拼接成完整地址。上面脚本里我在两个分支都调用了urljoin，就是干这个事的。

实际部署下载脚本时，还要注意一个很现实的问题：文档系统一般都有登录鉴权，直接裸请求下载URL大概率会得到一个跳转到登录页的HTML，而不是真正的图纸文件。解决办法是在请求头里带上登录后的会话凭证，通常是一个Cookie，Python的requests.Session对象可以很好地处理这个问题：

python复制import requests

session = requests.Session()
session.headers.update({
    'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)',
    'Referer': 'http://doc.internal.test/admin/article_edit.jsp?id=1001'
})
session.cookies.update({
    'JSESSIONID': 'your_session_id_here'
})

def download_file(url, dest_path):
    resp = session.get(url, timeout=15)
    if resp.status_code != 200:
        print(f'failed: {url}, status={resp.status_code}')
        return False
    if resp.headers.get('Content-Type', '').startswith('text/html'):
        print(f'skip html page: {url}')
        return False
    with open(dest_path, 'wb') as f:
        f.write(resp.content)
    return True

顺带提一个批量下载时的性能习惯：不要一次性开200个线程去拉图，很多老系统扛不住这种并发，会把你的会话直接踢掉或者触发限流。我实测下来，控制在5到8个并发，每下载完一批sleep一下，整体速度反而不慢，而且稳定。

3. 图纸转存真正的分水岭：图片类图纸和CAD文件类图纸要分开走

3.1 已有DWG/DXF附件的场景：下载、校验、转换版本

如果从KindEditor正文里捞出来的是dwg或dxf附件，这件事相对简单一些，但别高兴太早。下载下来的CAD文件经常存在版本过新、老版本打不开的情况。有些工程师使用的是高版本CAD，另存文件时没注意版本选项，直接保存成了AutoCAD 2024格式。部门里其他人电脑上装的还是2018甚至2016，打开就会提示版本不兼容。

批量处理跨版本问题，我推荐的方式是用ODA File Converter，它可以把dwg在多个版本之间批量切换，命令行也可以用，适合和之前的Python下载脚本串起来跑。OdaFileConverter其实是个免费的小工具，很多做CAD二次开发的人都在用。转换命令大致长这样：

bash复制OdaFileConverter "D:\converted\input_dir" "D:\converted\output_dir" "ACAD2018" "DWG" "0" "1"

参数含义分别是：源目录、目标目录、目标版本、输出格式（DWG还是DXF）、是否递归处理子目录、是否包含隐藏文件。如果不想额外装这个工具，也可以直接用AutoCAD的脚本命令_SAVEAS逐个另存，但遇到几百个文件就比较折磨人了。

转换完成后，我习惯对每个图纸做一次“完整性”抽查：打开文件检查模型空间里是否有图元，检查是否存在代理实体。尤其注意，某些芯片设备厂商发的图纸里带着自定义对象，没有装对应插件的情况下，AutoCAD会把它显示成代理实体，直接转版本有丢失风险。

3.2 图片类图纸的转存：要不要矢量化，以及怎么兜底

图片类图纸才是“转存CAD”这件事里最让人纠结的部分。芯片制造文档里经常出现的图片类图纸有三种：第一种是CAD界面截图，工程师把局部装配图截下来贴在文档里；第二种是扫描件，比如老设备的纸质图纸扫描成PDF或者JPG后再截图上传；第三种是显微镜照片或实测照片，这种本质上是仪器输出图，虽然长得像“图”，但通常不需要转CAD。

先说结论：代码自动把位图矢量化成可直接编辑的CAD图纸，目前效果只在简单线稿上勉强可用，如果原图里包含尺寸标注、标题栏、虚线、中心线，自动矢量化出来的结果基本没法直接用。

我自己实测过很多次，自动矢量化最怕的就是两条线离得近、或者原图分辨率不够高的情况。它会把两条平行线识别成一条粗线，把尺寸标注的数字轮廓识别成填充区域，处理完比不用还乱。

所以我的建议是分情况走：

• 如果图片是设备的原理框图、流程图，这类图纸结构简单，线条规则，把位图插到AutoCAD里做底图，然后人工用多段线描一遍，反而比花时间调自动矢量化更快、更准。
• 如果图片是治具外形图，包含精确尺寸标注，那就必须拿到原始dwg，图片只能做参考，不能拿位图直接在CAD里测量尺寸。单靠图片上的标注和像素比例去重绘，误差风险太大。
• 如果图片只是现场安装照片、显微镜形貌图，压根不属于CAD图纸范畴，按参考图归档即可，不要强行转成dwg，转了也只是个光栅图像引用块。

这里可以给一个“踩图重绘”的标准操作：用AutoCAD的IMAGEATTACH命令把原图插入模型空间，插入时按比例拉到实际尺寸附近，然后把图片放到锁定图层“REF”，再用多段线和圆重新描画轮廓，最后在模型空间里做基准尺寸校验。这样做出来的CAD文件至少有骨架线和基本尺寸逻辑，后续工程师再修改也有一个可编辑基础。

3.3 DWG里的字体和线型问题，比图纸本身更影响交付

转过CAD图纸的人应该遇到过这种场景：文件打开了，图形也显示了，但是所有文字都变成了问号，或者明明该显示虚线的地方全部显示成实线。这是典型的字体和线型缺失问题，和转存动作本身没有直接关系，却是转存后最容易被下游同事吐槽的问题。

处理方式三个方向：

第一，把图纸涉及的字体一起拷贝。如果原文件用的是某个公司的专用HZTXT.shx字体，接收方电脑上没有，打开后文字必然乱码。转存文件时分一个fonts目录，把文档中引用的shx字体、ttf字体都带过去。AutoCAD会优先从选项里的“支持文件搜索路径”加载，但最简单的做法是把字体放进目标机器AutoCAD安装目录下的Fonts文件夹。

第二，设置合适的替代字体。在AutoCAD命令行输入FONTALT，默认值是simplex.shx，如果原图用中文长仿宋字体，它就会用simplex.shx渲染，中文变成问号。可以把FONTALT改成系统里已有的中文字体，比如改为TSSDENG.shx或者直接设置成宋体这种TrueType字体。

第三，做图层清洗。从KindEditor附件里转存出来的图纸，很多是设计人员从大装配图里局部导出的，图层里可能还有几十个无内容的图层、被冻结的外部参照图层。交付之前用PURGE命令清理无用对象，再用LAYDEL删掉冗图层，至少让对方拿到文件后第一眼不觉得头大。

4. 新装AutoCAD打开图纸“满屏全是线”：一个高频但好解决的问题

图纸转存回来后，第一道验证工序就是打开看能不能正常显示。很多同事反馈说新装了CAD、打开转存的图纸，满屏密密麻麻全是线，缩放哪里都看不到一个完整的零件。我一开始也怀疑是原文件损坏，排查了几次之后发现，这个现象更像是一个“新装CAD默认设置+图纸自身数据”叠加出来的问题。

4.1 先给这个现象定性：绝大多数不是文件损坏

我遇到过一个最典型的案例：同事下载了转存出来的治具图，打开后看到屏幕上从左上角到右下角全是细密的短线段，旋转一下模型更夸张，像一团被搅乱的毛线。他第一反应是把文件发回来说“转换坏了”，我打开同一份文件后却显示完全正常。

这就是一个经典的显示层面问题。新装的AutoCAD默认开启了硬件加速，但办公笔记本的核芯显卡或者某些远程桌面环境，对OpenGL支持不完整，CAD在重绘图形时会出现线条错乱、显示不完整、满屏残线。

处理顺序很简单：

第一步，在命令行输入GRAPHICSCONFIG，打开“图形性能”对话框，先把“硬件加速”取消勾选，再回来缩放图形看是否恢复。如果是远程桌面操作，这一步通常立竿见影。

第二步，如果关掉硬件加速没有明显变化，检查线宽显示。输入LWDISPLAY，默认值是ON，意即显示线宽。某些DWG里大量线条设置了0.3毫米或0.5毫米的线宽，视觉上层层叠叠，看起来就像满屏是线。把这个变量改成OFF，显示会清爽很多。

第三步，刷新显示。命令行输入REGEN，有时图形对象太多，显示缓存没刷新，密密麻麻的线其实只是旧缓存和新视图叠在了一起。

4.2 如果还是“线很多”，要开始怀疑数据层面的重复和隐藏对象

显示问题排除后，图纸依然显得杂乱，就要考虑文件本身的数据结构了。最常见的是大量重复对象。大家从KindEditor附件里转存出来的图纸，有些是由装配图反复另存、外部参照绑定后生成的，模型空间里可能堆积了大量重叠的线段、圆弧和块实例。肉眼看去，一条直线位置上有好几根完全重合的线，等于把所有图纸线都叠了好几层。

这种情况的清理命令是OVERKILL，回车后选择全部图形，CAD会删除完全重叠或近乎重叠的对象。清理一次，文件体积常常能下降百分之三十以上。

还有一个容易被忽略的地方：图层全开加颜色不区分。新装CAD默认不会自动隔离图层，某些图纸把几百个图层全部打开，各图层的线条颜色设置又接近，比如灰色和浅灰色混在一起，视觉上就分不清结构位置。处理方式是点击图层面板，先关闭所有外部参照和Defpoints层，再通过图层隔离命令把当前要看的部件单独显示出来。

4.3 外部参照和自定义对象：最容易让人误判的“线多”

我处理过一批从KindEditor正文附件里下载的厂房动力管道图，打开后整个布局区出现了一个巨大的“地图形状”的线框，删又删不掉，选又选不中，好像图纸本身就是乱的。后来打开外部参照管理器才发现，文件里关联了三个外部参照DWG，那些乱七八糟的线其实是参照文件带来的，不是当前图形自己的图元。

如果转存的CAD附件不需要保留外部参照关系，最好的处理方案是“绑定并拆离”，命令行输入-XREF，选择绑定选项，把外部参照的内容真正合并到当前图纸里。绑定后，再使用OVERKILL清洗一遍重复线条。

另外，如果图纸来自一些芯片制造设备厂商的专用制图插件，文件里可能包含大量proxy实体。没有安装原插件时，CAD会用代理图元代替显示，由于绘制规则缺失，这些代理实体在屏幕上的表现就是一堆不可编辑的乱线。查看方法是在命令行输入PROXYNOTICE，设为1，打开文件时就会提示代理实体数量。这类图纸要找到原插件或者让原发图方输出一份不带自定义实体的版本。

4.4 新装CAD图纸很乱的排查步骤清单

把整个排查过程整理成一张表，可以贴到部门共享目录里，大家遇到类似问题先自己对一遍：

其实这节内容看似和“KindEditor转存CAD”的主题有些偏移，但在实际项目中是同一个流程的两端。你辛辛苦苦把图纸内容提取下来，交付给别人的第一步就是让对方能顺利打开看到有效信息，如果新装CAD这关过不了，后面所有转存都白做。

5. 图纸回库：命名、单位、版本如何做到和芯片制造文档体系兼容

5.1 图档落盘路径和命名规则，要在跑批量之前定好

第一轮批量转存我犯过一个低级错误：因为全是从文档HTML里自动提取的，down下来的文件名全是原始URL的文件名，比如20240903_abc_dwg_v2.dwg，几十个文件长得很像，根本分不清是哪个产品线、哪台设备哪个工序的治具图。图库管理人员看到这种命名直接崩溃。

在写下载脚本之前，一定要先列好命名映射表。我的做法是：先从文章表的doc_no、title字段里提取产品线和工序名，再把正文里提取到的每个资源按顺序编号，最后生成一个CSV映射文件，把源URL、原文件名、目标文件名、所属文档号全部记录下来。

目标文件名建议遵循这样的格式：

text复制产品线代码-工序代码-图类型代码-日期-流水号-版本.dwg

比如封装压焊工序的夹具图：

text复制ASM-WB-FIXTURE-20240903-001-A.dwg

图类型代码可以自己约束：FIXTURE表示治具图，LAYOUT表示设备布局图，TRAY表示料盘/托盘图纸，SPAREPART表示备件图。这种编码一旦在部门内形成习惯，不用打开任何查看器，光看文件名就能判断图纸的大致归属。

自动下载脚本里，可以在保存dest_path时直接按这套规则拼接：

python复制import csv
import os

mapping = []

def build_destination(doc_no, source_url, index, version='A'):
    ext = os.path.splitext(source_url)[1].lower()
    # doc_no 示例: ASM-WB-20240831-SOP-001
    prefix = '_'.join(doc_no.split('-')[:2])
    dest_name = f"{prefix}-FIXTURE-{datetime.now().strftime('%Y%m%d')}-{index:03d}-{version}{ext}"
    return dest_name

# 每下载一个文件，把映射关系记录到csv，方便后续追溯
with open('mapping.csv', 'w', newline='', encoding='utf-8') as f:
    writer = csv.writer(f)
    writer.writerow(['doc_no', 'source_url', 'dest_path', 'file_type'])

5.2 单位、图框、版本栏是芯片制造文档协同里的“隐形标准”

图纸转存后要交给不同角色使用：设备工程师看安装尺寸，工艺工程师看动作时序，质量工程师看校验点。同一个文件，如果单位不同，极容易出事故。

芯片与电子制造行业有个特殊习惯：很多设备资料来自境外，原图可能是英制单位或者图纸上只标了英寸，而国内产线做治具加工时用的是公制毫米。传输中间只要忘了一次单位换算，一个公差标注就可能把整个治具做废。

转存后不要只是保存文件，我建议用AutoCAD打开文件后执行一次UNITS检查，把插入单位设置成长度毫米。然后统一图框：如果原图没有图框，自动加一个A4/A3标准图框，标题栏里填写图号、零件名、材料、版本、日期、编制人。这个工作可以通过一次批处理来完成，录一个action macro，对每个同名库文件执行一遍。

版本方面，从KindEditor文章里提取出来的图纸，它实际上是和某版文档绑定的历史快照。很多工程师拿到图纸后直接改了并覆盖保存，后续文档追溯时根本对不上。为了保留追溯关系，我在转存图库里会把原图复制一份带“ASM-REV”字样的版本归档，再创建一个工作副本供编辑，修改后工作副本更新版本号，归档版永久保留。

5.3 把正文里的旧链接信息回写，避免系统变“图裂”

KindEditor正文里那些图片和附件链接，是直接指向文档系统上传目录的。如果转存团队把图纸都下载到工程图库服务器，然后顺手把文档系统里的上传文件做了一次清理，那原来几十篇工艺文档里会立刻出现一堆破图图标，相关人员再次登录查看文档时，图纸全看不到了。

这个操作顺序必须谨慎。正确的做法是，在正文HTML被脚本解析后，先不要动原系统内容；等所有图纸都转存成功并验证没问题后，再决定是否清理。如果要清理，也应该在文档系统里做一次批量替换，把content字段中指向旧upload目录的IMG和A标签地址，替换为新的图库地址，或者统一替换为归档文件的相对路径。

这种批量替换SQL有一定风险，但思路可以参考：

sql复制UPDATE cms_article 
SET content = REPLACE(content, 
  '/uploadfile/2024/0901/old_asm_123.dwg', 
  '/archived/cad_center/ASM-WB-FIXTURE-20240903-001-A.dwg')
WHERE doc_no = 'ASM-WB-20240831-SOP-001';

只要在正式跑批之前备份一遍数据表，并且在测试环境里先验证一批数据，这个方法比手动改几十条HTML要可靠得多。

6. 写在最后：一些被验证过的操作习惯

KindEditor转存CAD图纸这件事，本质上拼的不是复杂的算法，而是流程每一步是否都有人把边界情况考虑进去。

我在反复处理了几个批次之后，逐渐固定了一套操作习惯。第一，先拿一篇典型的文档从解析到下载到打开验证完整跑一遍，确认脚本输出没有异常，再进入批量循环。直接一头扎进几千条的批量任务里，最后往往是要花更多时间排查那些半路下载失败的半成品。

第二，批量下载阶段不要追求极致并发。很多旧系统的KindEditor上传目录其实是在应用服务器本地，文件读取能力有限，高并发下载会把应用服务器的IO占满，影响正常员工浏览文档。把并发控制在5，每个文件下载之间加一个很短的等待时间，整个批跑下来虽然多花一点时间，但不会引发“系统突然变卡”的投诉。

第三，下载完成的图纸一定有一个“复验”动作。我习惯随机抽取百分之五到十的文件，打开看图形空间是否有内容、尺寸标注是否是有效的文字而不是线条组合、外部参照是否都已经绑定、字体替换是否正常。只有抽查样本达到这个比例，我才会认为当前批次可以归档。如果抽检时发现某一个环节大量出问题，就回溯到解析脚本和下载脚本改对应部分。

第四，每批次处理完，保留解析产生的中间HTML文件和CSV映射表。很多同事不明白为什么还要保留这种“垃圾文件”，等下一次要给图纸增加工艺流程标签或者追溯原始文档出处时，这些中间文件就成了唯一的索引。KindEditor正文可以升级改版，上传目录可以被清理，上下游系统可以调整URL，但CSV映射表会把“哪篇文档、哪个URL、哪个图纸文件、哪个版本”这条线索永久固定下来。

图纸转存这种工作，考验的不是你会不会点鼠标，而是你能不能把偶然的、散落在HTML正文中的资源，用一种可追溯的方式变成有序的工程资产。做完第一轮之后你会明显感觉到，下次再需要类似的数据迁移，整个业务域的人都会愿意来找你。