Hucre：零依赖、MIT 协议的 TypeScript 电子表格引擎
阅读时间: 大约 8 分钟
Hucre：零依赖、MIT 协议的 TypeScript 电子表格引擎
在浏览器与 Node 端读写 Excel，过去十几年几乎是 SheetJS（前身 js-xlsx）一家独大的市场。但 SheetJS 近年来把读写样式、条件格式、图片等能力收进付费 Pro 版，并从 npm 官方仓库撤下、改为 CDN tarball 分发，给了后来者一个缺口。Hucre 就是这个缺口里长出来的项目：纯 TypeScript、零外部依赖、MIT 协议，宣称能读写 XLSX、CSV、ODS、JSON/NDJSON、XML。本文基于其 GitHub README 的一手数据，做一次克制的拆解。
一、为什么需要新一个电子表格库
Koala 的点评点出了背景：SheetJS 长期统治该领域，但免费版能力残缺、分发渠道不友好；ExcelJS 功能全但体积大（README 称约 500KB gzip）、CommonJS 模块、不支持 edge runtime。Hucre 的差异化非常明确——小、零依赖、原生 ESM/TypeScript、能跑在 edge worker 上。
它自带 SAX 式 XML 解析器与 ZIP 引擎（这正是「零依赖」的工程代价：不把 pako、sax 这类老牌依赖搬进来，而是自己实现），gzip 后按你引入的模块大小计费。
二、体积与分发：按模块 tree-shake
Hucre README 给出了一组用 pnpm size 实测、并用 rolldown 打包、钉在 scripts/size-budget.json 里（超标 CI 直接失败）的体积数字（minified + gzip）：
| 引入内容 | 体积（gzip） |
|---|---|
仅 { parseCsv, writeCsv } from hucre/csv | 3.7 KB |
仅 { readXlsx } from hucre/xlsx | 34 KB |
{ readXlsx, writeXlsx } | 68 KB |
整个库 export * from "hucre" | 129 KB |
README 还很诚实地补了一句：之所以把这四个数字写进文档，是因为「之前写的 2.3 / 32 / 64 / 114 KB 在当时是真的，但当时没有任何机制 enforce，后来漂移了」——现在有 size budget 兜底。这种把「为什么要有这条数字」也写出来的做法，在开源项目里少见，可信度较高。
三、与同类的对比（README 官方口径）
在 TS 生态内，README 把自己与 SheetJS CE、ExcelJS、xlsx-js-style 并列，关键差异：
| 维度 | Hucre | SheetJS CE | ExcelJS |
|---|---|---|---|
| 依赖数 | 0 | 0* | 9 |
| gzip 体积 | 4–129 KB（tree-shake） | ~300 KB | ~500 KB |
| ESM 原生 | 是 | 部分 | 否（CJS） |
| TypeScript | 原生 | 后补 | 后补 |
| Edge runtime | 支持 | 不支持 | 不支持 |
| 样式/条件格式/图片 | 免费可用 | 仅 Pro 付费 | 可用 |
| npm 发布 | 是 | 否（已撤到 CDN） | 停滞 |
*README 注明：SheetJS 已从 npm 撤下，必须从 CDN tarball 安装。
跨语言对比里，Hucre 的位置也很清楚：它不做公式求值（Apache POI 是表里唯一支持公式计算的），透视表只写骨架（pivot cache 与布局，但不预算结果单元格，靠 Excel 首次打开时填充）。
四、官方自己标注的口径偏差与能力边界
这一节是 README 最有价值的部分——它用脚注把「支持」两个字拆开讲：
条件格式 13 种类型：cellIs、colorScale、dataBar、iconSet、各种文本/空值/重复值规则都能读写；但 top10 与 aboveAverage 只在默认形态下往返（写出时不发 rank/percent/stdDev 属性），timePeriod 规则读入时直接丢弃。
ODS 往返是有条件的：值、公式、合并单元格可完整往返；单元格样式只覆盖六个面（粗体、斜体、字号、字色、背景色、数字格式）；边框、对齐、列宽、冻结窗格、数据验证、命名区域、图片、页面设置双向都不建模——所以「ODS→ODS 无损」成立，但「XLSX→ODS 会丢掉这些东西」。
「Round-trip 保留」不等于「我都懂」：Hucre 的卖点之一是往返编辑时不丢失它不直接处理的内容（图表、宏等被原样保留）。但要注意，「保留」和「理解并可修改」是两回事——很多元素它是原样塞回包里，而不是解析成可操作的对象模型。
无公式求值：读进来的是公式字符串，不会替你算结果；需要计算的场景仍得靠 Excel/POI。
五、适用与不适用场景
适合： 运行在 edge worker / Cloudflare Workers 上、对体积敏感的表格导入导出服务；只需要 CSV/XLSX 读写、不想为样式和样式付费的 Web 应用；需要在浏览器端流式处理大文件（双向流式读写）的场景；重视 MIT 协议与原生 TypeScript 类型的团队。
不适合： 需要在服务端求值 Excel 公式的场景；重度依赖 ODS 完整样式（边框/对齐/列宽）互转的项目；需要 top10/aboveAverage/timePeriod 条件格式完整保真的报表；把它当浏览器端 Excel 替代品做富编辑的用户——它是「引擎/库」，不是「在线表格」。
六、客观分析：优势与局限
优势： 零依赖 + MIT + 原生 ESM/TS + edge 可用，在 SheetJS 收缩后确实补上了生态空白；体积小且有 CI size budget 约束；往返保留思路对「导入→小改→导出」类流程友好；README 把局限写得非常坦诚。
局限： 项目年轻（v1.1.0、月下载约 14 万，与 SheetJS 存量差距巨大）；ODS 与若干条件格式规则是「半支持」；无公式求值；透视表只写骨架；生态与踩坑案例还在积累。
七、它意味着什么
Hucre 代表的是一种「小而专」的开源打法：不去追全功能在线表格，而是把「在任何 JS 运行时里轻量、合法、往返地读写表格文件」这一件事做到极致。对受够了 SheetJS 付费墙与 npm 缺位的前端团队，它是一个值得放进技术评估矩阵的新选项——但落地前，务必按第四节的边界清单核对自己的文件里是否有它「不建模」的那几类元素。