CAD图纸粘贴TinyMCE如何实现矢量输出？芯片设计评审的SVG转换方案

芯片设计评审系统里那张永远失真的截图，不知道各位有没有经历过：Fab的工程师把封装基板的CAD图纸复制进TinyMCE驱动的工艺文件管理平台，发给审核人一看——线是糊的，焊盘位置靠猜，想量个尺寸结果图上全是马赛克。这几乎是所有芯片制造企业做设计协同办公时必踩的一个坑。本篇文章就围绕“CAD图纸粘贴到TinyMCE后，如何保证矢量输出”这个具体问题，把底层逻辑、转换路径、TinyMCE配置、DXF转SVG的实现细节，以及芯片级大图性能优化的坑，一次性讲透。适合EDA系统的开发人员、企业IT集成工程师，以及天天和版图图纸打交道的CAD管理员阅读。

1. 为什么“复制CAD图纸进TinyMCE”这件事会翻车

1.1 一次真实的设计评审事故

先还原一个典型的故障现场。某天下午，封装设计组把一份包含BGA焊盘排列、走线层叠结构的图纸发到公司内部的工艺评审系统里。系统用的就是TinyMCE作为富文本编辑器，工程师按习惯在AutoCAD里框选图形、Ctrl+C，回到网页里Ctrl+V，图片成功贴进去了。结果评审会上把页面投到大屏时，图纸边缘出现明显锯齿，放大到焊盘区域，连引脚编号都看不清。

问题出在哪里？很多人第一反应是“图片分辨率不够”，然后试图通过调高截图DPI解决。但真正懂行的人知道，CAD图纸是矢量数据，无论怎么截图，导出成PNG、JPEG之后就已经是位图了，位图的分辨率天花板就在那里，放大必然发虚。只要源数据没有以矢量格式进入网页，后面做多少补偿都是白费。

1.2 浏览器粘贴的本质：剪贴板里根本没有矢量路径

要理解这个问题的根源，得先搞清楚“粘贴”在浏览器里到底发生了什么。当用户在AutoCAD里复制图形时，Windows剪贴板里会同时放好几份数据：DWG图元数据、DIB位图数据、增强图元文件（EMF）等。浏览器在响应粘贴事件时，通常只认 image/png 或 image/bmp 这类位图格式，TinyMCE把拿到的位图转成base64的data URL，直接嵌进编辑器的 <img> 标签里。

关键就在这里：浏览器拿到的是剪贴板里的位图版本，而不是CAD的矢量图元数据。剪贴板里那层位图，本质上就是一张像素画。CAD侧的矢量路径、图层名称、线宽信息，浏览器根本无法直接读取。所以，指望TinyMCE“自动”把CAD图纸粘贴成矢量，是不现实的——问题不出在TinyMCE，而出在数据源头。

1.3 芯片行业对矢量输出的要求比普通制造业更苛刻

普通机械图纸粘贴成位图，顶多是放大看不清尺寸标注，尚可忍受。但芯片制造企业的图纸涉及晶圆Layout、封装基板走线、光刻版图等场景，有几个特殊要求是位图完全没法满足的：

• 尺寸精确性：芯片封装图纸上的焊盘间距、走线宽度往往精确到微米级，评审时需要在线测量，位图没有可量化的坐标体系。
• 图层管理：一个封装基板文件通常有几十个图层，评审时需要单独看某个走线层或者阻焊层。位图把所有图层焊死成一张图，无法分层查看。
• 版本与追溯：图纸在TinyMCE里审核通过后，可能需要关联到ECN变更单、质量报告。如果内容是位图，后续想提取里面的坐标、网络名，基本只能靠人工重新录入。

所以“矢量输出”不是一个锦上添花的体验优化，而是芯片行业设计评审的刚需。

2. 把矢量路径从CAD里“请”出来的三条可行路线

既然浏览器没法直接拿剪贴板里的矢量数据，就要在“进入TinyMCE之前”先把格式转好。根据实际场景，有三条可落地的路线，按推荐程度排列如下。

2.1 路线一：CAD端直接导出SVG（最快，适合零散图纸）

最简单粗暴的办法，是在CAD软件里直接把需要的图纸区域输出成SVG文件。AutoCAD支持 EXPORT 命令，格式选SVG；中望CAD、浩辰CAD等国产软件也基本都有类似功能。导出的SVG文件可以直接拖拽进TinyMCE，或者通过编辑器工具栏的“插入图片”选择SVG文件。

