Stream聚合统计前须先定义POJO类明确数据结构，统一使用LocalDate/BigDecimal等类型，避免null和字符串解析问题；多维分组需预筛null并用SimpleImmutableEntry作键；导出用XSSFWorkbook+自动列宽与数字格式；参数须校验，SQL防注入，时间范围用左闭右开。
用 Stream 做聚合统计前先理清数据源结构
Java 报表统计不是堆代码，而是先确认原始数据能不能被 Stream 有效消费。常见错误是直接对 List<map object>></map> 做 groupingBy，结果字段名拼错、类型不匹配、null 值触发 NullPointerException。
推荐做法：封装成明确的 POJO 类（比如 SaleRecord），让编译器帮你检查字段和类型：
public class SaleRecord {
private String region;
private String product;
private double amount;
private LocalDate date;
// 构造、getter 省略
}
这样后续用 Collectors.groupingBy(SaleRecord::getRegion, Collectors.summingDouble(SaleRecord::getAmount)) 才稳定可靠。
- 避免用
Map或Object[]当主数据结构——字段无约束，运行时才暴露问题 - 日期类统一用
LocalDate/LocalDateTime，别用String存“2024-03-15”，否则排序、区间过滤全得手写解析 - 数值字段优先用
double或BigDecimal，不用String存“123.45”再Double.parseDouble()，容易抛NumberFormatException
Collectors.groupingBy 嵌套统计时注意键的可比较性与空值处理
做多维分组（比如按地区+产品统计销售额）时，groupingBy 嵌套写法很常见，但默认行为对 null 值不友好，且复合键需保证 equals/hashCode 正确。
立即学习“Java免费学习笔记（深入）”；
错误示例：groupingBy(r -> r.getRegion() + "-" + r.getProduct()) —— 一旦 region 或 product 为 null，拼出 "null-ABC"，语义错误且难调试。
正确做法：用 AbstractMap.SimpleImmutableEntry 或自定义轻量键类：
Map<SimpleImmutableEntry<String, String>, Double> result = records.stream()
.filter(r -> r.getRegion() != null && r.getProduct() != null)
.collect(Collectors.groupingBy(
r -> new AbstractMap.SimpleImmutableEntry<>(r.getRegion(), r.getProduct()),
Collectors.summingDouble(SaleRecord::getAmount)
));
- 务必加
filter预筛null字段，别依赖收集器兜底 - 嵌套
groupingBy（如groupingBy(region, groupingBy(product, summingDouble))）可读性高，但深层嵌套后取数麻烦，建议只到两层 - 如果要支持“全部”汇总行，单独用
records.stream().mapToDouble(SaleRecord::getAmount).sum()更直白，别硬塞进分组逻辑
导出 Excel 时别直接手写 XML 或用过时的 HSSFWorkbook
很多老项目还在用 HSSFWorkbook（.xls 格式），它不支持超过 65536 行，且内存占用大；而手动拼 .xlsx 的 XML 结构极易出错，连单元格合并都可能生成非法 ZIP 包。
当前稳妥方案是用 Apache POI 的 XSSFWorkbook（对应 .xlsx）配合 try-with-resources 控制资源：
try (XSSFWorkbook wb = new XSSFWorkbook();
FileOutputStream fileOut = new FileOutputStream("report.xlsx")) {
XSSFSheet sheet = wb.createSheet("Sales Summary");
// 写表头
XSSFRow header = sheet.createRow(0);
header.createCell(0).setCellValue("Region");
header.createCell(1).setCellValue("Product");
header.createCell(2).setCellValue("Total Amount");
// 写数据行（假设 result 是 Map<Entry<String,String>, Double>）
int rowNum = 1;
for (Map.Entry<SimpleImmutableEntry<String, String>, Double> e : result.entrySet()) {
XSSFRow row = sheet.createRow(rowNum++);
row.createCell(0).setCellValue(e.getKey().getKey());
row.createCell(1).setCellValue(e.getKey().getValue());
row.createCell(2).setCellValue(e.getValue());
}
wb.write(fileOut);
}
- 记得调用
sheet.autoSizeColumn(i)自动列宽，否则 Excel 打开全是“###” - 数值单元格建议显式设
CellStyle（如createDataFormat().getFormat("#,##0.00")），避免导出后显示为科学计数法 -
大数据量（>10 万行）别用 POI 写内存式工作簿，改用
SXSSFWorkbook流式写入
报表参数传入和 SQL 查询边界必须校验
实际项目里，报表常带时间范围、地区下拉等参数。如果前端传 startDate=2024-13-01 这种非法日期，后端不拦截，LocalDate.parse() 直接抛异常，整个报表接口挂掉。
关键动作就两条：
- 所有外部输入参数，在进入业务逻辑前，用
DateTimeFormatter.ISO_LOCAL_DATE解析并捕获DateTimeParseException，返回明确错误码（如400 Bad Request） - SQL 查询中禁止字符串拼接参数，一律用
PreparedStatement占位符；若用 MyBatis，确保<foreach>或@SelectProvider生成的 SQL 不含注入风险 - 时间范围查询务必加
endDate.plusDays(1)转成左闭右开区间（date >= ? AND date < ?），避免漏掉当天最后一秒的数据
复杂点在于：统计口径常随业务调整（比如“活跃用户”今天定义为“当日登录+下单”，明天加“且完成支付”），这类逻辑别硬编码在 Service 里，抽成策略接口 + Spring @Qualifier 注入，否则改一次就要测全量报表。
