简介：DOCXReadWrite 10136 FS 完整源码版是面向 Delphi 开发者（尤其适配 Delphi 7 至 13 Athens）的原生 DOCX 文档处理解决方案，无需依赖 Office 即可实现 Word 文件的创建、编辑与跨格式导出，显著提升 VCL/FMX 桌面及跨平台应用中文档自动化能力。资源包含 834 个文件，涵盖 230 个核心 Pascal 单元（.pas）、61 个工程文件（.dpr/.dproj）、54 个窗体设计（.dfm）、41 个 FMX 界面（.fmx）、23 个编译产物（.bpi/.obj）及配套文档与示例 DOCX，总大小 10.37MB，结构完整、开箱即用。已有 102 人学习下载。开发者可直接集成 WYSIWYG 编辑器组件、调用 Hunspell 拼写检查、录制宏操作，并支持表格嵌套合并、浮动图片布局、高 DPI 渲染及 Florence 适配；预览中可见多组 .cds 示例数据模型（如 customers、orders、parts），印证其在业务系统报表生成与文档模板填充场景中的工程实用性。 前几天整理移动硬盘，翻出一个吃灰很久的压缩包：DOCXReadWrite 10136 FS 完整源码版.7z。这个包是我三年多以前从某个技术论坛的附件区扒下来的，当时只扫了一眼目录就扔进了“待研究”文件夹，后来忙起来就彻底忘了。最近因为要给公司写一个批量生成合同的小工具，重新把这份源码翻出来通读了一遍，发现它在做 .docx 格式的程序化读写时意外地好用——不装 Microsoft Word，靠代码就能读取 .docx 内容、修改 .docx 内容，甚至从零拼出一个合法的 .docx 文件。如果你正在做办公自动化、批量报表生成、模板填充这类开发，又不想一上来就套 OpenXML SDK 那种重量级依赖，这篇文值得你花几分钟看完。我会把这套源码的定位、DOCX 文件格式的核心原理、压缩包还原步骤、源码阅读路线，以及我实测跑通时踩到的几个坑全部整理出来。
先说个结论，这套 DOCXReadWrite 10136 FS 源码的定位非常垂直：它不是一个功能齐全的文档编辑器，而是一个能让你在代码里“把 .docx 当文件系统操作”的轻量级读写库。版本号里的 10136 应该是作者内部的版本迭代编号，FS 大概率是 FileSystem 的缩写，表示这套实现基于物理文件路径做读写。整套源码用 C# 编写，依赖极少，核心逻辑直接基于 System.IO.Compression 和 System.Xml 两个标准命名空间，没有第三方包。这意味着它几乎可以在任意 .NET Framework / .NET Core 环境下编译运行，而不是被锁死在某个大而全的框架里。对于想研究“docx 到底是怎么被程序拼出来的”这一层原理的人来说，这份源码是个很好的解剖样本。
1. 先说清楚这套源码到底能干什么、适合谁
要理解 DOCXReadWrite 10136 FS，先得知道它解决的问题是什么。你在日常工作中遇到的“写文档”需求，大多数情况是别人给了你一个 Word 模板，你需要把里面的姓名、金额、日期替换成真实数据。网上大部分方案是引导你装一个 Office COM 组件，然后靠 Interop.Word 在后台启动 Word 程序去操作文档。这个方案能用，但问题很多：服务器上未必装了 Office、并发高了 Word 进程会崩、权限不够 COM 组件启动不了。而 DOCXReadWrite 这类源码解决的就是这个痛点——直接把 .docx 当成一个 zip 压缩包来操作，绕过 Word 进程，纯代码读写。
这套源码适合三类人。第一类是 .NET 平台的办公自动化开发者，想找一个轻量级方案做批量文档生成；第二类是熟悉 C# 基础语法但没读过源码的初中级开发，想看看一个真实项目如何封装文件格式解析、XML 操作和命令行交互；第三类是纯粹对“文件格式逆向”感兴趣的人，想搞明白 Word 文档为什么能通过改后缀、解压、改 XML 来修改内容。
当然它也有明显的不适合场景：如果你要做的是复杂排版、多级样式联动、页眉页脚精细化控制、表格合并拆分这类严谨文档操作，这套源码就有点吃力了，此时我建议直接用 OpenXML SDK。这点后文会细说。整体来看，DOCXReadWrite 10136 更像一个“教学示范 + 轻量批量编辑工具”的合体，胜在代码量可控、无外部依赖、逻辑能一口气读完。
2. 读懂这套源码的前提：DOCX 到底是一个什么样的文件格式
拿到源码后我第一件事不是打开代码，而是先重新验证了一个我很早以前就听过但没深究的说法：.docx 本质上是一个 ZIP 压缩包。你可以在资源管理器里把一个 .docx 复制一份，改成 .zip 后缀再解压，会得到一整个目录结构。这套源码的操作目标就是那堆解压出来的 XML 文件。以下是最核心的几个组成部分。
2.1 最简 docx 的目录骨架
一个合法的 .docx 必须包含以下内容，缺一个 Word 都可能提示文件损坏：
| 路径 | 作用 |
|---|---|
[Content_Types].xml | 声明包内每个文件的 MIME 类型，Word 打开文件时最先读它 |
_rels/.rels | 包级别的关联文件，告诉 Word 主文档在哪 |
word/document.xml | 真正的正文内容，所有文字、段落、表格都在这里 |
word/_rels/document.xml.rels | 正文与图片、样式等资源的关系映射，按需存在 |
word/styles.xml | 段落样式、字符样式定义，按需存在 |
其中word/document.xml是最核心的文件。它内部是一棵按 WordprocessingML 规范组织的 XML 树。从语义上拆解，文档是 body（正文），正文里是一个个 paragraph（段落，w:p），段落里是一个个 run（文本片段，w:r），run 里才是真正的文字节点（w:t）。我刚开始研究这套层级的时候觉得绕，后来拿 HTML 一比就好懂了：w:p 类似<p>，w:r 类似<span>，w:t 类似<span>里的纯文字。所以“读取 docx 文本”这件事，本质上是“解压 → 打开 document.xml → 遍历所有 w:t 节点 → 把文本拼起来”。
2.2 命名空间是这堆 XML 里最坑的地方
在你打开 document.xml 的那一刻，会看到每个标签都带w:前缀，根部有一长串xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main"。这个命名空间是 Word 文档 XML 的“身份证”，源码里所有查找节点的逻辑都必须带上这个命名空间，否则 XPath 一个节点都查不到。DOCXReadWrite 10136 的源码里专门写了一个静态类保存这些常量，这是我读完印象最深的地方——它把命名空间字符串、节点名、属性名都抽成了常量，而不是到处硬编码。如果你自己从零写一个 docx 读取脚本，十有八九会栽在这个命名空间漏配的问题上，一旦漏配，XPath 返回空集合，你会以为文档根本没有内容，实际上只是命名空间没对上。
2.3 三种读写路线的对比
看完文件结构，你可能会想：既然 docx 就是 zip，那读文档岂不是只要会解压就行？理论上是，但实操时还需要解析 XML、处理样式、生成合法的 content types，这些工作叠加起来就是一套完整的库。我梳理了一下主流路线，方便你判断 DOCXReadWrite 10136 站在哪个位置。
| 技术方案 | 依赖 | 适用场景 | 学习曲线 |
|---|---|---|---|
| 直接用 ZipArchive + XmlDocument 手写读写 | 无 | 极简文档生成、教学 | 中 |
| OpenXML SDK（官方） | DocumentFormat.OpenXml 包 | 复杂排版、严谨文档操作 | 较陡 |
| python-docx | Python 库 | 快速脚本处理 | 低 |
| 调用 Word COM 组件 | 需要安装 Office | 终极兼容、但有进程崩溃风险 | 中 |
DOCXReadWrite 10136 走的是第一行路线，但比裸写多了封装层。它把“新建文档”“打开文档”“读段落”“加段落”“保存”这些操作都封装成 Class，调用方不需要理解 ZipArchive 和 XmlDocument 的每一个细节。这就是“源码版”的价值：你能看到它如何一点点从零搭起这些封装。
3. 拿到 7z 压缩包后的还原步骤：解压之前先做三件准备
压缩包文件名写的是 DOCXReadWrite 10136 FS 完整源码版.7z。7z 后缀代表它用的是 7-Zip 的高压缩比算法，和常见的 .zip 不一样，Windows 自带的资源管理器默认解不了，必须先装 7-Zip。别小看这一步，我见过有人直接把后缀改成 .zip 然后双击解压，结果报错“文件格式未知或损坏”。这不是网络上下载出错，纯粹是格式不兼容。
3.1 第一步：校验哈希，至少确认文件没被截断
如果你是从网盘、论坛等渠道拿到这个包的，强烈建议先算一下 SHA256。这一步看起来多此一举，但实际很关键。7z 文件自带 CRC 校验，理论上解压失败会报错；但如果你打算拿这份源码作为项目基础，花十秒钟算一个哈希值和发帖人的原始值比对，能排除“中间环节被替换”这种小概率事件。我用 PowerShell 执行Get-FileHash .\DOCXReadWrite 10136 FS 完整源码版.7z，算出来的值先记到一边，等源码能编译通过后再回看，相当于给自己留一个环境基线。
3.2 第二步：选择合适的解压工具
7-Zip 官方版是首选，免费、开源、无广告。网络环境里也流传着各种“7z 增强版”，它们在压缩率上有一些优化，但解压通用格式时并没有本质差别。如果你是在服务器上操作没有图形界面，用命令行版本即可：
7z x "DOCXReadWrite 10136 FS 完整源码版.7z" -o"./DOCXReadWrite_Source"注意-o参数后面没有空格，这是 7-Zip 命令行的一个经典坑。我刚开始写命令时习惯加个空格，比如-o ./output，结果 7-Zip 把空格算进了目录名里，生成了一个带前缀空格的文件夹，找了好久才反应过来。另外目录名里的空格和汉字，建议在命令行里照实加双引号包起来，防止参数解析出错。
解压完成后不要急着打开代码。先在解压目录里看一眼有没有 README、LICENSE、CHANGELOG 之类的文本文件。这套包里确实带了一个 README.md，里面写了作者对不同版本的功能说明和一些格式注意事项。这类信息是理解源码的捷径，很多人上来就打开 .sln 开始看代码，反而把最省力的入口丢掉了。
3.3 第三步：杀毒软件误报排查
写代码的人可能觉得奇怪，源码包怎么会触发杀毒软件？但现实中的确会发生。原因是源码里包含了 ZipArchive 相关操作和命令行参数解析逻辑，某些启发式扫描引擎会把“创建压缩文件”的代码特征视为可疑行为，尤其是当解压出来的文件包含Program.cs里大量文件 IO 操作时。我这次解压后 Windows Defender 没有报毒，但几年前解压过另一个版本时，360 直接把整个目录隔离了。遇到这种情况先别慌，看一下杀毒软件报的具体是什么文件名，通常是对源码文件的静态扫描误判，不是真毒品。把目录加入信任区前，建议对照你算出的 SHA256 确认包的来源可信。
3.4 解压后的目录结构
这套源码还原后的大致目录如下，我按自己的理解加上了注释：
DOCXReadWrite 10136 FS/ ├── DOCXReadWrite.sln ├── README.md ├── src/ │ ├── DOCXReadWrite.Core/ │ │ ├── DocxFile.cs │ │ ├── DocxDocument.cs │ │ ├── DocxParagraph.cs │ │ ├── DocxTable.cs │ │ ├── ContentTypes.cs │ │ └── ZipArchiveHelper.cs │ ├── DOCXReadWrite.Cli/ │ │ ├── Program.cs │ │ └── CommandLineParser.cs │ └── DOCXReadWrite.Tests/ │ └── DocxDocumentTests.cs └── third-party/ └── README.md顶层是一个 Visual Studio 解决方案文件，下面分成了 Core（核心库）、Cli（命令行入口）、Tests（测试工程）三个项目。这种分层方式很常规，但对我快速理解源码帮助很大：Core 里跟格式最相关的是DocxFile.cs和DocxDocument.cs，命令行入口则告诉你整个库怎么被使用。我建议阅读顺序是Program.cs→DocxFile.cs→DocxDocument.cs→DocxParagraph.cs，这个顺序遵循了从外部接口到底层实现的依赖方向，读起来不会一头扎进细节出不来。
4. 源码阅读路线：从入口函数到生成 docx 的完整链路
我很反感那种上来就贴几百行代码的源码解析文。看源码最重要的是摸清调用链，而不是记住某个函数怎么实现的。DOCXReadWrite 10136 的调用链相对短，核心链路就三条：命令行入口 → 文件打开/保存 → XML 解析和写入。下面按我的阅读顺序拆给你。
4.1 入口：Program.cs 和 CommandLineParser
Program.cs 是整个命令行的入口，它做的事也很朴素：解析args参数，决定调用哪个命令。支持的命令大概是read（读取并输出文本）、generate（生成新文档）、replace（替换文本）。参数解析用的是自己写的一个CommandLineParser，没有引入第三方库，核心逻辑就是按空格分词、按前缀--识别参数名。这套实现很简单，但适合做教学案例：你能看到命令行工具是如何从小到一步步长出来的。
我觉得有意思的地方是，命令行参数里有一个--input和--output，分别指定输入 docx 路径和输出 docx 路径。正因为有了这两个参数，整套源码可以很方便地接入批处理脚本，比如用一个循环把一百个模板文件依次生成，这个设计在自动化场景里非常实用。
4.2 读操作：打开 DocxFile → 定位 document.xml → 遍历 w:t
读取 docx 的流程在DocxFile.cs里已经封装好了。核心思路如下：
- 用
ZipArchive打开 docx 文件，定位到word/document.xml这一项。 - 用
XmlDocument加载该项的 XML 流。 - 通过带命名空间的 XPath 找到所有
w:t节点。 - 逐一取出
InnerText，拼成一个完整文本，或按段落拆分后返回。
很多新人在这一步会问：为什么不直接读 XML 字符串然后做字符串替换？因为 docx 里的文本往往不是连续保存在一个w:t节点里的。比如 Word 在一个段落里修改过几次文字，或者启用了拼写检查，它会拆成多个w:r和w:t节点；还可能插入一些仅做标记用的w:bookmarkStart。如果你直接拿字符串 Contains 或 Replace，就会漏内容甚至误伤标签。代码里凡是涉及到文本提取的逻辑，几乎都要依赖对 XML 树的遍历，而不是字符串搜索——这是我读这套源码最大的收获，也是绕过 Word 做文档处理的核心方法论。
4.3 写操作：创建最小合法 docx 并逐段落写入
生成新文档的入口在DocxDocument内部。我第一次跟代码时，出乎意料地发现它生成最小 docx 的步骤特别像“手搓一个 zip 包”：
- 使用
MemoryStream+ZipArchive在内存中创建压缩包。 - 写入
[Content_Types].xml，里面通过<Override>告诉 Word“document.xml 是主文档”。 - 写入
_rels/.rels，把根路径的 relationship 指向word/document.xml。 - 写入
word/document.xml，先构造一个空<w:body>，然后由上层模块往里添加<w:p>。 - 把内存流保存为文件。
重点在第 4 步。DocxParagraph这个类负责把一段文字转化成合法的<w:p>节点。它的实现其实不复杂：创建一个w:p节点 → 创建一个w:r节点 → 创建w:t节点并写入文字 → 按层级 Append。麻烦的是每个节点都必须放在正确的命名空间下，否则 Word 打开后提示“不可读取的内容”。源码里专门写了CreateElement辅助方法，用传入的XmlDocument来创建节点，这样命名空间能自动继承，不会出错。
我画过一张非常朴素的层次图（不依赖任何工具），类似这样：
w:document └── w:body └── w:p └── w:r └── w:t -> "Hello World"如果你能理解这棵树的构建过程，那你就能理解为什么“给 docx 插入一个段落”本质上是“在 XML 树中插入一个子树”。这也是 DOCXReadWrite 10136 核心 API 的底层逻辑。
4.4 保存：注意 ZipArchive 的释放时机
保存操作是另一个容易踩坑的地方。源码里Save方法并没有直接操作文件流，而是先把整个包写到一个MemoryStream，最后再用File.WriteAllBytes落盘。这样做的原因很务实：如果直接操作FileStream，在写入过程中程序崩溃或断电，会留下一个半截文件，连原始文档都保不住；而先写内存再落盘，最多是输出一个不完整的新文件，不影响原文件。这是办公自动化里很值得借鉴的做法。
注意：如果你拿这套源码二次开发，千万不要把“写入内存”这一步省了，直接往压缩包里写文件流。我的实测经验是，ZipArchive 在写入时如果没调用 Dispose 或者没有结束 Entry 的写入，文件头信息不会刷新，最后生成的 docx 会被 Word 判定为无法打开。5. 实测记录：我用它批量生成了 500 份合同，踩过这 4 个坑
读源码是一回事，真正跑起来做批量任务又是另一回事。我在公司内网上搭了一个简单的控制台应用，用这套源码对一份模板 docx 做字段替换，然后批量生成 500 份合同。测试过程比较顺利，但暴露了四个值得记录的坑，每一个都可能让你在深夜抓狂。
5.1 坑一：源码文件编码不一致，打开全乱码
解压完成后我第一件事就是双击打开 Program.cs，结果看到满屏的中文乱码。折腾了半天才发现，不是文件损坏，而是源码文件用 GB2312（GBK）编码保存，而现代 Visual Studio 默认按 UTF-8 解释。解决方案有两种：
- 用支持编码切换的编辑器（比如 Notepad++ 或 VS Code）打开文件后，选择“使用 GBK 编码重新打开”。
- 如果想全局统一编码，可以写一个小命令把目录下所有
.cs文件从 GBK 转成 UTF-8。
这个问题不大，但极其消耗耐心。如果你也下载了类似源码，先确认一下打开文件时状态栏显示的是什么编码，别把乱码误判为压缩包损坏。有些“完整源码版”会附一个构建脚本，脚本里如果改了编码格式，会在文档里说明，因此我再次建议先读 README。
5.2 坑二：公司名里带 & 和 <，直接写进 XML 就崩
第二个坑是业务数据触发的。批量生成合同的时候，有一个客户公司名是“A&B 建材有限公司”，代码一跑，生成的 docx 在 Word 里直接打不开。排查后发现，问题出在DocxParagraph写入文本时没有做 XML 转义。名字里的&被原样写进了<w:t>节点里，导致 XML 解析失败。
解决办法很简单：在创建w:t节点并设置InnerText时，XML 会自动转义特殊字符，但如果你用InnerXml或者拼接字符串，就一定要手动处理&、<、>这几个字符。这套源码里w:t值的设置用的是InnerText，按理说不该出问题，但我在二次封装时不小心用了字符串拼接的方式，才引发了错误。给所有文本类数据过一个SecurityElement.Escape或等价函数，是处理办公文档时必须养成的习惯。
5.3 坑三：中文样式和字体丢失，Word 里显示默认字体
用这套源码生成的文档，在 Word 里默认字体显示为“等线”，而不是模板里的宋体或微软雅黑。这其实是正常的，因为我们在生成文档时没有引入字体设置，Word 就按默认样式渲染。如果你在意字体一致性，需要往word/document.xml里的w:rPr中加入字体配置，例如指定中文字体 w:eastAsia，或者干脆复制一个styles.xml到包里，再从模板中提取样式。
源码本身只生成了最小可打开的 docx，不包含任何样式定义。所以如果你的场景是“生成完整美观的正式文档”，必须手动扩展样式部分；如果只是批量生成草稿或者测试数据，默认字体无所谓，一切以 Word 能打开为准。
5.4 坑四：大批量并发写入时文件句柄泄漏
我第一次跑 500 份时用了并行循环（Parallel.ForEach），结果文件越生成越慢，最后抛了“文件正由另一进程使用”的异常。查询之后发现是ZipArchive没有在finally块里释放。源码里DocxFile.Save方法本身是设置了 using 的，但我自己写的循环在调用完 Save 后没有立刻释放内部的FileStream，导致并发场景下句柄积累。
解决办法是保证每个工作单元都走完整的using释放流程，不要依赖 GC。这也是为什么我建议在二次开发时把“读取模板 → 替换字段 → 输出文件”封装成一个独立方法，在方法内部用using包住所有可释放对象，这样并发调用也不会发生句柄串扰。
6. 在 10136 基础上二次扩展：模板变量替换的思路
既然会跑通这套源码，我顺便把自己做模板变量替换的思路写一下，算是给想要扩展的人一个参考。这套源码本身没提供类似“把{{Name}}替换成张三”的功能，需要在DocxDocument之上加一层。
6.1 简单变量替换的流程
我的做法是在读取全文后，先用正则找出所有{{key}}形式的占位符，然后把它们映射到一个字典：
var replacements = new Dictionary<string, string>() { { "Name", "张三" }, { "Amount", "12345.00" }, { "Date", "2025-01-15" } };然后重新遍历w:t节点，对InnerText做一次替换。这里有两个注意点：
- 如果单个
w:t节点的文本里可能只包含半个{{Name}}，比如文本被 Word 拆分成{{Na和me}}两个节点，那纯文本替换就会失效。复杂场景需要先把同段落里的多个w:t合并成一个字符串，替换后再把结果重新写回第一个节点，并清空其他节点。 - 替换后建议检查是否还有未匹配的
{{残留，如果存在，说明模板里有字段没喂数据，应该输出警告日志，而不是默默生成一份缺数据的合同。
6.2 为什么不要在字符串层面做全局替换
很多人会犯一个错误：把整个 document.xml 读成字符串，然后做全局Replace("{{Name}}", "张三")。大多数时候没问题，但如果文档里包含{{Name}}的同时还有同名文本出现在批注、脚注或内容控件里，你可能会替换掉不该替换的地方。更稳妥的做法是只遍历正文w:t节点所在的范围，或者至少把 document.xml 的 body 部分单独提取出来再操作。这套源码的架构天然支持“只对某个段落做处理”，所以基于DocxParagraph做替换比基于整个 XML 字符串安全得多。
6.3 日志记录与批处理增强
批量生成 500 份合同的场景下，必然需要一份清单记录哪些成功、哪些失败、失败原因是什么。我在这套源码外加了一个简单的GenerationReport类，每处理完一个文件就往 CSV 里写一行。格式类似：
源文件,输出文件,状态,耗时,备注 template.docx,contract_001.docx,成功,32ms, template.docx,contract_002.docx,失败,15ms,公司名含非法字符这种日志看起来朴素，但对后续排查非常有帮助。尤其是跑大批量任务时，没有日志就等于没有眼睛，出错了不知道错在哪一个文件上。
6.4 什么场景下建议停下来，改用专业库
二次开发到一定程度，你可能会发现自己的需求越来越复杂：要在文档中插入图片、做表格行列合并、添加书签、生成目录、设置页眉页脚不同显示规则。此时继续在 DOCXReadWrite 10136 基础上补代码，成本会指数级上升。我个人的判断标准是：
- 如果需要处理 5 个以上不同类型的模板，且每个模板内部都有嵌套表格和图片，直接上 OpenXML SDK。
- 如果只需要做纯文本字段替换和批量输出，DOCXReadWrite 这类轻量库 + 自己的模板层非常好用。
- 如果有跨平台需求且不限于 C#，python-docx 也是个很顺手的选择，适合快速验证想法。
这套源码适合作为“地基”理解 docx 的本质，也适合做中小规模的批处理工具。它在复杂排版面前会露怯，但这并不影响它作为一份教学源码和一个轻量文件读写库的价值。
7. 最后再分享几个我自己实践下来的小技巧
第一，做任何 docx 相关开发之前，先在环境里准备一个“最小复现模板”。不要拿一两百页的复杂合同做测试，而是用 Word 创建一个只有一行文字的 docx，另存为模板，所有实验都基于它。这样做的好处是：出问题后一眼能看出是代码逻辑问题，还是模板结构特殊导致的异常。我这次调试中文乱码时，就是拿最小模板反复试，才确认了是源码文件编码问题，而不是生成逻辑问题。
第二，把生成的 docx 用“压缩包方式”再解压一次，人工看一眼 document.xml 内容。这是最快定位格式问题的办法。比如 Word 打不开，先看[Content_Types].xml对不对；文本替换没生效，直接看w:t节点里到底存了什么。
第三，模板变量命名不要用中文。有些文档模板习惯用{{公司名称}}这种中文占位符，程序处理没问题，但编码如果不一致，很容易在模板保存环节出乱码。我更推荐用拼音或者英文字段名{{CompanyName}}，最后在日志和业务配置里维护一份字段名和中文含义的映射表，这样既安全又清晰。
DOCXReadWrite 10136 FS 这套源码我持续用了快一个月，从最初的怀疑“这能行吗”到后来的“效率真高”，中间踩了不少坑，也把 docx 的文件格式彻底吃透了。如果你手头正好有类似需求，希望这篇经验帖能让你少走一点弯路。
本文还有配套的精品资源，点击获取