这条路线几乎没有开发成本，适合图纸数量少、由设计师手工操作的场景。缺点也很明显：如果企业每天有几十上百张图纸要进入评审系统，让每个工程师都手动导出SVG再上传，效率太低，而且人工操作容易漏导出、导错范围。

2.2 路线二：服务端批量转换DXF/DWG为SVG（适合系统集成）

更工程化的做法是在服务端搭一条转换链路：设计师继续像以前一样把DWG/DXF文件上传到系统，后台自动把DWG/DXF转成SVG，再嵌入TinyMCE。转换引擎可以选择：

对于芯片行业，如果企业内部主要用AutoCAD，DWG文件居多，我一般建议先通过ODA File Converter或商业库把DWG统一转成DXF，再用ezdxf做二次处理生成SVG。这样既能用开源工具深度定制，又绕开了DWG格式闭源带来的兼容性坑。

2.3 路线三：CAD插件配合复制“SVG到剪贴板”（最接近“粘贴”直觉）

如果业务上确实要求“在CAD里复制，在TinyMCE里粘贴”这种交互，也不是完全做不到。可以在CAD里开发一个插件，用户框选图形后点击“复制为SVG”，插件自动调用AutoCAD的导出接口生成SVG，并把SVG文本写入系统剪贴板。

这时候TinyMCE里粘贴，剪贴板里就真的带有 image/svg+xml 数据了。配合TinyMCE 6.4及以上版本提供的 paste_paste_images_as_svg 选项，编辑器会优先把剪贴板里的SVG数据作为矢量内容嵌入，而不是退化成位图。

这条路线的开发工作量在CAD插件侧，需要用到AutoCAD .NET API或者ObjectARX。对于没有CAD二次开发能力的企业，可以直接选路线二，让用户走“上传DXF”而不是“粘贴”。

2.4 路线四（不推荐）：粘贴PNG后服务端自动转矢量

有人可能会灵机一动：反正粘贴进来的是位图，那我拿到这个PNG后调用服务端的图片矢量化工具，把它转成SVG不就行了？理论上可行，但实际应用于芯片图纸是灾难级的体验。

自动矢量化算法（如Potrace）面对的是线条和色块，它不认识CAD的图层、不认识线宽属性、更不认识文字。芯片版图里密集走线转换后会产生海量无意义的杂散路径，文件体积暴涨，精度还完全不可控。任何自动矢量化工具在芯片图纸上产出的结果，都无法替代原始CAD数据。所以这条路我直接劝退，不要浪费时间。

3. TinyMCE侧的关键配置：让编辑器真正“吃得下”SVG

3.1 开启SVG粘贴支持的两个开关

如果流程上能够保证剪贴板或上传文件里是SVG数据，TinyMCE这边只需要做几项配置。

首先是 paste_paste_images_as_svg，这个选项在TinyMCE 6.4版本之后提供，作用是让编辑器在粘贴时，如果剪贴板里同时存在位图和SVG格式的图片数据，优先把SVG作为嵌入内容。初始化时可以这样配：

javascript复制tinymce.init({
  selector: '#editor',
  paste_paste_images_as_svg: true,
  // ...其他配置
});

其次是 extended_valid_elements，确保编辑器不会把SVG标签过滤掉。TinyMCE默认的HTML过滤规则里，对SVG的支持是有限的，如果直接插入SVG字符串可能被拦下。建议增加一行白名单配置：

javascript复制extended_valid_elements: 'svg[*],defs[*],g[*],path[*],circle[*],rect[*],line[*],polyline[*],polygon[*],text[*],tspan[*]',

配置完这两个基础项，TinyMCE才能算真正兼容SVG内容。

3.2 自定义粘贴处理器：把位图换成服务端转换后的SVG

如果走的是“服务端批量转换”路线，用户上传/粘贴的是DWG/DXF文件，而不是SVG，那么TinyMCE默认的粘贴行为还是会把DWG文件当作普通文件处理。这种情况建议在工具栏加一个“上传CAD图纸”按钮，用dialog弹窗上传文件，后端返回SVG后再插入编辑器。

一个相对完整的处理逻辑如下：

