月末那场"通宵归档"

又到月底，某特检院的信息化办公室灯火通明。小陈是刚入职的系统管理员，他的任务是把本月所有已完成的电梯检验报告导出归档——一共 137 份。

他的操作流程是：打开 LIMS，找到第一份报告，点"导出"，等 Excel 加载完，另存为本地文件，然后回到系统，找到第二份，重复以上动作。每一份报告，光是"打开、等待加载、另存为、关闭"就要四步，137 份报告意味着 500 多次点击，整整一整天耗在这件机械重复的事上。中间点错、做漏、来回核对，更是家常便饭。

这不是个例。在检测行业，"月末手工归档"几乎是每家机构的保留节目。

---

批量导出：LIMS 绕不开的"刚需"

检测报告不是做完就完了，它最终要"交出去"。而交付的场景，往往不是一份两份，是批量：

• 月度归档：每月末，所有已完成报告需统一导出、打包、存入档案系统，供内部审计和资质评审调阅。

• 客户交付：大客户（如物业公司、地铁运营方）一次委托几十台上百台设备，报告要批量打包交付。

• 监管抽查：市场监管部门不定期抽查，要求机构在限定时间内提交指定批次的报告，迟交即违规。

这三类场景有一个共同特征：量大、时间紧、不能出错。手工逐份导出不仅效率低下，而且极易遗漏或重复。批量、自动化、服务端生成，不是锦上添花，而是 LIMS 系统的基本功。

---

传统方案的三重瓶颈

既然批量导出是刚需，为什么这么多机构还在"手工逐份导"？因为技术上确实难。常见的三种方案，各有硬伤。

瓶颈一：客户端 Excel COM 自动化。 不少老系统用 VBA 或 C# 调用本机 Office 的 COM 接口，模拟人工打开 Excel、填充数据、另存为。这种方式的天真之处在于——它假设客户端永远装着 Office，版本一致，且运行稳定。现实是，一个弹出的"兼容性提示框"就能让整个批处理卡死；Office 更新后接口签名变了，脚本直接报废。更致命的是，这种方案根本无法服务化，无法部署到服务器上集中处理。

瓶颈二：开源 POI / NPOI。 Apache POI 是 Java 圈处理 Excel 的经典开源库，NPOI 是其 .NET 版本。它们不需要安装 Office，纯代码操作 Excel 文件，看起来很美好。但检测报告不是简单的数据表——它有复杂的模板格式：多级表头、合并单元格、条件格式、图表，还有嵌入的自定义公式（比如我们在前几篇讲过的修约函数、数据校验公式）。POI 对这些高级特性的支持参差不齐，渲染结果与原模板"形似神不似"，审核时经常被打回。

瓶颈三：服务端跑桌面版 Excel。 有人在服务器上装了一套桌面版 Excel，通过程序驱动它批量处理。这在技术上能跑通，但在合规层面踩了红线：微软的 Office 许可协议明确禁止将桌面版 Office 用于服务端自动化。一旦被审计发现，面临的是许可证违规的法律风险。此外，桌面 Excel 并非为高并发设计，多线程同时调用极易崩溃、内存泄漏，稳定性堪忧。

---

SpreadJS + GcExcel：前后端同源的协同方案

如果说前四篇文章讲的都是 SpreadJS 在前端解决的问题——修约、校验、留痕、权限，那么到了"批量导出"这一步，前端已经完成了它的使命，接力棒必须交到后端。而这个后端的主角，就是 GcExcel。

GcExcel 是葡萄城推出的服务端 Excel 组件（同时提供 Java 和 .NET 版本），它的定位很纯粹：在服务器上，无需安装 Office，以纯代码方式批量生成、读取、修改 Excel 文件。听起来和 POI 类似？关键区别在于——GcExcel 与 SpreadJS 同源。它们来自同一个产品家族，底层对 Excel 格式的解析逻辑完全一致，模板格式 100% 兼容。这意味着前端 SpreadJS 设计的模板，后端 GcExcel 打开后不会出现任何"格式漂移"。

整个协同链路是这样的：

第一步，前端设计模板。 业务人员用 SpreadJS 设计器搭建检测报告模板——表头、公式、修约函数、数据校验规则、权限标记，全部所见即所得。模板设计好后，保存为 .sjs 或 .xlsx 文件，上传到服务端模板库。

