IllegalFormatConversionException是Java中String.format()等方法因格式符（如%d）与参数类型不匹配而抛出的运行时异常，例如用%d传String、%f传Integer、%t系列传String等；需严格按Formatter语法匹配类型，优先用%s兜底或启用-Xlint:format编译检查。
IllegalFormatConversionException 是 Java 中 String.format() 方法在格式化字符串时，占位符类型与实际传入参数类型不匹配时抛出的运行时异常。比如用 %d（期望整数）却传入了 String，或用 %s 却传入了未重写 toString() 的自定义对象且其为 null，都可能触发该异常。
检查占位符与参数类型的对应关系
Java 格式化语法对每个转换符有明确的类型要求。常见不匹配示例如下：
-
%d、%x、%o：只接受byte、short、int、long及其包装类，不接受String或Double -
%f、%e、%g：仅支持float、double及其包装类，传Integer会报错（自动装箱不等于类型兼容） -
%s：可接受任意对象（调用toString()），但若对象为null且未显式处理，也可能在某些上下文中引发间接问题（如后续链式调用） -
%t系列（如%td）：必须传入java.util.Date、Calendar、Long（毫秒时间戳）或实现了TemporalAccessor的类（如LocalDateTime），传String直接抛IllegalFormatConversionException
使用 IDE 提示和编译期检查辅助定位
现代 IDE（如 IntelliJ IDEA 或 Eclipse）会在编辑时标出明显类型不匹配的 String.format() 调用。启用「Inspection」中的「String concatenation can be replaced with format()」或「Format string syntax error」可提前发现错误。
更可靠的做法是配合静态检查工具（如 ErrorProne）或启用 -Xlint:format 编译选项：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
javac -Xlint:format MyTest.java它会在编译阶段报告潜在的格式化类型冲突，避免等到运行时才暴露问题。
用 Objects.toString() 和显式类型转换增强健壮性
对可能为 null 的引用类型，不要依赖默认 %s 行为；对数值类型，确保传入正确包装类或原始类型：
- 替代
String.format("Name: %s", user.getName())→String.format("Name: %s", Objects.toString(user.getName(), "N/A")) - 若需格式化浮点数但变量是
int count = 5;，不要写%f，而应转成(double)count或改用%d - 处理日期时，避免直接传
new Date().toString()给%td；应传new Date()或System.currentTimeMillis()
用 String.format 的安全替代方案降低风险
对于复杂或动态拼接场景，可考虑更类型安全的替代方式：
- 使用
MessageFormat（支持位置索引，类型检查较宽松，适合国际化） - 采用 Lombok 的
@ToString+ 明确字段拼接，或使用TextBlock（Java 15+）配合字符串连接 - 引入模板引擎（如
StringSubstitutorfrom Apache Commons Text）做键值替换，完全规避格式化符号解析 - JDK 15+ 可尝试
Formatter配合 try-catch 做兜底，但不推荐作为主要策略