javascript复制tinymce.init({
  selector: '#editor',
  paste_preprocess: (plugin, args) => {
    // 如果粘贴内容是文件列表里的DXF/DWG，拦截默认处理
    if (args.clipboardData && args.clipboardData.files.length > 0) {
      const file = args.clipboardData.files[0];
      const ext = file.name.split('.').pop().toLowerCase();
      if (ext === 'dxf' || ext === 'dwg') {
        args.preventDefault();
        uploadCadAndInsertSvg(file);
      }
    }
  }
});

async function uploadCadAndInsertSvg(file) {
  const formData = new FormData();
  formData.append('file', file);
  const resp = await fetch('/api/cad/to-svg', { method: 'POST', body: formData });
  const data = await resp.json();
  if (data.svg) {
    // 安全净化后再插入
    const cleanSvg = DOMPurify.sanitize(data.svg, {
      USE_PROFILES: { svg: true, svgFilters: true }
    });
    tinymce.activeEditor.insertContent(cleanSvg);
  }
}

这里的核心思路是：在数据到达编辑器DOM之前，就把DXF/DWG换成SVG字符串。通过 paste_preprocess 拦截，通过 insertContent 注入，完全绕开TinyMCE默认的位图路径。

3.3 为什么必须做SVG安全净化

SVG本质上是一种XML，可以内嵌 <script> 标签，也可以给元素挂 onclick 这类事件属性。如果CAD转换服务被投毒，或者图纸里混入了恶意构造的实体，SVG直接插入页面就相当于执行了一段不受信任的脚本，这在企业系统里是绝对不能接受的。

DOMPurify是目前最稳妥的选择。它对SVG的支持比较完善，可以保留绘图属性，同时清洗掉脚本、事件处理器、外部实体引用等危险内容。上面的示例代码里已经用到了 USE_PROFILES: { svg: true, svgFilters: true }，这是针对SVG场景的推荐配置。

还有一个小细节：DOMPurify清洗后返回的是字符串，插入TinyMCE时建议保留SVG根节点的 xmlns 属性。很多从转换工具直接输出的SVG会省略这个命名空间声明，在独立文件里浏览器能容忍，但一旦作为HTML片段插入DOM，各个浏览器对命名空间缺失的处理不一致，可能导致部分图形渲染不出来。所以我在服务端生成SVG时，会强制做一次根节点修补，确保带上 xmlns="http://www.w3.org/2000/svg"。

3.4 插入SVG的两种姿势与浏览器兼容性陷阱

把SVG放进TinyMCE编辑器，常见两种方式：editor.insertContent(svgString) 和 editor.dom.setHTML(svgString)。实测下来，前者更省事，TinyMCE会自动把内容合并进当前选区；后者适合需要完整替换编辑器内容的场景。

但有一个坑必须提醒：如果SVG字符串里有单引号、双引号混用不规范，insertContent 解析HTML时可能出错，导致插入的内容被截断。建议插入前用 JSON.stringify(svg) 打印检查一下，确保引号闭合。另一个常见问题是SVG里如果带 <style> 标签定义了图表样式，TinyMCE的Content CSS可能覆盖掉style里的规则，导致颜色错乱。我通常的做法是把关键颜色直接写成元素的 stroke 和 fill 属性，而不是依赖CSS覆盖。

4. DXF转SVG的核心实现：坐标、线宽和图层的翻译

4.1 推荐的技术栈：ezdxf + SVGBackend

讲完TinyMCE侧，回到最核心的转换引擎。如果服务端用Python，ezdxf是当前最成熟的开源DXF处理库，它自带的 ezdxf.addons.drawing 模块可以直接渲染DXF到SVG。基本代码如下：

python复制import ezdxf
from ezdxf.addons.drawing import RenderContext, Frontend
from ezdxf.addons.drawing.svg import SVGBackend

doc = ezdxf.readfile("input.dxf")
msp = doc.modelspace()

backend = SVGBackend()
ctx = RenderContext(doc)
Frontend(ctx, backend).draw_layout(msp, finalize=True)
backend.save("output.svg")

这段代码就能跑通一个最小可用的DXF转SVG流程。但真实芯片图纸远比这个复杂，至少还有坐标、线宽、图层、字体这几个问题需要单独处理。

4.2 坐标翻转的viewBox技巧：让CAD的Y轴“朝上”

