应优先使用 numberformat.getcurrencyinstance(locale) 获取区域敏感的货币格式器，而非直接使用 decimalformat；因后者不绑定 locale 且无视币种小数规则，易导致符号错误或非法小数位。
Java 里格式化数字和货币，别用 DecimalFormat 直接硬套，它默认不处理区域敏感逻辑，尤其货币容易出错；优先用 NumberFormat 的工厂方法，再按需定制。
为什么 DecimalFormat 单独用会丢掉货币符号或小数位
DecimalFormat 是个“裸”格式器，不绑定任何区域（Locale），也不自带货币元数据。你写 new DecimalFormat("$#,##0.00")，$ 只是字面字符，不会随系统语言自动变成 ¥ 或 €，也不会校验该地区货币是否真用两位小数（比如日元本就不该有小数）。
- 常见错误现象：
format(1234.5)输出$1,234.50，但切换到Locale.JAPAN后仍显示美元符号，而非¥1,234 - 正确做法：用
NumberFormat.getCurrencyInstance(Locale.JAPAN)，它内部已预置符号、小数位、分组符 - 如果必须用
DecimalFormat（比如要微调模式），务必先用NumberFormat.getCurrencyInstance().getCurrency()拿到真实币种，再设setCurrency()
NumberFormat.getCurrencyInstance() 怎么选对 Locale
传错 Locale 是最隐蔽的坑——不是看服务器在哪，而是看「这笔钱给谁看」。面向中国用户的钱，就得用 Locale.CHINA，哪怕服务部署在德国。
- 别用
Locale.getDefault()：它依赖 JVM 启动环境，测试机和生产机可能不同，导致格式不一致 - Web 场景下，应从 HTTP 请求头（如
Accept-Language）或用户账户配置中取Locale，而不是硬编码 -
Locale.US和Locale.ENGLISH不等价：前者带货币规则（$、2 位小数），后者只是语言，用它获取货币实例会 fallback 到 US，但行为不可靠
自定义货币格式时，setMinimumFractionDigits() 不能乱调
日元、韩元等无小数货币，强制设 setMinimumFractionDigits(2) 会输出 ¥1,234.00，这是业务错误，不是显示问题。
- 正确做法：先调
currency.getDefaultFractionDigits()获取该币种法定小数位，再设setMinimumFractionDigits()和setMaximumFractionDigits() - 示例：
Currency.getInstance("JPY").getDefaultFractionDigits()返回0，此时设setMinimumFractionDigits(0)才安全 - 注意：
NumberFormat实例不是线程安全的，多线程共用时要同步或每次新建
真正难的不是写对一行格式代码，而是想清楚「这个数字最终在哪个国家、由哪类用户、以什么业务含义去阅读」——漏掉这点，再准的 DecimalFormat 模式都是障眼法。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
