MessageFormat.format() 为什么总丢参数或报错
根本原因不是语法写错，而是 MessageFormat 的占位符不认普通字符串插值，它只认 {0}、{1,date} 这种带索引+可选类型的格式。传参顺序、类型、数量必须严格匹配模板里的占位符定义。
常见错误现象：IllegalArgumentException: Cannot format given Object as a Number（传了字符串却声明为 {0,number}），或静默丢掉后面几个参数（占位符索引跳号，比如写了 {0} 和 {2}，但只传了两个参数）。
- 参数必须是 Object 数组，不能用 varargs 直接传单个值（除非显式写成
new Object[]{...}） - 占位符索引从 0 开始，且建议连续；跳号或重复会导致不可预期行为
- 如果模板里有单引号
'，需写成两个''，否则会解析失败
示例：MessageFormat.format("用户 {0} 在 {1,date,yyyy-MM-dd} 登录", "Alice", new Date())
多语言模板里怎么安全处理复数和性别
MessageFormat 本身不支持 i18n 中的复数（plural）、性别（gender）等复杂规则——它只支持 choice 子句做简单数值分支，而且语法生硬、易出错。
立即学习“Java免费学习笔记（深入）”；
使用场景：你有一份中文模板和一份英文模板，都希望根据用户数量显示“1 个用户”或“{0} 个用户”，但英文需要 “1 user” / “{0} users”。这时候硬靠 {0,choice,0#无用户|1#1 user|1 写法，既难维护，又无法对接 ICU 或 CLDR 标准。
-
choice的分隔符是|，范围写法如1 表示“大于 1”，<code>1#表示“等于 1”，但没有“≥2”这种简洁表达 - 所有分支必须覆盖完整区间，漏写
0#或other#可能导致运行时 fallback 失败 - 真正做国际化时，应优先用
ResourceBundle+java.text.ChoiceFormat组合，或直接迁移到java.time.format.TextStyle等更现代的 API
format() 和 parse() 的线程安全性要注意什么
MessageFormat 实例**不是线程安全的**——它的内部状态（如 parsePosition）会被并发调用污染。你可能会在高并发日志拼接中看到偶尔解析错位、格式错乱，甚至 NullPointerException。
性能影响明显：每次 new 一个 MessageFormat 开销不大，但频繁创建 + GC 会影响吞吐；而共享实例又容易出问题。
- 推荐做法：把模板字符串作为 key，用
ConcurrentHashMap<string messageformat></string>缓存已编译的实例 - 不要在实例上调用
applyPattern()后复用——这会重置内部状态，且非原子操作 - 如果只是简单拼接，且模板固定，用
String.format()更轻量；只有需要日期/数字本地化格式时，才值得上MessageFormat
替换方案：什么时候该放弃 MessageFormat
当你开始给占位符加嵌套（比如 {0, date, {1}}）、或需要动态切换 locale、或模板来自配置中心/数据库时，MessageFormat 的维护成本就远超收益了。
容易被忽略的一点：它的 pattern 解析是在运行时做的，没有编译期检查。模板写错（比如多了一个 }），要等到第一次 format() 才抛 IllegalArgumentException，而不是编译报错。
- 纯 Java 项目可考虑
java.util.Formattable+ 自定义实现，或用StringTemplate（JDK 21+）替代 - Spring 生态直接用
MessageSource接口，底层自动处理 locale、fallback、缓存 - 微服务场景下，模板逻辑尽量前置到前端或配置平台，Java 层只做参数透传
真正棘手的从来不是怎么写对一个 format 调用，而是当模板变多、语言变多、上线后还要热更新时，你有没有预留好解析、校验、降级的余地。