CAD的数学坐标系里，Y轴正方向是向上的；而SVG的默认坐标系里，Y轴正方向是向下的。直接拿CAD坐标画SVG，图形会上下颠倒。

很多人第一反应是逐点做变换：svgY = -cadY。但这种做法会污染所有坐标值，后面如果要提取某个点的真实坐标去做联动标注，还得再反向换算一遍，非常麻烦。

更好的方案是在SVG根节点上通过viewBox把坐标空间翻转。先算出整张图纸的包围盒：

python复制from ezdxf import bbox

extents = bbox.extents(msp)
min_x, min_y = extents.min.x, extents.min.y
max_x, max_y = extents.max.x, extents.max.y
width = max_x - min_x
height = max_y - min_y

view_box = f"{min_x:.4f} {-max_y:.4f} {width:.4f} {height:.4f}"

这里的诀窍是取 -max_y 作为viewBox的 min-y，高度保持不变。这样viewBox内部坐标系的Y轴就是向上的，CAD里的原始坐标可以直接写进SVG的 d 属性、x、y 属性，不需要任何数学变换。

实际效果：CAD里一个点 (100, 200)，在SVG里写 M 100 200，浏览器渲染时根据viewBox映射，会自动把Y翻转，显示位置和CAD里完全一致。之后做焊盘坐标提取、点击测量，拿到的都是CAD原始数值，这个优势在芯片场景里价值极大。

4.3 线宽映射：从CAD物理单位到SVG屏幕单位

CAD里的线宽单位是毫米，DXF属性 lineweight 的存储单位是1/100毫米。比如值为25，代表0.25mm。SVG里的 stroke-width 默认是用户单位。如果viewBox保持1:1毫米映射，那0.25mm的线宽在SVG里是0.25，渲染成96dpi屏幕约等于0.94px，肉眼看起来偏细，被缩略显示时几乎看不清。

我的经验是按图纸整体尺寸动态算一个全局线宽缩放系数。比如最大图纸宽度是1000mm，网页展示区域最多800px，那缩放系数就是0.8。映射函数可以写成：

python复制def map_linewidth(lineweight_100mm, scale_factor=1.0):
    if lineweight_100mm is None or lineweight_100mm <= 0:  # ByLayer或默认值
        return 0.35  # 按0.35mm默认线宽处理
    width_mm = lineweight_100mm / 100.0
    width_px = max(0.1, width_mm * scale_factor)
    return f"{width_px:.2f}"

这样既保住了线宽之间的相对粗细关系，又能在网页上呈现可辨识的层次。绝对数值不用太较真，评审场景要的是“看得到、分得清”，不是打印级还原。

4.4 图层信息的结构化保留：一个图层一个SVG组

DXF的图层信息如果丢掉，等于把一套完整的工程数据降级成了一幅画。转换时建议按图层分组输出：每个图层对应一个 <g> 元素，class 属性里带上图层的原始名称，data-layer 属性存机器可读的层名。示例如下：

python复制layers = {}
for entity in msp:
    layer_name = entity.dxf.layer
    layers.setdefault(layer_name, []).append(entity)

# 渲染时，每个图层生成一个 <g data-layer="xx">...</g>

这样TinyMCE里的SVG就保留了图层结构，前端JS可以方便地实现图层的显隐控制。后续做走线层单独查看、阻焊层标识，都不用重新生成图片，直接在页面里加一个勾选框就行。

颜色映射同样依赖图层表。DXF的实体颜色用的是AutoCAD颜色索引（ACI），不是直接的RGB。建议在服务端预先读一遍LAYER表，把常用颜色索引映射成hex，例如颜色1是红色，颜色2是黄色，颜色5是蓝色。没有特别要求时，转换脚本里用一个字典写死前255号的基础映射即可，足够覆盖绝大多数图纸。

4.5 文字与SHX形字体的处理：最容易翻车的一环

芯片图纸里往往有不少标注文字，比如引脚名、网络名、层序号。DXF里文字有两种形态：纯文本（TEXT/MTEXT）和已经炸开成线条的形（SHX字形）。电子图纸里纯文本居多。

ezdxf 在渲染纯文本时，会试图用本机TrueType字体替代。问题是芯片行业大量使用AutoCAD的SHX字体（比如 simplex.shx、hztxt.shx）标注，这些字体是CAD独有的矢量形定义，系统里没有对应的TrueType字体，转换出来的SVG里中文变成一串乱码或者空心方块。

