XSSFWorkbook易OOM因构建全量DOM树，而事件驱动（SAX）仅流式解析、内存仅数百KB；必须用XSSFReader+SharedStringsTable+StylesTable三件套，且顺序与初始化时机严格受限。
为什么 XSSFWorkbook 一读就 OOM，而事件驱动能扛住 GB 文件
因为 XSSFWorkbook 把整个 .xlsx 解压后构建成 DOM 树——一个 200MB 的 Excel 文件，内存占用轻松突破 1.5GB。而事件驱动（SAX 模式）不建树、不缓存全量数据，只在解析到某行某单元格时触发回调，内存常驻仅几百 KB。它本质是把 Excel 当作 ZIP + XML 流来处理，靠 XSSFReader 和自定义 DefaultHandler 驱动解析流程。
必须用 XSSFReader + SharedStringsTable + StylesTable 三件套
缺一不可，否则会丢文本、错格式、甚至解析失败：
-
XSSFReader是入口，负责打开 OPCPackage 并获取 sheets.xml 和 sharedStrings.xml 的流 -
SharedStringsTable存所有字符串字面值（Excel 为节省空间会把重复字符串统一索引），不传它，t标签里的内容就拿不到真实值 -
StylesTable提供单元格样式和数据类型（如日期、数字格式），不用它，所有单元格都默认当字符串，DateUtil.isCellDateFormatted(cell)这类判断直接失效
注意：不能用 OPCPackage.open(file) 直接传文件路径，要传 FileInputStream 并确保未被其他线程关闭；SharedStringsTable 必须在 XSSFReader 实例化后立即构建，顺序错了会导致空指针。
tidy-excel-data
下载
清理、标准化、验证并汇总杂乱的 Excel 工作簿。当 Codex 需要处理 `.xlsx`、`.xls`、`.xlsm` 或 `.csv` 格式的数据时使用，包括：统一表头格式、删除空白行与空白列、修剪文本内容、去重记录、检测数据质量问题、拆分或合并工作表、生成清洗后的工作簿，以及为业务电子表格生成审计摘要。
解析时 cell 类型判断和值提取最容易出错
Excel 单元格的 s（style index）、t（type）、v（value）三者组合决定最终内容，常见坑点：
- 数值型单元格没有
t属性，但v里存的是浮点数原始值（如日期存为 44562.0），需用DateUtil.getJavaDate(double)转换 - 字符串型单元格带
t="s"，此时v是 shared-strings 表的索引，必须查SharedStringsTable获取原文本 - 公式单元格带
t="str"或t="n"，但v是计算结果，不是公式本身；若需原始公式，得额外监听f标签 - 空单元格可能无
v标签，也无t，此时应返回 null 或空字符串，别强行 toString()
示例片段：
if ("s".equals(nextDataType)) {
String s = stringsTable.getItemAt(Long.parseLong(value));
row.add(s != null ? s : "");
}
性能关键：禁用自动格式推断 + 关闭样式继承链
POI 默认会尝试从样式表向上追溯父样式，对超大 sheet 来说，这会引发大量无效对象创建。必须显式关闭：
- 构造
XSSFReader后，调用reader.setStylesTable(null)是错的——会导致样式丢失；正确做法是传入精简后的StylesTable，并确保其内部未启用isStyleInheritanceEnabled - 禁用数字格式自动识别：
dataFormatter = new DataFormatter(Locale.ROOT); dataFormatter.setUseCachedValuesForFormulaCells(false);，避免缓存污染 - 不要在 handler 的
startElement里做任何 IO 或复杂对象构建，所有业务逻辑延后到整行收尾（endElement触发row完整时）再处理
真正压测下来，单核 CPU 处理 100 万行耗时约 8–12 秒，内存峰值稳定在 30–60MB。最易被忽略的是 SharedStringsTable 构建时机和 StylesTable 的裁剪粒度——这两个没控好，哪怕用了事件模式，照样 OOM。
