dto不能一上来就全字段初始化，因传感器/日志等数据字段多、解析开销大（如base64解码）、依赖上下文校验，且含大量非法值；全量反序列化易中断整批处理。
构造方法引用本身不支持“迟延初始化”，但结合 构造方法重载 + 工厂方法 + 懒加载语义，可自然实现大数据清洗中 DTO 的按需初始化——即只在真正需要某字段时才解析、转换、校验，避免全量反序列化与冗余计算。
聚焦清洗场景：为什么 DTO 不能一上来就全字段初始化？
工业传感器数据、日志流、多源 CSV 等清洗输入常具备以下特征：
- 单条记录字段数多（如 50+ 列），但每次清洗逻辑仅关注其中 3–8 个关键字段（如 temperature、timestamp、device_id）
- 部分字段解析开销大（如 base64 图像字段解码、JSON 嵌套结构 flatten、正则地址提取）
- 字段有效性依赖上下文（如“告警等级”需结合“设备型号”查规则表，不应在构造时硬编码）
- 原始数据含大量 null/空字符串/非法格式，全量强转易抛异常，中断整批处理
用构造方法重载定义清晰的初始化入口
不提供“全参构造器”，而是按清洗阶段意图设计轻量构造入口：
- new CleanRecord(rawLine)：仅保存原始字符串或字节数组，不做任何解析 —— 适用于预过滤、行级采样
-
new CleanRecord(header, values)：按列名映射构建弱类型 record，字段值为 String 或 Optional
—— 适用于 Schema-aware 清洗（如 GroovyTransformer 中调用） -
new CleanRecord(Map
rawMap) ：接受已初步解析的 Map（如 JSON 解析后），跳过文本解析环节 —— 适用于上游已做基础 ETL 的场景
所有构造器均通过 this() 委托至私有全参构造，但该构造器仅设 final 字段 final String raw; final Map<string object> parsed;</string>，不触发任何字段解析逻辑。
用 getter + 双检锁实现字段级懒加载
每个业务字段封装为带缓存的 getter，首次调用时才执行清洗逻辑：
public BigDecimal getTemperature() {
if (temperature == null) {
synchronized (this) {
if (temperature == null) {
temperature = parseTemperature(raw); // 含异常兜底：返回 null 或默认值
}
}
}
return temperature;
}
优势明显：
- 清洗算子（如 DataX 的 GroovyTransformer）可自由调用
record.getTemperature()，无需关心是否已解析 - 若某批次数据根本不含温度相关逻辑，
parseTemperature永远不会执行 - 异常隔离：单个字段解析失败（如非数字字符串）不影响其他字段使用
配合 Builder 模式支持动态清洗策略注入
当清洗规则需运行时决定（如根据数据来源选择不同脱敏算法），构造器本身不宜承载策略参数。此时采用静态工厂方法 + Builder：
public static CleanRecordBuilder from(String raw) {
return new CleanRecordBuilder(raw);
}
public static class CleanRecordBuilder {
private final String raw;
private TemporalAdjuster timeAdjuster = ...;
private Function<string string> idNormalizer = s -> s.trim().toUpperCase();
CleanRecordBuilder(String raw) { this.raw = raw; }
public CleanRecordBuilder withTimeAdjuster(TemporalAdjuster adj) {
this.timeAdjuster = adj; return this;
}
public CleanRecord build() {
return new CleanRecord(raw, timeAdjuster, idNormalizer); // 传入策略，由内部 getter 使用
}
}</string>
这样，DTO 初始化既保持了构造语义的清晰性，又把动态行为外移，避免构造器膨胀和参数模糊。
