Java 中处理电子表格的实用概览

Java 遇上电子表格

Apache POI 作为 Java 读取和写入 Excel 文件的标准库已有二十多年历史。它能很好地处理大多数日常电子表格任务。但如今越来越多的真实 Excel 文件包含 POI 求值器完全无法执行的公式。

这是 Java 开发人员 在处理电子表格时会遇到的几种情况之一，这些问题往往要到真正进入生产环境后才会显现。业务用户使用电子表格生成、共享和分析数据。财务团队在 Excel 中建模。运营团队用 Excel 跟踪库存。分析师以 .xlsx 文件的形式将交付物交给工程团队。Java 应用程序最终要与所有这些交互：后台服务接收 Excel 上传，定价引擎运行最初在工作簿中编写的计算，报表工具以收件人能在 Excel 中打开且格式无问题的格式导出数据。

尽管这些情况非常普遍，但“Java + 电子表格”并不是大多数开发者第一次遇到之前会思考的话题。本文对这个领域做一个实用概述：常见场景、关键组成部分、可用的方案，以及一些容易让团队措手不及的坑。

视频 10音频 5音频 6访问广告商网站前往页面

三种常见场景

大多数使用电子表格的 Java 开发者都属于以下三种情况之一。在评估工具之前，先找准自己属于哪一类是值得的。

[LOADING...]

文件交换（无界面导入与导出）

应用程序读取上传的 Excel 文件并提取数据，或根据数据库内容生成 Excel 文件。应用中本身没有电子表格界面。这是最常见的情况。例子包括批量数据导入、报表生成，以及与期望接收 .xlsx 文件的第三方系统集成。

应用内计算（无界面公式求值）

应用程序使用电子表格风格的公式作为计算逻辑。业务用户在 Excel 中编写定价规则、税务公式或分配逻辑；Java 应用在运行时执行这些公式，有时针对的是用户从未见过的数据。该场景相对少见，但常见于金融科技、保险和企业资源规划（ERP）领域。

应用内编辑（嵌入式电子表格界面）

应用程序在浏览器中呈现交互式电子表格，类似于 Excel Online。用户可以在应用内查看、编辑和协作处理工作簿。这在报表工具、财务建模平台，以及任何需要让最终用户在不离开应用的情况下获得电子表格灵活性的应用中非常常见。

这三种场景的技术要求截然不同。适用于其中一种场景的库，未必适合另一种场景。

处理电子表格实际上涉及什么

开发者常常以为电子表格集成主要是读取单元格值。实际上，大多数生产环境中的问题来自原始数据之外的功能：公式求值、格式保真度、工作簿结构以及现代 Excel 行为。

文件格式：主流格式是 .xlsx（Office Open XML）。旧文件使用 .xls（二进制）。更简单的表格数据通常以 .csv 形式交换，但 CSV 会丢失公式、多工作表、格式和单元格类型。任何真正的电子表格集成都必须支持 .xlsx。

公式与公式求值：Excel 文件经常包含引用其他单元格的公式。读取文件时，你得到的是公式文本和上次缓存的值。重新计算公式需要一个理解 Excel 公式语言的求值器。不同库实现的函数范围差异很大。

现代 Excel 行为：Excel 365 和 Excel 2021 引入了动态数组公式、溢出（spill）行为，以及 UNIQUE、SORT、FILTER、LET、XLOOKUP 和 LAMBDA 等新函数。在动态数组公式中，单个单元格可以产生一个数组并“溢出”到相邻单元格。例如，在一个单元格中输入 =UNIQUE(A1:A100)，会生成该区域中所有去重值的完整列表，并按需填充多个单元格。在现代 Excel 中创建的文件经常包含这些结构。较旧的求值引擎通常无法执行它们。

单元格格式与样式：数字格式、日期格式、颜色、边框、条件格式、合并单元格。这些既影响准确读取（格式化为百分比的值与原始小数含义不同），也影响导出保真度。自定义数字格式（例如会计风格的负数括号表示）和 Excel 表格样式，是最容易在往返过程中丢失或改变格式的类型。

图表、图片和其他嵌入内容：有些库会在往返时保留这些内容，而另一些库则会静默丢弃。

数据验证、筛选器、表格和数据透视表：用户依赖的结构功能。不同库的覆盖程度差异很大。

并非每个应用都需要这些功能。一个只从固定模板读取数值数据的批处理任务几乎不需要什么。而一个允许用户上传任意工作簿并编辑的应用则几乎需要全部功能。

Java 中可以使用的方案

并没有一个单一的“Java Excel 库”。这个领域分为几类，每一类都有自己的取舍。

Apache POI

这是 Java 生态中无界面文件处理的事实标准。开源、成熟、使用广泛。支持 .xlsx 和 .xls 的读写，并内置公式求值器。POI 的公式求值器实现了大约 250 个内置函数；不在该列表中的函数在求值时会抛出 NotImplementedException。不支持动态数组公式和溢出行为。

一个最小的 POI 读取示例：

try (Workbook wb = WorkbookFactory.create(new File("data.xlsx"))) {
    Sheet sheet = wb.getSheetAt(0);
    Cell cell = sheet.getRow(0).getCell(0);
    System.out.println(cell.getStringCellValue());
}

