创业 3 年， 我们一直在迭代和优化 JitWord 文档解析引擎， 今天 Word 文档解析引擎终于迭代到了 4.0 版本。
我们对标测试了大量开源及商业化 Word 编辑方案，经过持续打磨，JitWord 的 Word 文档解析精度，已达到业界领先水平。
由于内容过长，干货过多，大家看之前建议先收藏～
接下来，我就和大家深度分析一下我们的 JitWord 解析引擎 4.0。
先聊聊背景
在【在线Word文档协同】赛道，有一个心照不宣的行业现状：几乎所有产品都宣称“完美兼容 Word”，但只要遇上一份带流程图、嵌入 Visio 图、复杂排版的专业文档，体验就会立刻“现原形”——流程图只剩第一个方框的文字，组织架构图整块空白，表格与图片位置跑偏，前端导入和服务端导入结果不一致，文档对比功能满屏误判。
这些问题我认为不是“小瑕疵”，而是底层解析能力的天花板。普通用户可能感知不深，但对工程、建筑、法务、国企等中高端客户而言，“内容丢失、排版失真”就是产品不可用的直接判定标准。
JitWord 从立项第一天起我们就认定：文档产品的核心竞争力，本质是解析精度的竞争力。过去几年，我们在文本段落、表格、公式、样式体系上已经做到行业第一梯队，但面对 Word 原生绘图画布、OLE 嵌入对象这两大“行业顽疾”，始终和同行一样受限于技术边界。
最近2个月，我们一直在攻克上面的难题。好在熬了几个通宵之后，我们终于完整攻克了 Word 原生流程图/组织图高精度还原、OLE 嵌入对象全格式兼容两大核心难题，同时完成了 Word 排版精度的精细化打磨，实现了“前端与服务端导入结果逐字节一致”。
我会站在架构师与创业者的双重视角，完整复盘 4.0 引擎的实现原理、技术难点、工程设计，以及我们为什么愿意投入大量精力去啃这块“冷门硬骨头”。
JitWord 文档解析引擎 4.0，欢迎用复杂文档直接验证导入效果
一、Word 解析的深水区：为什么复杂图形是全行业的痛点
在讲技术实现之前，我们先拆解一个本质问题：为什么市面上这么多文档产品，都做不好 Word 里的流程图和嵌入对象？
1.1 DOCX 不是“文件”，是一套完整的文件体系
很多人以为 DOCX 就是一个文档，实际上它是一个 ZIP 压缩包，内部由数十个 XML 文件、二进制文件、资源文件共同构成。文本、段落、样式只是其中最基础的部分，真正复杂的是绘图体系与对象嵌入体系。
我画了一张图方便大家理解：
目前业内的解析方案大致分为三类，各自都有无法逾越的短板：
•基于开源库二次开发：如 docx.js、python-docx、POI 等。这类方案只能覆盖标准文本、普通图片、简单表格，遇到 DrawingML 复杂图形、嵌套组合、OLE 对象时，要么直接丢弃，要么只能提取第一个文本框。这也是绝大多数中小厂商的现状。
•调用 Office COM 组件转码：通过服务端调用桌面 Word 进行转换，效果最接近原生，但缺点极其明显：部署授权成本高、并发性能极差、稳定性弱、无法与编辑器深度集成，只能输出图片或 PDF，完全无法支撑协同编辑场景。
•自研引擎但止步于“主流场景” ：少数头部厂商有自研解析能力，但普遍只覆盖 85% 左右的通用场景。复杂图形与嵌入对象用户占比低、开发成本高，从 ROI 角度被战略性放弃。
最终形成的局面是：所有人都在“平原地带”卷功能，没人愿意踏入“山地”啃硬骨头。但恰恰是这 15% 的“山地场景”，决定了产品能不能进入专业级市场，能不能真正替代桌面 Office。
1.2 两大核心顽疾：原生绘图与 OLE 嵌入
这次 4.0 引擎重点攻克的，就是 Word 里最常见、也最容易“翻车”的两类复杂内容。
第一类是 Word 原生绘图画布 / 图形组合。
用户通过“插入 → 形状 → 新建绘图画布”绘制的流程图、组织图、说明页，是职场人最常用的轻量绘图方式。它不依赖任何第三方软件，完全由 Word 自身渲染，文件内只存储形状的语义描述（位置、样式、文字），没有现成图片。
这类内容的解析难点在于：形状类型多达上百种、坐标嵌套变换复杂、主题色体系庞大、文字排版规则特殊，需要完整复现 Word 的绘图渲染逻辑。
第二类是 OLE 嵌入对象。
通过“插入 → 对象”嵌入的 Visio 图、Excel 表、附件图标、老式公式，在文件中以二进制原始数据 + 预览图的形式存储。其中预览图大量采用 WMF/EMF 微软矢量格式，浏览器原生不支持，业内也没有成熟可靠的开源转换方案，最终表现就是空白图、坏图。
除此之外，还有一个隐蔽但致命的行业通病：前后端解析不一致。绝大多数产品前端用 JS 解析、服务端用 Java/Python 解析，两套逻辑两套实现，导入结果必然存在差异。这直接导致文档对比、版本回溯功能产生大量误判，用户根本无法信任系统。
二、核心突破一：原生绘图画布无损还原——从“丢内容”到“像素级还原”
针对 Word 原生绘图画布与图形组合，我们的目标非常明确：宁可先不可编辑，也绝对不能丢内容。在编辑器尚未支持完整画布组件的前提下，通过自研绘图渲染引擎，将整张画布完整渲染为矢量图片导入，保证方框、箭头、文字、配色一个都不少。
最终实现在 JitWord 中，能高精度渲染绘图对象，如下图所示：
2.1 先搞懂：Word 绘图画布到底是怎么存的
DOCX 中的绘图基于 DrawingML 语言，内联在段落的 <w:drawing> 节点中。一张绘图画布的 XML 结构是典型的树状嵌套，如下图所示：
• 外层是位置锚点（内联或浮动），决定整张图在页面中的位置与环绕方式；
• 内部是图形容器 <a:graphic>，如果是画布或组合，就对应 <a:grpSp> 组合节点；
• 组合节点下可以嵌套任意数量的形状 <a:sp>、图片 <a:pic>、连接线，甚至子组合。
每个形状节点都携带了完整的属性信息：坐标与尺寸（EMU 单位）、变换矩阵（旋转/翻转/缩放）、填充与边框样式、文本框内容与排版属性。
这里面的技术坑远超想象：
1.坐标系统复杂：Word 采用 EMU（英制公制单位）作为基础单位，1 英寸 = 914400 EMU。组合内的坐标是相对组合左上角的局部坐标，嵌套多层组合就要做多次坐标变换，旋转、翻转还会涉及矩阵运算，一步算错就全盘错位。
2.形状种类繁多：Word 内置 180+ 种预设形状，从基础的矩形、菱形，到流程图专用的决策框、过程框，再到大括号、箭头等特殊形状，每种都有独立的几何路径公式。
3.主题色体系庞大：专业文档的形状颜色几乎都不是固定色值，而是引用文档主题色，还要叠加提亮、加深、透明度等变换，解析时必须先完整解析主题文件再做映射。
4.形状内文字排版特殊：文本框有独立的字号、字体、对齐方式、内边距，支持竖排、旋转，换行规则与正文不同，还涉及溢出裁剪。
2.2 我们的实现：五层架构的绘图渲染引擎
为了完整复现绘图画布效果，我们设计了独立的绘图渲染引擎，纯 TypeScript 实现，前后端共用，整体分为五层，如下图所示：
第一层：语义解析层
从 DOCX 的 XML 结构中完整提取绘图画布的所有节点，构建出内存中的绘图对象树：组合节点可嵌套子组合、形状、图片、连接线，每个节点携带完整的属性数据。
这一层的核心工作之一是主题色解析：先读取文档 theme1.xml 中的 12 种主题色及深浅变体，再将形状中的主题色引用（如 schemeClr val="accent1"）转换为实际 RGB 值，同时正确处理 tint（提亮）、shade（加深）、alpha（透明度）三种变换。
第二层：坐标统一层
这是整个模块最容易踩坑的部分。我们实现了完整的仿射变换矩阵计算体系，从最内层节点开始，层层向上应用组合的偏移、缩放、旋转、翻转，最终将所有形状的坐标统一到整张画布的全局坐标系中。
调试阶段我们踩过一个经典的坑：Word 形状旋转的默认中心点是形状几何中心，而很多开源实现默认是左上角，导致旋转后位置完全偏移。最终我们以 Word 导出的 PDF 作为“标准答案”，逐像素校准矩阵参数，才彻底解决坐标错位问题。
第三层：形状几何层
针对 Word 180+ 种预设形状，我们对照微软官方开放规范，逐个实现了几何路径生成器。每种形状都有对应的路径计算公式，确保轮廓、比例、圆角等细节与 Word 原生渲染高度一致。
除了基础形状，我们还完整支持了连接线（直线、折线、曲线）、箭头、大括号等流程图高频元素，以及虚线、端点样式等细节属性。
第四层：文本排版层
形状内的文本不能直接沿用正文排版逻辑，我们单独实现了一套轻量文本排版引擎，支持横排、竖排、任意角度旋转，支持字号、字体、颜色、行间距、对齐方式，同时模拟 Word 的自动换行与溢出裁剪规则。
为了保证前后端排版完全一致，我们没有依赖系统字体，而是内置了标准字体映射表与字宽估算模型。虽然受限于系统字体渲染差异，无法做到与 Word 100% 字位重合，但我们做到了前后端输出完全一致，且与 Word 的换行差异控制在 1-2 个字以内，肉眼几乎不可感知。
第五层：SVG 输出生成层
将渲染完成的所有元素转换为标准 SVG 矢量图。矢量格式保证了放大不失真，文件体积也远小于位图。
最后我们增加了一个场景化判断：如果组合内只有一个文本框，则仍然转换为可编辑的文本框组件，不转图片，保证简单场景的编辑体验；只有多元素的复杂组合才转为图片，并在导入报告中明确提示“该画布已作为图片导入，其中的形状与文字不可编辑”。
详细的流程架构设计如下图所示：
2.3 效果验证：11 张复杂图逐字节一致
我们用 4 份来自真实客户的投标文件与工程方案进行验证，包含 11 张复杂流程图，其中最多的一张包含 23 个步骤框、19 条箭头连线、4 个大括号与竖排标签。
对比结果显示：导入后的 SVG 与 Word 导出的 PDF 相比，方框、连线、箭头、括号的位置基本重合，文字位置与配色高度一致。这得益于前后端同构的架构设计，也是我们和业内绝大多数方案最核心的区别之一。
三、核心突破二：OLE 嵌入对象兼容与自研 WMF/EMF 矢量转换引擎
如果说原生绘图画布考验的是对 Word 绘图模型的理解，那么 OLE 嵌入对象考验的就是对微软 legacy 矢量格式的工程化能力。
3.1 OLE 对象的本质与行业困境
OLE 对象在 DOCX 中分为两部分：
• 原始二进制数据，存放在 word/embeddings/ 目录，只有对应软件（Excel、Visio 等）才能编辑；
• 预览图，存放在 word/media/ 目录，就是用户在 Word 页面上看到的样子。
网页编辑器无法运行第三方桌面软件，因此显示预览图是唯一可行的方案。但行业普遍卡在了预览图格式上：大量老文档、Visio 导出文档的预览图是 WMF 或 EMF 格式——这是微软 Windows 系统的原生矢量图格式，本质是 GDI 绘图指令的集合，浏览器原生完全不支持。
业内过往的解决方案都不理想：
• 用开源转换工具（如 wmf2svg、ImageMagick）：指令覆盖不全，形状错位、文字乱码、渐变阴影丢失是常态；
• 前端与服务端用不同方案：结果不一致，文档对比误判严重；
• 直接丢弃：显示空白占位图，用户体验毁灭性下降。
我们也曾尝试过基于开源方案改造，但效果始终达不到商用标准。最终团队做出决策：自研纯 TS 实现的 WMF/EMF 转 SVG 引擎。
3.2 为什么要自研？创业者的算账逻辑
很多人会问：WMF/EMF 是很老的格式，用户量不大，值得投入这么多人力自研吗？
站在创业公司的角度，我的判断逻辑是：
1.客户痛点真实且致命。工程、建筑、制造业客户的历史文档里充满了这类格式，遇到一次就是“产品不能用”的结论，直接丢单。
2.大厂不会做，就是我们的壁垒。大厂用户基数大，85% 场景覆盖就够了，这种长尾场景投入产出比太低。但对创业公司而言，把别人不做的事情做好，就是差异化竞争力。
3.技术有复利。今天做了 WMF/EMF 转换，未来可以延伸到更多矢量格式、更多 Office 专有格式，底层能力是可复用的。
3.3 自研引擎的三层架构
WMF/EMF 文件的本质是“绘图指令流”：文件由一条条 Record 组成，每条记录对应一个 GDI 绘图操作，比如设置画笔颜色、画矩形、输出文字、贴位图、设置裁剪区等。
我们的引擎做的事情，就是逐条解析这些指令，在 SVG 中完整“重放”出来，相当于用 TypeScript 实现了一个迷你 GDI 绘图层。
引擎整体分为三层，如下图所示：
第一层：二进制解析层
解析 WMF/EMF 文件头与指令流，逐条识别记录类型并解析参数。EMF 指令集远大于 WMF，还包含大量增强绘图指令。我们对照微软官方格式规范，完整实现了 30 多类核心绘图指令，覆盖了真实场景中 99% 以上的内容。
所有二进制解析都做了严格的边界检查，防止异常文件引发越界错误。
第二层：绘图状态机层
GDI 绘图是典型的状态机模式：当前画笔颜色、画笔宽度、字体、背景模式、裁剪区域、坐标变换矩阵都是全局状态，每条指令执行后更新状态。
我们完整维护了这套状态机，尤其重点实现了 8 种坐标映射模式（MM_ANISOTROPIC、MM_ISOTROPIC 等）。这是 WMF/EMF 最容易出错的地方——逻辑坐标与设备坐标的映射关系直接决定了图形的比例和位置，也是很多开源工具效果差的核心原因。
第三层：SVG 渲染层
将每条绘图指令对应转换为 SVG 元素：矩形转 、线条与多边形转 、文字转 、位图转 。
针对 Office 特有的视觉效果，我们做了大量专项适配：
• Visio 图形的阴影效果、渐变填充、透明背景；
• 特殊符号字体（希腊字母、数学符号）的映射与 fallback；
• 虚线样式、线帽、连接点的细节对齐。
3.4 一致性与安全：商用级引擎的必修课
作为服务端可匿名调用的基础能力，安全与稳定是底线。我们设计了多层兜底机制：
• 单张图片的绘图指令数量上限，防止恶意构造的无限循环指令；
• 单张图片尺寸上限与整篇文档图片总大小上限，防止内存耗尽；
• 所有资源分配都有熔断机制，异常文件直接降级处理，不影响整体服务。
同时，因为是纯 TypeScript 实现，前端浏览器与服务端 Node.js 运行同一套代码，转换结果逐字节一致。这不仅解决了 OLE 对象的显示问题，更重要的是彻底消除了前后端导入不一致导致的文档对比误判。
除此之外，我们还顺手修复了一个长期存在的“小顽疾”：服务端导入含嵌入对象的文档时，正文里会多出“false”字样。本质是旧解析器把 OLE 对象内部的一个布尔属性标记误当成了正文文本。4.0 引擎中我们严格区分了属性元数据与正文内容，导入内容彻底干净无冗余。
四、精度革命：拉开差距的，永远是细节
很多人觉得，导入只要内容不丢就够了。但我们始终认为：专业级产品与普通产品的差距，就藏在那些“说不出哪里不对，但就是看着别扭”的细节里。
4.0 版本除了两大核心功能，我们还对排版引擎做了一轮深度精细化打磨，解决了多个长期存在的精度问题。
4.1 图片与表格：位置尺寸更贴近原文
旧版本中存在几个高频反馈的排版问题：图片被强行放大导致比例失调、窄表格被拉满整页宽度、大面积流程图压住后续文字、导出 Word 后页序跑偏。
这次我们做了系统性优化：
•图片尺寸严格还原：按照 Word 记录的显示尺寸（EMU 转像素）渲染，薄图不会被强行放大，比例完全忠实原文；
•缩进继承：图片继承所在段落的缩进属性，列表中的图片不会再被“带偏”位置；
•表格宽度回归原始：窄表格默认按原表网格宽度显示，不再强制拉满页面，只有用户主动设置自适应时才拉伸；
•分节关系保留：大面积组合图形按正文内联图片占位，保留原文的分节与分页逻辑，导出 Word 后页序与位置不会跑偏。
还有一个非常细节的优化：组合图转图片时保留少量边缘余量。旧版本中圆角边框经常被裁掉一半，因为裁剪边界刚好卡着形状边缘。现在预留少量像素余量，圆角、阴影、外描边都能完整呈现。
4.2 混合字号段落：缩进、列表与行高的校准
这是一组非常隐蔽但严重影响排版质感的问题：
• 同一段落内字号大小不一时，首行/悬挂缩进按错误字号换算，导致右栏文字偏移；
• 带大首行缩进的版面段落，被误判为上一条列表的续段，缩进被列表样式覆盖；
• 混合字号的标题（如 24pt 序号 + 16pt 标题文字）行高按小字号计算，大号文字顶部被裁切。
我们的优化思路是：
1.缩进计算基准修正：首行/悬挂缩进不再按段落默认字号计算，改为按段落开头首个内容（文字或图片）的字号计算，大字号开头的段落缩进量从此准确。
2.列表归属判断重构：从“按缩进量猜测”改为“优先按编号标记判断”，带大首行缩进的独立段落不会再被误并入上一条列表。
3.标题行高算法升级：行高按段内最大字号计算，并对齐整数网格行，大号序号与文字都能完整显示，同时保证与周边内容的对齐关系。
这些优化没有任何捷径，就是对着几十份真实文档，逐行对比、逐像素调试。但正是这些细节，让用户打开文档时会下意识觉得“这个编辑器很专业”。
五、工程架构复盘：前后端同构，是我们的核心护城河
讲完功能实现，我想聊一聊更底层的架构设计，下面是我们的核心架构思想：
JitWord 解析引擎从第一天起就坚持前后端同构——所有解析、渲染逻辑全部用 TypeScript 编写，前端浏览器与后端 Node.js 最大限度复用一套代码。
5.1 为什么坚持同构？
业内很多团队会质疑：服务端用 Java 或 Go 性能不是更好吗？为什么要用 JS？
我们的答案是：对文档协同产品而言，一致性远比峰值性能更重要。
如果前端一套逻辑、服务端一套逻辑，必然会出现无数细微差异：导入结果不一样、导出结果不一样、样式计算不一样。最终文档对比、版本回溯、多人协同都会出现大量误判，用户根本无法信任系统。
而同构架构从根源上解决了这个问题：同一套代码，同一个结果。前端验证通过的能力，服务端直接就能用，不会出现“前端好好的，服务端导入就坏了”的割裂感。
其次是研发效率。一套代码开发、一套代码测试、一套代码维护，团队不用重复造轮子，迭代速度翻倍。这次 4.0 的两大核心模块，我们只开发了一次，就同时解决了前端导入与服务端导入两个场景的问题。
5.2 三层测试体系：保证引擎稳定可靠
底层引擎最怕的就是“改一个 bug 引出十个新 bug”。为此我们建立了完整的三层测试体系：
1.单元测试：覆盖每个形状、每条 WMF 指令、每个排版算法，正常场景与边界场景全覆盖；
2.集成测试：针对典型文档模板，验证整体解析结果的完整性与样式正确性；
3.端到端快照测试：我们维护了一个数百份文档的测试集，覆盖各行各业的典型复杂场景。每次代码变更都会自动跑完全量文档，对比输出快照，一旦出现差异立即告警，从机制上杜绝回归问题。
这次 WMF/EMF 引擎开发中，我们专门生成了覆盖 30 多类绘图指令的专项测试文件，逐项核对位置、形状、颜色；同时以 Windows 系统原生绘制结果作为标准答案逐张对比，确保转换精度达到商用标准。
六、创业者视角：为什么我们要啃这些“冷门硬骨头”
作为从大厂出来的AI创业者，我经常被问到：为什么不追 AI 热点，非要死磕这些底层又冷门的解析技术？
借这篇复盘，我也想分享几个我们团队的底层思考。
6.1 文档赛道的终局，是解析能力的竞争
现在在线文档产品看起来功能都差不多：协同编辑、AI 润色、模板库、权限管理。但这些都是“上层建筑”，真正的地基是文档解析能力。
普通个人用户可能感知不到差异，但企业客户尤其是中大型客户，选型时第一件事就是拿自己最复杂的文档去试导入。导入进去内容全丢、排版全乱，AI 再花哨也没有用。
对 JitWord 而言，我们的目标客户是对文档质量有高要求的企业与组织。这就决定了我们必须把解析能力做深、做透，而不是停留在“能用”的层面。
地基不牢，地动山摇。上面的功能再热闹，地基不行，产品就立不住。
6.2 大厂的盲区，就是创业公司的生存空间
这么难的技术，大厂为什么不做？不是做不出来，是投入产出比不划算。
大厂面向亿级大众用户，覆盖 85% 的主流场景就足够了。剩下 15% 的复杂专业场景，用户量少、开发成本高，从战略优先级上排不到前面。
但对创业公司来说，这 15% 就是我们的机会。
我们服务的很多工程类、国企客户，就是因为大厂产品导入不了他们的投标文件、施工流程图，才找到了我们。我们把这些别人不愿意做的场景做到极致，就能在细分市场站稳脚跟，建立口碑。
而且底层技术是有复利的。今天我们做了绘图画布渲染，明天就可以做可编辑画布组件；今天做了 WMF/EMF 转换，明天就可以延伸到更多格式。这些沉淀下来的技术，就是别人短期内抄不走的护城河。
6.3 产品决策复盘：先“有”再“好”，拒绝完美主义
这里也想复盘一个具体的产品决策：这次我们选择把流程图转成图片导入，而不是直接做成可编辑组件。
内部讨论时也有不同观点：有人觉得可编辑体验更好，应该一步到位。
但我们最终还是选择了“先完整显示，再逐步可编辑”的路径，原因有三点：
1.用户刚需是“不丢内容” 。大部分用户导入文档，核心诉求是内容完整、能正常阅读和修改正文。流程图只要在就行，真要编辑可以回 Word 里改。
2.可编辑画布开发周期极长。相当于在网页里做一个迷你 Visio，没有半年以上做不出来。让客户等半年，黄花菜都凉了。
3.先上线再验证需求。先快速解决最痛的问题，再观察真实用户中有多少人需要编辑流程图，再决定下一步投入多少资源，避免过度开发。
创业不是做学术，不能追求完美主义。先交付核心价值，再快速迭代，才是正确的节奏。
6.4 做难而正确的事
创业这几年我最深的体会就是：捷径往往都是最远的路。
如果当初图省事，用开源库凑一凑，调用 Office 组件转一转，我们也能很快做出一个看起来差不多的产品。但一遇到复杂场景就露馅，客户口碑起不来，永远只能在低端市场内卷。
我们选择从零开始自研解析引擎，前期走得慢一点，踩的坑多一点，但越往后走路越宽。
这次 4.0 迭代，两个核心模块前后打磨了两个多月。团队啃完了上百页微软技术文档，对着像素调了无数版坐标矩阵，反复测试了上百份真实文档。
但上线后收到客户反馈：“终于能正常导入我们的投标文件了，之前用别的产品流程图全没了。”
那一刻就觉得，所有的付出都值得。
对创业公司来说，最好的壁垒，从来不是什么炫酷的概念，而是你比别人更愿意下笨功夫，更愿意把用户的痛点当回事。
七、未来展望：从“无损导入”到“往返编辑”
4.0 不是终点，只是 JitWord 在复杂图形解析上的第一步。接下来我们已经规划了更长远的路线：
1.可编辑绘图画布组件：目前已经启动预研，未来导入的流程图可以直接在编辑器内修改文字、拖动形状、调整连线，无需再跳转回 Word。
2.导入导出往返保真：现在导出 Word 时流程图是图片形态。未来我们会将原始绘图数据写回 DOCX，实现“导入 → 编辑 → 导出”之后，回到 Word 仍然是可编辑的原生形状。
3.OLE 对象深度支持：针对嵌入的 Excel 表格等常见对象，探索转换为编辑器可编辑表格的可能性，进一步提升编辑体验。
4.持续打磨排版精度：分栏、页眉页脚、批注、修订记录等场景，我们都会逐个攻克，不断缩小与桌面 Office 的差距。
我们的目标很明确：做国内最好的 Word 解析与编辑引擎，让专业用户真正可以放心地把工作搬到线上。
写在最后
做底层引擎是一件挺枯燥的事。没有光鲜的概念，没有爆炸的功能，就是对着 XML、对着二进制、对着像素，一点点抠细节。
但我始终相信，技术的价值就藏在这些看不见的地方。
从 1.0 到 4.0，JitWord 一步步把 Word 解析的天花板往上推。我们走得不快，但每一步都踩得很实。
感谢所有客户和用户的反馈，是你们的真实痛点推着我们不断往前走。也欢迎所有对文档技术感兴趣的朋友，和我们一起交流探讨。
路还很长，我们继续死磕。
