NumberFormat.getCurrencyInstance() 受系统区域设置影响，需显式传入Locale（如Locale.CHINA）；format()仅接受Number子类，须校验null和类型；须同时设最小/最大小数位及舍入模式；非线程安全，应避免共享实例。
NumberFormat.getCurrencyInstance() 返回的格式器会受系统区域设置影响
Java 的 NumberFormat.getCurrencyInstance() 默认使用运行时默认的 Locale，不是你本地语言习惯的“¥1,000.00”，而是可能变成 “$1,000.00” 或 “1 000,00 €”。这在服务器部署或跨环境运行时极易出错。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 显式传入
Locale，比如NumberFormat.getCurrencyInstance(Locale.CHINA)才能得到带 ¥ 符号、千分位逗号、两位小数的中文习惯格式 - 避免依赖
Locale.getDefault()，尤其在 Spring Boot 等容器中，它可能被 JVM 参数或容器环境覆盖 - 若需动态适配用户请求的区域（如 Web 接口），应从 HTTP 请求头（
Accept-Language）解析后构造Locale，再传给getCurrencyInstance()
format() 方法对 null 和非数字类型会直接抛 NPE 或 ClassCastException
NumberFormat.format() 只接受 Number 子类（Double、BigDecimal、Long 等），传 null 会触发 NullPointerException；传 String 或自定义对象则抛 ClassCastException。这不是设计缺陷，而是 API 明确契约。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 调用前做空值检查：
if (amount == null) return "—"; - 不要试图把字符串如
"1234.56"直接传进去，先用Double.parseDouble()或new BigDecimal(str)转成数值类型 - 推荐优先使用
BigDecimal表示金额，避免double的浮点误差导致显示为¥19.999999999999996
setMinimumFractionDigits(2) 不足以保证货币总显示两位小数
很多人以为设了 setMinimumFractionDigits(2) 就万事大吉，但 NumberFormat 还有 setMaximumFractionDigits() 和四舍五入模式共同起作用。如果没设最大位数，且原始数值本身是整数（如 100），结果可能是 ¥100 而非 ¥100.00。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 必须同时调用：
formatter.setMinimumFractionDigits(2)和formatter.setMaximumFractionDigits(2) - 设置舍入模式：
formatter.setRoundingMode(RoundingMode.HALF_UP)，否则BigDecimal的精度行为可能和预期不一致 - 注意：这些设置要在
getCurrencyInstance()之后立即做，因为不同Locale的默认精度可能不同（如某些地区默认显示 0 位小数）
在高并发场景下 NumberFormat 实例不能共享使用
NumberFormat 不是线程安全的。它的内部状态（如 parsePosition、缓存的格式化结果）在多线程并发调用 format() 或 parse() 时会被污染，导致偶发性格式错乱，比如本该是 ¥1,234.56 却输出成 ¥1,234.5 或抛出 IllegalArgumentException。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 不要将
NumberFormat声明为 static 全局变量 - 每次使用都新建实例：
NumberFormat.getCurrencyInstance(Locale.CHINA)—— 开销极小，别担心性能 - 如果真有性能敏感场景（如每秒数万次格式化），可用
ThreadLocal<numberformat></numberformat>缓存，但务必确保每个线程只读写自己的实例
最常被忽略的一点：货币符号位置、千分位分隔符、小数点符号，全由 Locale 决定，而不是由你写的代码“控制”。换一个 Locale，¥ 可能变 ￥，逗号可能变空格，小数点可能变逗号——这些细节在国际化项目里，比逻辑错误更难排查。