瓶颈在于动态数组系列函数：SEQUENCE、FILTER、SORT、UNIQUE 和 TEXTSPLIT 在求值时会抛出 NotImplementedFunctionException，而且溢出区域在 POI 的单元格模型中根本没有表示。LET 更糟：POI 的公式语法不支持变量绑定概念，因此 LET 公式甚至无法解析：

// Cell A1 contains: =LET(total, SUM(B1:B100), total * 1.1)
FormulaEvaluator eval = wb.getCreationHelper().createFormulaEvaluator();
Cell cell = sheet.getRow(0).getCell(0);
eval.evaluate(cell); // threw: org.apache.poi.ss.formula.FormulaParseException:
                     // Specified named range 'total' does not exist in the current workbook.

文件本身可以正常打开，读取缓存值也正常。只有应用需要重新计算时，问题才会显现。（上述代码已在 POI 5.5.1 中验证。）

商业无界面库

像 Aspose.Cells 这样的产品提供了更广泛的公式覆盖、更好的格式保真度，以及对高级功能（图表、数据透视表、格式化）更完整的支持。它们通常按开发者或按部署授权。当 POI 的局限成为障碍且无法改写时，团队通常会选择这些产品。

嵌入式电子表格组件

像 Keikai（Java）和 SpreadJS（JavaScript）这样的产品会在浏览器中渲染交互式电子表格界面，并与后端协同。它们将文件 I/O、公式求值和渲染整合在同一个组件中。适用于最终用户需要直接查看和编辑工作簿的应用。

云端电子表格服务

Google Sheets API 和 Microsoft Graph 让应用可以完全将电子表格外包，并通过 REST 进行集成。电子表格存放在云服务中，Java 应用通过 API 读写。当工作簿本身就是用户关注的核心产物时，这样做效果很好；而当电子表格需要嵌入到更大的应用体验中时，效果就没那么好了。

这些分类也可以组合使用。常见的做法是使用 POI 进行后端生成，并使用一个单独的嵌入式组件来面向用户编辑。

如何选择方案

根据场景匹配合适的方案。

对于文件交换，可以从 Apache POI 入手。它是免费的、文档完善，并且适用于很大一部分导入/导出的使用场景。如果遇到特定限制，再转向商业无界面库：例如对现代公式求值、复杂格式保真度或大型工作簿性能的需求。

对于应用内计算，请仔细评估候选库的公式覆盖范围。如果需要运行的公式来自真实用户编写的真实 Excel 文件，它们会包含并非所有引擎都支持的函数。这正是动态数组和现代函数最关键之处：包含 LET 或 UNIQUE 的公式在不支持这些函数的库上无法正确求值。

对于应用内编辑，单靠 POI 是不够的，因为它没有用户界面。你需要一个在浏览器中运行的嵌入式电子表格组件，或者一个与之集成的云端电子表格服务。选择取决于电子表格需要与应用体验的集成紧密程度，以及用户数据是否可以离开你的基础设施。

这三种场景也可以叠加。同一个应用可能使用 POI 进行后端批量导入，使用无界面引擎进行业务规则的定时重算，并使用嵌入式组件提供最终用户编辑界面。

让团队措手不及的问题

有几个实际问题往往直到项目后期才暴露出来，但本应更早被发现。

[LOADING...]

公式覆盖并不统一。两个库可能都声称支持“Excel 公式”，但它们会在真实工作簿的不同子集上失败。现代函数（UNIQUE、SORT、FILTER、LET、XLOOKUP、LAMBDA）是最常见的短板。请使用实际文件验证，而不是用合成示例。

动态数组文件在不同引擎上的行为不同。在 Excel 365 中创作的包含 =UNIQUE(A1:A100) 的文件，根据库的不同，可能正确打开（显示缓存值）、无法重算，或抛出异常。如果你的应用需要重新计算上传的文件，这一点就很重要。

缓存值可能误导你。当库无法求值公式时，它往往会回退到文件中存储的缓存值。这会在开发期间掩盖问题，因为一切看起来都正确。只有当底层数据发生变化、公式需要重新求值时才会失败，而这通常发生在生产环境而非测试阶段。

格式保真度参差不齐。自定义数字格式、条件格式规则和合并单元格行为在不同库中的保留程度并不相同。如果你的工作簿需要返回给 Excel 用户，请务必使用业务方所用的确切模板明确测试往返过程。

内存与性能并非线性扩展。加载一个 100,000 行的工作簿与加载 1,000 行的工作簿是完全不同的问题。有些库会将整个工作簿以丰富的对象模型保留在内存中，应用通常会在几万行时开始遇到问题。另一些库则提供流式 API（写入使用 POI 的 SXSSF，读取使用 XSSF 事件模型），用对象模型换取可扩展性。如果你的场景涉及大型工作簿，请尽早进行基准测试。

结论

电子表格仍然是业务中使用最广泛的数据工具之一，而 Java 应用也越来越需要与它们交互。没有一种放之四海而皆准的方法——正确的选择取决于你是在交换文件、运行计算，还是嵌入电子表格 UI。近年来，可用的选项不断增多，尤其是对于需要处理现代 Excel 行为（如动态数组和更新的函数集）的团队。在选择库之前理解场景和关键组成部分，并使用真实用户生成的工作簿进行测试，将能在后续节省大量精力。

DZone 贡献者表达的观点均属于其个人观点。