最稳妥的方式是使用 NumberFormat.getCurrencyInstance() 并显式传入目标 Locale（如 Locale.CHINA），配合 BigDecimal 精确计算，避免 double 精度问题和 Locale 默认值陷阱。
用 NumberFormat.getCurrencyInstance() 最稳妥
Java 里格式化货币，别自己拼字符串或用 DecimalFormat 硬写模式——Locale 变动、小数位数、符号位置、千分位分隔符全会出错。直接用 NumberFormat.getCurrencyInstance()，它按系统或指定 Locale 自动适配规则。
常见错误是传了 Locale.US 却在中文环境显示 $1,234.56，用户一看就懵；或者没设 setMaximumFractionDigits()，导致金额显示成 ¥1234.5600。
- 必须显式传入目标
Locale，比如Locale.CHINA或new Locale("de", "DE")，不依赖 JVM 默认值 - 对金额做四舍五入前，先用
BigDecimal处理原始数值，避免double的精度丢失（例如0.1 + 0.2 == 0.30000000000000004） - 如果后端返回的是分（整数），记得除以 100 再格式化，别直接格式化 1234 当作 12.34 元
Locale 选错会导致符号和小数位全错
货币格式高度依赖 Locale：同样是 1234.5，Locale.US 输出 $1,234.50，Locale.CHINA 输出 ¥1,234.50，而 new Locale("ja", "JP") 输出 ￥1,235（日元无小数位）。不是所有 Locale 都支持两位小数，比如印度卢比（hi_IN）默认显示三位。
-
Locale.CHINA和Locale.SIMPLIFIED_CHINESE效果相同，但后者更明确意图 - 避免用
Locale.getDefault()做生产逻辑——容器环境或 Spring Boot 启动时可能被覆盖 - 测试时务必覆盖多个
Locale，尤其注意中东地区（如ar_SA）数字从右往左排，货币符号在右侧
Spring Boot 中用 @NumberFormat 注解要小心
在 Spring MVC 的 DTO 字段上加 @NumberFormat(style = Style.CURRENCY)，只影响绑定（binding）过程的解析，不控制输出。也就是说，前端传 "¥1,234.50" 能转成 1234.5，但你 return 这个对象时，JSON 里还是裸数字，不会自动变回带符号的字符串。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 输出格式化得靠序列化层，比如 Jackson 配
@JsonFormat(pattern = "###,##0.00")，但这只是数字格式，不是货币——缺符号、缺 Locale 感知 - 真正统一方案是自定义
JsonSerializer<bigdecimal></bigdecimal>，内部调用NumberFormat.getCurrencyInstance(locale) - 别在实体类字段上同时用
@NumberFormat和@JsonFormat，容易互相干扰
Android 上 NumberFormat 行为有差异
Android API 24+ 基本兼容标准 JDK，但低版本（尤其是 API 19–23）的 NumberFormat.getCurrencyInstance() 对某些 Locale 返回空或异常，比如 Locale.forLanguageTag("bn-BD")。而且 Android 不保证 Locale 列表完整，Locale.getAvailableLocales() 返回的子集比桌面 JVM 少得多。
- 上线前必须真机测目标
Locale，模拟器可能掩盖问题 - 兜底逻辑建议用
try-catch捕获IllegalArgumentException，降级到手动拼接（如"$" + String.format("%.2f", amount)），至少保功能 - 避免用
Locale.setDefault()动态改全局，Android 应用生命周期里可能影响其他模块
货币格式化看着简单，实际最麻烦的是「你以为它该长什么样」和「它真长什么样」之间那层 Locale 黑箱。每次换国家、换币种、换 Android 版本，都得重新验证符号位置、小数位、分组符——不能只信文档，得看真实输出。
