String.format参数类型与占位符不匹配时抛IllegalFormatConversionException；如%d配String、%d配null包装类（触发NPE而非此异常）、%e/%g配Float等，需按Formatter语法严格匹配类型，优先用原始类型和%s兜底。
String.format里类型和占位符对不上，直接抛IllegalFormatConversionException
这个异常本质就一句话：String.format 传进去的参数类型和格式串里的转换符（比如 %d、%s）不兼容。不是“写错了”，而是 JVM 在运行时严格校验失败了。
常见错误现象：
- 用
%d去格式化一个String变量 → 报java.util.IllegalFormatConversionException: d != java.lang.String - 用
%s格式化一个null的基本类型包装类（如Integer），虽然不会崩，但一旦换成%d就立刻出错 - 误把
float当double传给%f（其实能过），但若用%e或%g配Float对象，某些 JDK 版本会触发校验失败
实操建议：
- 检查每个
%占位符后面紧跟的字符，对照 Java Formatter 语法表确认它接受哪些类型；例如%d只认byte、short、int、long、BigInteger及其包装类，String不在其中 - 不确定类型时，统一用
%s—— 它兼容所有对象（包括null，输出为字符串"null"），代价是失去类型语义和精度控制 - 对数字，优先用原始类型（
int、double）而非包装类传参，避免自动拆箱失败或空指针干扰校验逻辑
String.format传入null导致IllegalFormatConversionException？不，那是另一回事
IllegalFormatConversionException 本身和 null 没有直接关系。真正因 null 崩的是 NullPointerException，发生在调用 toString() 时（比如 %s 遇到 null 是安全的，但 %d 遇到 null Integer 会在拆箱时炸）。
立即学习“Java免费学习笔记（深入）”；
容易混淆的场景：
-
String.format("%d", null)→ 先尝试null.intValue()→NullPointerException，不是IllegalFormatConversionException -
String.format("%d", "123")→ 类型不匹配 → 真正的IllegalFormatConversionException -
String.format("%s", null)→ 合法，结果是字符串"null"
实操建议：
- 别靠异常类型猜问题，先看完整错误信息里
!=左右两边的类型（如d != java.lang.String），那才是关键线索 - 如果参数可能为
null且必须用数字占位符，提前做非空判断并提供默认值：String.format("%d", obj == null ? 0 : obj.getValue())
用Objects.toString()或String.valueOf()绕过格式化校验？没必要，但要注意副作用
有人想用 String.valueOf(obj) 把任意值转成字符串再塞进 %s，以为能“兜底”。这确实能避开 IllegalFormatConversionException，但属于舍近求远。
真实代价：
- 多一次对象转换 + 字符串拼接，性能略损（通常可忽略）
- 丢失原始意图：你本来想输出带千分位的整数，结果用
%s+String.valueOf输出纯数字字符串，没法加%,d这类修饰符 - 对浮点数，
String.valueOf(0.1)可能输出"0.10000000000000001"，而%.2f能控制精度
实操建议：
- 需要类型安全又不想写一堆 if 判断？用
switch或instanceof分支预处理，再调用对应格式化方式 - 日志场景下，SLF4J 的
logger.debug("value={}", obj)内部就是安全的字符串化，比硬套String.format更省心
Android上String.format崩溃更频繁？跟资源绑定有关
Android 开发者常遇到：同一段 String.format(resources.getString(R.string.xxx), arg) 在某些机型或语言环境下崩，报 IllegalFormatConversionException。问题往往不在 Java 层，而在字符串资源里写了错误的占位符。
典型原因：
- 资源文件中用了
%d，但代码里传的是String（比如从 API 拿到的 ID 是字符串） - 多语言翻译时，译员不懂技术，把
%1$s改成%1$d，或者漏掉数字序号变成%s - 使用
getString(int, Object...)时，系统底层仍走String.format校验，错误位置指向资源内容而非 Java 代码行
实操建议：
- 检查
strings.xml里所有含%的字符串，用正则%\d*\$?[sdfe]扫一遍，确认占位符数量、顺序、类型和 Java 侧传参完全一致 - 开发阶段开启
lint检查：Android Studio 默认启用StringFormatMatches规则，能提前标出不匹配项 - 线上崩溃堆栈若显示异常来自
Resources.java，第一反应不是改代码，而是查对应 string resource 的内容
最麻烦的点其实是：错误可能藏在资源里，但异常堆栈只告诉你“格式化失败”，不告诉你哪一行资源出了问题。得手动比对或加日志打出来实际加载的字符串内容才能定位。