稳妥的解决办法有两个方向。方向一，在CAD源头处理：设计师在输出之前，用 TXTEXP 把文字炸开成多段线，这样转换出来的就是图形线条，不存在字体问题。方向二，在转换脚本里做字体映射：把常见的SHX文件名映射到系统已有的中文字体，比如：

python复制font_mapping = {
    "hztxt.shx": "simsun.ttc",   # 宋体
    "simplex.shx": "simplex",    # 英文字体
}

具体的API在ezdxf的渲染上下文里可以配置字体替换。实在不行，就在SVG输出的CSS里给 text 元素加一个全局的 font-family 兜底：

css复制text { font-family: "Noto Sans CJK SC", "Microsoft YaHei", sans-serif; }

这里要特别说一句：如果图纸对文字形状有硬性精度要求（比如芯片版图的PIN名形状不能变），唯一可靠的方案是让CAD端提前把文字炸成曲线。所有依赖系统字体替换的方案，都存在字形偏差风险，评审时可以接受，审查做精细比对时不行。

4.6 一个完整的最小转换脚本

把上面的要点串起来，服务端一个可用的转换函数大致长这样：

python复制import ezdxf
from ezdxf import bbox
from ezdxf.addons.drawing import RenderContext, Frontend
from ezdxf.addons.drawing.svg import SVGBackend
from lxml import etree

def dxf_to_svg(dxf_path, svg_path):
    doc = ezdxf.readfile(dxf_path)
    msp = doc.modelspace()

    extents = bbox.extents(msp)
    min_x, min_y = extents.min.x, extents.min.y
    max_x, max_y = extents.max.x, extents.max.y

    backend = SVGBackend()
    ctx = RenderContext(doc)
    Frontend(ctx, backend).draw_layout(msp, finalize=True)
    backend.save(svg_path)

    # 后处理：修正viewBox和命名空间
    parser = etree.XMLParser(remove_blank_text=True)
    tree = etree.parse(svg_path, parser)
    root = tree.getroot()
    root.set("xmlns", "http://www.w3.org/2000/svg")
    root.set("viewBox", f"{min_x:.4f} {-max_y:.4f} {max_x - min_x:.4f} {max_y - min_y:.4f}")

    # 给SVG元素补上图层属性
    # 这一步根据实际渲染情况，可能需要遍历后端输出的节点

    tree.write(svg_path, pretty_print=True, xml_declaration=False)

这个脚本的后处理步骤很关键：SVGBackend 输出的SVG不一定给根节点设置正确的viewBox，手动覆盖一次，能确保坐标方向不出问题。

5. 芯片版图级别的性能与避坑：几万条实体不是闹着玩的

5.1 十万元素级DXF转SVG，浏览器卡死的根因

普通机械图纸可能几千个实体，SVG随便渲染。但芯片封装基板、光罩版图级别的DXF，实体数量动辄几万到几十万，全量转成SVG后，每个实体都是一个独立的DOM节点，浏览器渲染时布局计算、样式计算的开销会成倍上涨。页面拖动、缩放时掉帧，严重时直接崩溃。

遇到这种情况，不要先怀疑转换脚本，首先要确认业务需求：评审场景真的需要同时显示全部图层、全部实体吗？ 绝大多数时候不需要。芯片图纸评审是分层、分区域进行的，一次只看一两个关键层。

5.2 三个有效的瘦身策略

第一，按图层过滤。服务端转换时，接收前端传来的“需要显示的图层列表”参数，只渲染这些图层。比如默认只导出TOPLayer、BOTTOMLayer，阻焊层、丝印层留待用户勾选后再生成。

第二，按范围裁剪。如果图纸只有局部区域发生了设计变更，可以让用户在CAD里框选范围，只把框内实体导出。DXF文件里支持按坐标范围筛选实体，这个在服务端循环实体时加一个包围盒判断即可。

第三，动态分段渲染。超大图纸不生成一张完整SVG，而是把图纸切成若干瓦片（类似地图瓦片），TinyMCE里嵌入一张SVG总览图，用户放大到某个区域时，再异步请求这个区域的高精度SVG图层。这个方案工程量最大，但效果也最好，适合做在线版图协同浏览的团队。

