messageformat.format() 不替换占位符主因是花括号不配对或类型不匹配：{0}未替换因单个{被当字面量；{0,date}传入instant会classcastexception；中文locale需显式传入避免格式错乱；固定pattern应static final复用以提升性能。
MessageFormat.format() 为什么有时不替换占位符
常见现象是传入的 pattern 里写了 {0}、{1,date}，但输出原样显示 {0}，没被替换成实际值。根本原因不是语法错，而是 MessageFormat 对花括号极其敏感：它把未配对的 { 或 } 当作字面量处理，而不会报错。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 确保 pattern 中所有
{都有对应}，哪怕只是想显示一个左花括号，也得写成{{ - 避免在 pattern 里直接拼接用户输入——比如
"Hello " + name + "!"再塞进MessageFormat.format()，这会破坏占位符结构 - 如果 pattern 来自配置文件或数据库，先用
String.replace("{{", "\u007B\u007B")这类方式预处理不可靠；更稳妥的是改用双大括号转义：{{表示单个{，}}表示单个}
参数类型不匹配导致 format() 报 ClassCastException
比如 pattern 含 {0,date}，但传入的参数是 Long 或 Instant，MessageFormat 就会抛 ClassCastException: java.lang.Long cannot be cast to java.util.Date。它不自动转换，只认严格类型。
实操建议：
立即学习“Java免费学习笔记（深入）”；
-
{0,date}只接受Date或null；要用Instant，得先转：Date.from(instant) -
{0,number,currency}要求参数是Number子类，String直接传进去会失败，不是格式化问题，是类型校验失败 - 批量参数时，用
Object[]显式声明类型，别依赖 varargs 自动装箱——int会被装成Integer，但{0,number}能接受；boolean装成Boolean就无法用于{0,date}这类格式
中文环境下日期/数字格式不按 locale 显示
调用 MessageFormat.format(pattern, args) 时，即使 JVM 默认 locale 是 zh_CN，输出仍可能是英文月份或美式数字分隔符。因为 MessageFormat 的无参构造默认用 Locale.getDefault()，但 format 过程中若参数含 Date 或 Number，其格式化实际由内部 DateFormat 和 NumberFormat 控制——而这俩可能被缓存或重置过。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 显式传入 locale：
new MessageFormat(pattern, Locale.CHINA)，而不是依赖默认 - 避免复用同一个
MessageFormat实例跨不同 locale 使用——它的setLocale()方法是线程不安全的，且影响后续所有 format 调用 - 如果发现数字千分位变成逗号（如
1,234.56）而非顿号或空格，确认Locale.CHINA下NumberFormat.getInstance(Locale.CHINA).getGroupingSeparator()确实返回'，'（全角逗号），否则 pattern 里的{0,number}仍按 fallback locale 格式化
性能陷阱：反复 new MessageFormat 实例
每次调用都 new MessageFormat(pattern)，尤其 pattern 固定、高频使用（如日志模板、响应消息），会触发重复解析 pattern 字符串、重建内部语法树，比字符串拼接还慢。JDK 并不缓存 MessageFormat 实例，也不推荐自行加锁缓存。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 将固定 pattern 的
MessageFormat实例声明为static final，例如：private static final MessageFormat MSG = new MessageFormat("用户{0}于{1,date,short}登录"); - 注意线程安全：
MessageFormat不是线程安全的，但它的format()方法是无状态的，只要不调用applyPattern()或setLocale()，多个线程并发调用format()是安全的 - 如果 pattern 动态生成（比如从 DB 查），就别硬套静态实例；此时优先考虑
java.text.Format子类或现代方案（如String.format()+DateTimeFormatter），MessageFormat在动态场景下维护成本明显更高
真正麻烦的从来不是怎么写对一个 pattern，而是当多语言、多时区、多数据类型混在一起时，MessageFormat 的隐式类型约束和 locale 绑定行为会在某个凌晨三点的发布后突然冒出来。
