类型转换的关键在于可控性与安全性，需前移至规则定义期，结合编译期约束与运行时校验，绑定上下文、预检兼容性、统一数值计算、治理装箱成本，并为字符串转换提供可配置、可回溯的格式化支持。
Java 类型转换逻辑不是性能瓶颈的来源，而是可控性与安全性的关键支点。在高性能数据处理引擎中，真正影响吞吐量和延迟的，从来不是“要不要转”，而是“在哪转、怎么转、谁来保证不崩”。核心思路是：把类型适配前移到规则定义期，用编译期约束 + 运行时可信校验替代反射硬转和字符串解析。
类型转换必须绑定上下文，不能孤立存在
脱离数据来源、字段语义和业务契约的类型转换极易引发运行时异常或静默错误。例如一个规则表达式写 age > 18，但原始数据里 age 是 String 类型，直接 parse 成 int 可能失败；若底层是 JSON 字符串且含空格或单位（如 "25岁"），裸调 Integer.parseInt() 就会抛异常。
- 字段声明时明确标注目标类型，如
RuleField.of("age", Integer.class) - 配套注册可选转换器，比如
StringToIntegerConverter支持 trim、去单位、默认值 fallback - 引擎执行前做一次轻量级类型兼容性预检，不实际转换，只验证是否可达（如 String → LocalDateTime 是否配置了格式模板）
运算阶段统一提升，避免中间态隐式降级
Java 算术运算中的自动类型提升规则（byte/short/char → int）常被忽视，却直接影响计算结果正确性。尤其在聚合、加权、阈值判断等场景，未显式控制类型会导致溢出或精度丢失。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 对数值类字段，统一按
Number接口接入，内部优先转为BigDecimal或long进行中间计算，规避 float/double 的舍入误差 - 涉及乘除或大数累加时，强制使用 long 或 BigInteger，例如：
long total = (long) qty * unitPrice;，防止 int 溢出 - 比较操作符（EQ/GT/IN）背后不依赖原始类型，而是提取标准化值：数字走
doubleValue()或longValue()，时间走毫秒时间戳，字符串走toString()并归一化空值
包装类空值与装箱成本必须显式治理
高频规则匹配中，Integer、Double 等包装类的 null 值和自动装箱行为是隐形性能杀手——既可能触发 NPE，又会生成大量临时对象加重 GC 压力。
立即学习“Java免费学习笔记（深入）”；
- 规则上下文对象（RuleContext）内部用原生数组或
OptionalInt/OptionalLong存储确定性数值字段，避免泛型擦除后的强制转型 - 对外暴露的 getter 方法返回
int而非Integer，null 场景由业务约定默认值（如 -1、0 或 Long.MIN_VALUE），不依赖拆箱 - 批量处理时禁用
list.add(i)这类自动装箱，改用IntArrayList或int[]配合索引访问
字符串到结构化类型的转换要可配置、可回溯
现实数据源中，时间、金额、枚举码等几乎都以字符串形式流入引擎。硬编码 LocalDateTime.parse() 或 new BigDecimal(str) 不仅脆弱，还无法应对多格式、多区域、缺省值等真实需求。
- 为每个字符串字段关联
FormatSpec：支持正则提取、多模式匹配（如 "yyyy-MM-dd" / "yyyyMMdd" / "dd/MM/yyyy"）、时区偏移、千分位处理 - 转换失败时不中断流程，记录 warning 日志并转入 fallback 分支（如返回 null、默认时间、兜底枚举值）
- 保留原始字符串值与转换后对象的映射关系，便于审计、调试和规则热更新时重算
