GitHub上新出现一个MIT开源项目dom-docx，把语义化HTML片段直接转成原生可编辑的Word文档（OOXML），不是截图，也不是排版替代品。npm install dom-docx即可安装，要求Node.js 20以上，默认的inline转换路径是纯JavaScript，不依赖浏览器，也不依赖Playwright。
这类工具不算新鲜，但dom-docx把"可编辑结构"和"视觉回归打分"当核心卖点，而不是简单封装一个API。这对长期卡在报表导出、合同生成里"要么牺牲可编辑性、要么维护成本失控"的团队，是个值得看一眼的新选项。
发生了什么：可编辑优先，不是像素复刻
默认路径下，dom-docx能处理的元素挺完整：标题、段落、有序无序列表、表格、链接、内联加粗斜体。data:图片可以直接嵌入，页眉页脚、页码、目录也都支持。
生成出来的.docx打开后，用户能直接选中文字改，能调整表格列宽。这一点和截图方案完全不同——截图插进文档里的是一张图，改不了。
项目还做了一件其他转换库通常不做的事：用同一套测试harness，把自己和html-to-docx、@turbodocx/html-to-docx放在一起打分，维度包括视觉回归、结构保真度和可编辑性。这是项目自建的评测体系，不是独立第三方权威测评，但至少给出了一个可复现的对比框架，不只是甩一句"我们更好"。
为什么重要：报表、合同导出的老选择题
需要在系统里生成Word文档的场景很常见：财务报表导出、合同生成、后台管理系统的文档下载。过去开发者常见两条路：用Puppeteer截图或转PDF，牺牲可编辑性；或者用老式docx模板库拼字符串，灵活性差、维护成本高。dom-docx想切进这条缝里。
对前端和全栈开发者来说，如果产品要求"导出的Word能让用户直接改"，dom-docx值得拿来替换现有的Puppeteer截图方案先跑一遍测试，看结构保真度是否够用。对负责报表导出、合同文档预算的产品和技术负责人来说，更现实的动作是先圈定自己系统里HTML的复杂度——如果大多是表格加文字这种规整结构，迁移成本不高；如果涉及大量自定义布局，先别急着替换旧模板，等版本再成熟一些。
边界在哪：CSS grid、web字体、复杂图表过不去
当前版本v0.1.x有明确的能力边界，用表格看更清楚：
| 类别 | 支持 | 不支持（v0.1.x） |
|---|---|---|
| 文本结构 | 段落、标题、列表、内联加粗斜体 | — |
| 表格 | 基础表格 | rowspan |
| 布局 | — | CSS grid、float |
| 字体 | 系统字体 | web字体 |
| 图片 | data:图片直接嵌入 | 复杂SVG（路径、渐变） |
| 其他 | 页眉页脚、页码、TOC | 表单 |
换句话说，它优化的是"Word友好的语义化HTML子集"，不是完整网页的通用转换器。想把一整个带复杂布局的网页搬过去，大概率会失望。
还有一层容易被忽略的依赖关系：默认的inline路径是纯JS，但如果要用computed样式解析<style>和class选择器，Node端就需要装Playwright和Chromium。浏览器端的bundle可以直接读取页面的getComputedStyle，不用额外依赖。LibreOffice只出现在项目自己的视觉测试环节，跟实际转换过程没有关系。
如果文档里有大量图表或依赖web字体的复杂排版，默认路径转出来会失真，需要额外配置rasterizeInPlace并自行安装Playwright，成本比想象中高一些。
接下来值得盯的是两件事：项目能不能补上rowspan和更完整的CSS布局支持，以及它和html-to-docx、@turbodocx这些老项目在真实生产环境里的可编辑性差距是否经得起更多团队验证，而不只是自建的测试分数。
【锐评】工具易得，边界难破：能编辑不代表能通吃，量体裁衣才是正道。