callable保障异构数据映射不缩水的核心是精准控制参数类型投递的语义边界，需用setobject()显式声明sql类型、统一布尔语义、配合元数据校验、规范null传递，避免隐式转换导致精度丢失或类型错配。
用 Callable（特别是 ICallableStatement）保障异构系统间数据映射不缩水，核心不是“调用存储过程”，而是**精准控制参数类型投递的语义边界**。当 Oracle 的 NUMBER(10,2)、PostgreSQL 的 NUMERIC、Hive 的 DECIMAL(18,6) 都要映射到目标端一个 FLOAT 字段时，直接传原始 Java Double 会丢失精度或触发隐式截断——setObject() 的显式 SQL 类型声明，就是守住这个边界的最后一道闸。
明确指定 SQL 类型，堵住隐式转换漏洞
Java 对象到数据库类型的默认映射（如 Double → DOUBLE）在异构环境下极易失准。必须用带 sqlType 参数的 setObject() 强制对齐源端语义：
-
stmt.setObject("amt", new BigDecimal("12345.67"), Types.DECIMAL, 6);—— 显式声明为 DECIMAL 并保留 6 位小数，避免被驱动转成 FLOAT 后变成12345.670000000001 -
stmt.setObject("status_code", "A", Types.CHAR);—— 把字符串 "A" 当作定长字符传，而非默认的 VARCHAR，防止目标端因长度推导错误导致截断或补空格 - 对时间字段，优先用
java.time.Instant+Types.TIMESTAMP_WITH_TIMEZONE，比Date更可靠兼容 PostgreSQL 的TIMESTAMPTZ或 Oracle 的TIMESTAMP WITH TIME ZONE
针对布尔/状态码做语义归一化预处理
异构系统里 status=1（MySQL）、status='Y'（DB2）、is_active=true（Mongo via CDC）都可能表示“启用”，但目标数仓只接受 BOOLEAN。不能依赖数据库自动转换：
- 在调用
setObject()前，统一转成 JavaBoolean：Boolean isActive = "1".equals(srcStatus) || "Y".equals(srcStatus) || Boolean.TRUE.equals(srcStatus); - 再执行：
stmt.setObject("is_active", isActive, Types.BOOLEAN); - 避免把字符串 "1" 直接传给
setObject("is_active", "1")，某些驱动会按字符串存，下游消费时报类型不匹配
配合元数据校验，验证映射是否真正落地
光写对 setObject() 不够，还要确认目标端实际接收并存储的类型与预期一致：
- 执行前查目标表 DDL：
SELECT data_type, numeric_precision, numeric_scale FROM information_schema.columns WHERE table_name='target_table' AND column_name='amt'; - 插入后立刻反查：
SELECT pg_typeof(amt), amt::text FROM target_table WHERE id = ?;（PostgreSQL 示例），确认物理存储类型未被悄悄降级 - 对关键字段加质量断言：比如插入
BigDecimal("999.999")到DECIMAL(5,2)字段，应捕获SQLDataException而非静默截断为999.99
避开 null 传递陷阱，保持跨平台一致性
不同数据库对未指定类型的 null 处理差异极大：Oracle 允许 NULL 作为任何类型占位，而某些国产库要求必须声明类型才能接受 null：
- 永远不用
setObject("col", null)，改用setNull("col", Types.VARCHAR)或setObject("col", null, Types.DECIMAL) - 若字段可为空且类型动态，先从源元数据获取其 SQL 类型码，再传入
setObject(name, null, sqlType) - 测试环节专门构造全 null 记录同步，验证目标端字段值、类型、约束是否与源端完全对齐