5.3 输出文件体积与浮点精度怎么平衡

芯片图纸坐标值可能很大（几十万的x、y坐标），但精度要求又高（小数点后三四位）。SVG文件里坐标如果写成 100000.12345678 200000.12345678，一个path的d属性会非常冗长，文件体积陡增。

建议在渲染前对坐标统一做一次舍入优化。实测中，芯片评审场景保留3位小数足够了，1微米级别误差对于评审显示完全可控。但要注意：如果后续需要从SVG里提取坐标做精确测量，舍入策略要跟测量精度需求对齐，不能为了压缩体积把精度丢到不可接受的程度。

5.4 乱线、放射状线条到底是怎么来的

热搜词里有“cad出现放射状乱线”“cad 乱线 转 文字”，这两类问题在转换场景里同样会出现。放射状乱线的真正成因通常是DXF文件里有极长实体跨越大范围，比如一条从坐标原点画到数万毫米外的辅助线，SVG在渲染时为了适配这条线的包围盒，把有效图形压缩到很小一块区域，其他实体全部挤到边缘，看起来就是放射状。

解决方法是转换前做数据清洗：遍历实体，计算每个实体的几何范围，如果某个实体的外接矩形远大于全图包围盒的合理范围，直接跳过或单独打标记。这个预处理能解决大部分“转换后图面爆炸”的问题。文本乱码则对应前文提到的字体映射问题，优先在源头炸开文字，其次配置字体替换。

5.5 判断矢量输出是否成功的验证清单

每次改完转换脚本，别急着交付，用一份真实产品图纸跑一遍完整验证。下面这个清单是我内部常用的：

• 粘贴到TinyMCE后，选中SVG元素，确认DOM里是 <svg> 而不是 <img>。
• 浏览器窗口拉大到200%，图形边缘是否平滑、无锯齿。
• 在SVG里搜索图层名称，确认图层分组还在。
• 鼠标悬停某个焊盘，确认坐标数值与CAD原始坐标一致（Y轴方向已验证）。
• 文件大小对比：同图纸转出的SVG是否明显小于PNG导出（排除极端情况）。
• 用DOMPurify清洗后，确认没有残留的 on* 事件或 <script> 标签。

只要这六项全部通过，这个转换流程基本可以上生产。

6. 产线落地后的迁移经验与进阶可能

上面这些内容讲的是技术实现，但真正让方案在企业里跑顺，还涉及一个软性问题：用户习惯。这里说说我们踩过坑后总结出来的落地体会。

最关键的改变，是把“复制粘贴”改成了“上传转码”。 最初我们坚持做CAD插件复制SVG到剪贴板，交互上确实贴合工程师习惯，但插件部署、版本兼容、CAD版本升级带来的维护成本非常高。后来换了个思路：在TinyMCE工具栏里加一个醒目的“上传CAD图纸”按钮，用户上传DWG/DXF后，系统自动转换SVG并插入编辑器。虽然多了一步“保存文件再上传”，但胜在稳定、可控、支持批量。实际操作中，工程师反馈良好，因为图纸自动带上了图层信息，比他们手动截图清晰太多了。

这个方案后续还有几个可以扩展的方向。 一是把SVG里的图层信息与评审流程打通，审核人在网页上直接勾选“只看某层”，系统记录这次评审看了哪几个图层，形成完整的评审痕迹。二是把SVG嵌入与ECN变更单关联，每次设计变更都生成一张新SVG，用脚本对比新旧SVG的差异区域，自动标注变更范围。三是如果企业已经有PDM/PLM系统，SVG可以作为轻量预览文件随DWG一起入湖，DWG放原始库，SVG放预览层，浏览性能完全不在一个量级。

回到最初那个问题：芯片制造企业解决CAD图纸粘贴到TinyMCE的矢量输出，本质上不是给TinyMCE加一个插件，而是要在CAD数据与Web渲染之间建一条可控的转换管道。转换在哪一端做、用什么工具、TinyMCE怎么接，这些技术点本文已经拆开讲完了。有了这条管道，图纸到了网页上就不再是“一张会糊的图”，而是一份保留了坐标、图层、线宽，可以继续支撑评审、测量、追溯的活数据。这正是芯片行业做数字化协同最值得投入的一环。