Java数据导入导出核心是明确格式、边界与错误粒度：POI易OOM需流式读取，CSV须遵循RFC 4180并加BOM，导出需熔断校验与业务规则统一转换。
Java 中实现数据导入导出，核心不在于“用什么框架”，而在于「明确数据格式、边界场景和错误处理粒度」。Excel 是高频需求，但直接手写 POI 逻辑极易写出内存溢出、日期错乱、空指针或公式误读的代码；CSV 看似简单，却常因分隔符冲突、换行嵌套、编码不一致导致解析失败。
用 Apache POI 处理 Excel 导入时为什么 WorkbookFactory.create(inputStream) 会 OOM？
因为默认加载方式将整个 .xlsx 文件解压并构建 DOM 式对象树，10MB 文件可能占用 500MB 堆内存。尤其在 Web 环境中，多个并发上传极易触发 Full GC 或直接 java.lang.OutOfMemoryError: Java heap space。
- 改用
StreamingReader.builder().rowCacheSize(100).read(inputStream)（需引入excel-streaming-reader库），按行流式拉取，内存占用稳定在 MB 级 - 避免调用
cell.getStringCellValue()前不判空 ——cell为null时抛NullPointerException - 日期类型单元格必须用
cell.getDateCellValue()，而非先getStringCellValue()再 parse，否则返回的是 Excel 内部序列值（如44926.0） - 若模板含合并单元格，
Row.getCell(int)可能返回null，需配合Sheet.getMergedRegion()手动查找归属值
导出 CSV 时中文乱码、字段含逗号或换行怎么办？
本质是没遵循 RFC 4180 标准：字段必须用双引号包裹，内部双引号要转义为两个双引号，换行符必须在双引号内，且文件必须以 UTF-8 BOM 开头（否则 Windows 记事本默认用 GBK 解码）。
- 不要自己拼接字符串，用
OpenCSV的CsvWriter或Apache Commons CSV的CSVPrinter - 创建
OutputStreamWriter时显式指定StandardCharsets.UTF_8，并在首行写入\uFEFF（BOM） - 字段含双引号时，
CSVPrinter.print("他说\"Hello\"")会自动转义为"他说""Hello""" - 避免用
FileWriter—— 它默认使用平台编码（Windows 是 GBK），必然乱码
try (OutputStream os = response.getOutputStream();
OutputStreamWriter osw = new OutputStreamWriter(os, StandardCharsets.UTF_8);
BufferedWriter bw = new BufferedWriter(osw);
CSVPrinter printer = new CSVPrinter(bw, CSVFormat.DEFAULT.withFirstRecordAsHeader())) {
// 写入 BOM
bw.write('\uFEFF');
// 写表头和数据
printer.printRecord("姓名", "城市", "备注");
printer.printRecord("张三", "上海", "第一行\n含换行");
}
Spring Boot 项目中如何统一拦截导出请求并防止恶意大文件生成？
导出接口若无校验，攻击者可构造 ?limit=10000000 参数触发全表导出，拖垮数据库和 JVM。不能只靠前端限制，后端必须做硬性熔断。
立即学习“Java免费学习笔记（深入）”；
- 在 Controller 方法上加
@PreAuthorize("@exportAuthChecker.check(#params) == true")，自定义ExportAuthCheckerBean 校验用户角色 + 当前时间窗口内导出次数 + 查询条件是否含必要过滤字段（如tenant_id） - 使用
@Async将导出任务扔进独立线程池（ThreadPoolTaskExecutor配置maxPoolSize=3），避免阻塞主线程 - 导出前执行
SELECT COUNT(*)，若超阈值（如 10 万行）直接抛ExportLimitException并返回400 Bad Request - 生成文件后不存磁盘，而是用
ResponseEntity直接流式写回，避免临时文件清理遗漏
真正难的不是读写文件，而是把业务规则映射到每一行数据：比如导出订单时，“支付状态”字段要从 pay_status 整型转成“已支付/退款中/已关闭”，而导入时又要反向校验该文本能否映射回合法枚举值。这类转换逻辑一旦散落在各处，维护成本远高于 IO 本身。