第二步，后端批量填充。 用户在前端勾选要导出的报告（比如月度归档的 137 份），前端把选中的 ID 列表发给后端。GcExcel 在服务端逐一加载模板，绑定每份报告对应的业务数据，执行公式计算（包括修约等自定义函数），然后导出为最终的 .xlsx 文件。所有文件打包成 ZIP，一次性返回前端。

第三步，前端下载交付。 前端收到 ZIP 流，触发浏览器下载，用户得到一个包含全部报告的压缩包。整个过程，从点击"批量下载"到拿到文件，只需要几十秒。

这里最关键的价值不是"能导出"——POI 也能导出。关键是前后端同源带来的结果一致性。你在前端 SpreadJS 模板里定义的修约函数 ROUND_GB、你配置的条件格式、你精心调整的行高列宽，到了后端 GcExcel 那里，渲染结果和前端预览一模一样。没有"设计时是一个样、导出后变另一个样"的落差，不需要导出后再人工逐份核对。这就是"同源架构"的含金量。

---

一次 POST，拿回一个 ZIP

前端调用批量导出的逻辑非常精简：把勾选的报告 ID 数组 POST 给后端 /report/batch-export 接口，拿到一个 ZIP 二进制流，触发浏览器下载即可。真正的重活——模板加载、数据绑定、公式计算、格式渲染、打包压缩——全部在后端完成。前端的职责就是"选哪些报告"和"把结果存下来"，这种分工是合理的：前端做交互，后端做算力。

后端对应的接口同样简洁。核心接口 POST /report/batch-export，入参一个 ID 数组，出参一个 ZIP 流。此外还有两个辅助接口：GET /template/{id} 读取模板文件，POST /template/save 保存模板。模板文件以 .sjs 格式存储在服务端，既保留了 SpreadJS 的全部设计信息（包括权限标记、校验规则等元数据），又能被 GcExcel 无缝加载——这是前后端同源架构能跑通的关键一环。

---

真实案例：从 2 天到 20 分钟

某特检院此前采用客户端 Excel COM 方案做月末归档，每月安排 1 名专职人员花 2 天时间逐份导出，期间还经常因为 Office 弹窗卡死、模板渲染偏差而返工。引入 SpreadJS + GcExcel 协同方案后：

• 导出耗时：137 份报告，从 2 天缩短到 20 分钟以内，全部由服务端自动完成。

• 人力释放：原先的 1 名专职归档岗位被释放，转岗到数据质量审核等更高价值的工作。

• 格式一致性：导出报告与前端预览完全一致，审核返工率从月均 5-8 份降至零。

• 稳定性：服务端无 Office 依赖，连续运行半年未出现因导出导致的系统崩溃。

更重要的是，这套方案天然支持服务化。除了月末归档，客户批量交付、监管抽查等场景都可以复用同一个接口，只需传入不同的报告 ID 集合。一次建设，多处复用。

---

前端做交互，后端做算力

回望整个系列，前四篇——修约函数、数据校验、操作留痕、权限管理——解决的都是"交互层"的问题：怎么让业务人员在浏览器里高效、合规地填写和处理检测报告。而到了第五篇，场景切换到了"交付层"：报告做好了，怎么成批地、可靠地交出去。

这是两类完全不同的需求，需要不同的技术来应对。前端 SpreadJS 擅长的是交互——所见即所得的模板设计、实时的校验反馈、细粒度的权限控制。而后端 GcExcel 擅长的是算力——无 GUI 依赖的批量处理、高并发的文件生成、稳定可靠的格式渲染。把两者捏在一起的不是某一行代码，而是同源的底层架构：同一套 Excel 格式解析引擎，同一套公式计算逻辑，同一套自定义函数体系。

很多团队在选型时容易犯一个错误：前端用一个表格控件，后端用另一个 Excel 库，中间靠"格式转换"打补丁。结果就是模板改一次、导出效果跟着变一次，永远在对齐格式的路上疲于奔命。前后端同源的真正价值，是把这条路直接抹掉——你在前端设计的，就是你后端导出的。

工具的边界，决定了方案的边界。让前端做前端该做的事，让后端做后端该做的事，而让它们说同一种"语言"——这或许才是企业级表格处理的正确打开方式。