润乾报表中数字字段超长被截断或显示为科学计数法

Question

在润乾报表中，当数据库字段（如BIGINT、DECIMAL(20,0)或超长整数ID）返回位数较多的数字（如18位以上）时，常出现两种异常：一是数值被截断为末尾若干零（如`123456789012345678`显示为`123456789012345000`），二是自动转为科学计数法（如`1.2345678901234568E17`）。该问题并非源于数据库或SQL，而是润乾默认将数值型单元格交由Java `Double`类型解析并渲染，而`Double`精度仅约15–16位有效数字，导致高精度整数丢失。尤其在导出Excel（.xls/.xlsx）或PDF时更为明显。常见于订单号、身份证号、金融流水号等业务场景。需通过显式设置单元格数据类型为`java.math.BigDecimal`、禁用自动类型推断，或改用字符串方式读取+格式化输出来规避——但若未在数据集定义或表达式中主动干预，系统极易“静默失真”，埋下数据一致性隐患。

Answer 1

```html

一、现象层：高精度数字在润乾报表中的“静默失真”表现

• 18位以上整数（如订单号123456789012345678）在单元格中显示为123456789012345000——末尾精度丢失；
• 导出Excel时自动转为科学计数法：1.2345678901234568E17，导致Excel双击编辑后永久性变为浮点近似值；
• PDF导出中数字渲染异常，部分字体引擎将大数截断或补零；
• 身份证号（18位）、金融流水号（20+位）、分布式Snowflake ID（19位）等业务主键频繁出现一致性偏差；
• 该问题在Web预览中可能“看似正常”，但导出即暴露——属典型的“渲染态 vs 导出态”类型鸿沟。

二、机理层：Java Double精度陷阱与润乾类型推断链路解析

润乾报表默认采用以下数据流转路径：

DB ResultSet → JDBC Type Mapping → 润乾 DataSet → 单元格Expression求值 → Java Double自动装箱 → 渲染/导出

关键瓶颈在于：JDBC驱动虽可返回BigDecimal（如MySQL Connector/J对DECIMAL/BIGINT的getBigDecimal()支持），但润乾未强制启用，而是依赖getObject()→Double.valueOf()的隐式转换链。IEEE 754双精度浮点仅保障约15–16位十进制有效数字，超出即触发舍入（如Math.round(123456789012345678d) = 123456789012345000）。

三、诊断层：快速定位是否落入Double陷阱的四步法

步骤	操作	预期结果（健康）	异常信号
① 查源字段JDBC类型	SQL中执行SELECT COLUMN_NAME, DATA_TYPE, NUMERIC_PRECISION FROM INFORMATION_SCHEMA.COLUMNS WHERE ...	DATA_TYPE=−5 (BIGINT) 或 3 (DECIMAL)，NUMERIC_PRECISION≥18	润乾日志未打印BigDecimal相关类型提示
② 检查DataSet定义	右键数据集 → “属性” → 查看字段“类型”列	显示为java.math.BigDecimal或java.lang.String	显示为java.lang.Double或空白（即auto-infer）
③ 验证表达式求值	在单元格写表达式：=toString(A1.getClass().getName())	输出class java.math.BigDecimal	输出class java.lang.Double
④ 导出后校验Excel	用POI读取导出文件：cell.getNumericCellValue()	抛IllegalStateException（因存储为文本）	返回1.2345678901234568E17且cell.getCellType()==NUMERIC

四、解法层：三层防御体系（配置→编码→架构）

1. 配置级防御：在润乾设计器中，为数据集字段显式指定类型
   字段属性 → 类型 → 选择 "java.math.BigDecimal"（非“自动”）；
2. 编码级防御：SQL中强制类型转换（兼容各数据库）
   SELECT CAST(id AS CHAR) AS id_str, CAST(amount AS DECIMAL(20,2)) AS amount_bd FROM t_order；
3. 架构级防御：自定义润乾扩展函数，屏蔽Double路径
   public static String safeId(Object obj) { return obj == null ? "" : obj.toString(); }，在单元格调用=safeId(A1)。

五、进阶实践：构建高保真ID处理流水线（Mermaid流程图）

flowchart LR
  A[DB Query] -->|ResultSetMetaData.getType\\n=Types.BIGINT/DECIMAL| B[JDBC Driver]
  B --> C{润乾DataSet配置}
  C -->|类型设为String| D[字符串直达渲染]
  C -->|类型设为BigDecimal| E[BigDecimal精确承载]
  C -->|未配置/设为Double| F[Double精度截断→失真]
  D --> G[Excel导出：CELL_TYPE_STRING]
  E --> G
  F --> H[Excel导出：CELL_TYPE_NUMERIC + 科学计数法]

六、避坑指南：5个被低估的细节

• ⚠️ “数值格式”设置无效：即使单元格设了“#,##0”格式，若底层是Double，格式化仅作用于已失真的值；
• ⚠️ 分组汇总加剧误差：对BigID做=sum(A1:A100)会先转Double再累加，误差放大；
• ⚠️ 参数传入也需类型对齐：SQL中WHERE id = ?，若参数用new Integer(...)，可能触发隐式long→double→long往返；
• ⚠️ Oracle NUMBER(38)需额外处理：其JDBC映射默认为BigDecimal，但润乾若未识别仍走Double fallback；
• ⚠️ 升级不等于修复：润乾V2023+仍默认auto-infer，必须人工干预字段类型定义。

七、验证清单：上线前必检的7项

1. 所有含ID/流水号/证件号的字段，在DataSet中类型列≠空且≠Double；
2. 导出.xlsx用Excel公式=ISTEXT(A1)验证关键列返回TRUE；
3. PDF导出后用Adobe Acrobat“复制文本”比对原始值；
4. 开启润乾日志级别DEBUG，搜索setCellType.*STRING确认文本写入；
5. 对含ID的分页报表，验证第1页与最后1页ID无连续性跳变；
6. 使用=len(A1)在报表内检查字符串长度是否恒为18/20；
7. 压测场景下，检查GC日志是否因BigDecimal创建引发Minor GC频次异常升高。

```