不推荐用char数组构造BigDecimal——虽看似绕过String创建，但内部解析逻辑相同、内容不可复用、错误难定位、无JVM优化，实际性能无提升且风险更高。
直接用 char 数组构造 BigDecimal 在特定场景下确实能绕过字符串对象创建，但**不推荐作为性能优化手段**——它既不安全也不高效，反而容易引入隐性开销和错误。
为什么 char[] 构造器不是性能捷径
表面上看，char[] 比 String 少一层包装，似乎更“底层”。但实际上：
- BigDecimal 内部仍会将 char[] 复制并解析为数字，过程与 String 构造器几乎一致（源码中两者最终都调用同一套 parse 方法）
- char[] 无法复用（内容可变），每次传入都需确保数组内容稳定、无干扰字符，调试和维护成本高
- 若数组含前导空格、符号异常或非法字符，抛出 NumberFormatException 的堆栈更难定位，不利于批量解析的容错处理
- JVM 对 String 的 intern 和常量池优化成熟，而 char[] 无此类机制，实际 GC 压力未必更低
真正有效的批量解析优化路径
面对大数据量（如日志解析、账单导入、CSV 批量读取），应聚焦在“减少 BigDecimal 实例创建”和“规避低效解析路径”上：
- 优先复用预定义常量：对固定值（如"0"、"1"、"0.01"）直接使用 BigDecimal.ZERO、ONE、TEN 或缓存好的实例，避免任何构造
- 统一走 String.valueOf() + 静态缓存：将原始数值（如 long、int）先转为字符串再构造，比 double 构造安全；高频出现的字符串值（如"99.99"）可用 ConcurrentHashMap 缓存对应 BigDecimal 实例
- 避免在循环内 new BigDecimal(String)：改用 StringBuilder 预拼接或分批解析，结合 valueOf(long) / valueOf(int) 处理整数部分，小数部分单独拆解后组合
- 对纯整数场景，优先用 long + scale 控制：例如金额单位为分，直接用 long 存储，运算完再调用 BigDecimal.valueOf(totalCents).divide(BigDecimal.valueOf(100), 2, RoundingMode.HALF_UP)
如果非要用 char[]，必须注意这三点
仅当已有现成 char[] 且确认不可转为 String（如内存敏感的零拷贝解析场景）时才考虑，且务必：
立即学习“Java免费学习笔记（深入）”；
- 确保数组内容是连续、纯净的十进制数字字符（不含 BOM、\u0000、空格等）
- 显式指定 offset 和 length，避免默认全数组扫描带来的越界风险
- 配合 MathContext 使用（如 new BigDecimal(chars, offset, len, new MathContext(15, RoundingMode.HALF_UP))），防止因精度溢出触发额外校验开销
本质上，BigDecimal 的性能瓶颈不在构造器选型，而在频繁实例化和未控制的 scale 变动。把精力放在数据源头归一化（统一单位、预校验格式）、复用已有实例、减少中间对象生成，比纠结 char[] 还是 String 更有效。
