怎么在 Ja va 中使用 String.format() 实现类似 C 语言的格式化输出
String.format() 的基本语法和占位符怎么写
很多从 C 语言转过来的开发者，会下意识地把 printf 那套写法直接搬到 Ja va 里。但这里有个关键区别：Ja va 的 String.format() 虽然看起来眼熟，可它的占位符玩法更“讲究”。你不能简单地用 %d、%s 就完事了，必须带上参数索引，或者确保参数顺序严丝合缝，否则运行时等着你的就是 IllegalFormatConversionException 这类异常。
最稳妥、最推荐的做法是什么？是显式指定参数索引。比如这么写：String.format("用户 %1$s 年龄 %2$d", name, age)。你看，%1$s 意思很明确：“取第一个参数（name），按字符串格式化”；%2$d 则是：“取第二个参数（age），按十进制整数处理”。这样一来，哪怕参数顺序调整了，格式串本身也不用动，安全系数高多了。
- 当然，不写索引（像
%s）也行，但这意味着你必须保证传入参数的顺序和占位符出现的顺序完全一致，一旦错位，结果就错了。 - 基础的转换符，比如
s（字符串）、d（整数）、f（浮点数）、x（十六进制），这些和 C 语言是相通的。不过要注意，Ja va 可不支持%u（无符号整数）或者%p（指针地址）这种格式。 - 宽度、精度这些修饰符的写法倒是一脉相承。例如，
%5s表示最少占5个字符宽度，%.2f就是保留两位小数。
为什么直接套用 C 的 printf 风格会报错
把 C 代码直接复制过来，往往是踩坑的开始。比如，String.format("value = %d, str = %s", 42, "hello") 这段代码，表面上看风平浪静。可一旦你传入一个 null 字符串试试？它不会像 C 的 printf 遇到 NULL 指针那样崩溃或打印出 (null)，而是会抛出一个 ja va.util.FormatFlagsConversionMismatchException 异常，或者更“安静”地，直接把 "null" 这个字符串给打印出来——这跟很多人的直觉可不太一样。
还有更隐蔽的类型匹配问题。在 C 语言里，你用 %d 去打印一个 long 型变量，可能也就截取低32位了事。但在 Ja va 里，规矩就严格多了：%d 只能接受 byte、short、int、long、BigInteger 这些整数类型（是的，long 用 %d 是合法的，%ld 反而是多余的）。但如果你不小心用 %d 去格式化一个 float，对不起，程序会直接抛出异常，没有任何商量的余地。
立即学习“Ja va免费学习笔记（深入）”；
- Ja va 的类型检查更为严格。
%d不接受float或除Integer等标准包装类以外的数字类型（比如你用AtomicInteger就会失败）。 - 把
null值传给%s时，它会被转换成字面字符串"null"，既不是空字符串，也不会引发空指针异常（NPE）——这一点务必记牢。 - 关于换行：Ja va 没有
\n以外的特殊支持吗？有的，但要用对。平台相关的换行符是\n，而%n才是那个能保证跨平台正确换行的占位符。
如何安全处理 null 和可选字段
Ja va 没有 C 语言那样的宏或者编译期的可变参数预处理机制，所以别指望它能自动跳过 null 参数。在实际开发中，如果不对 null 做兜底处理，那么日志或者拼接的字符串里突然冒出一个 "null" 字眼，排查起来可是相当头疼的。
比较推荐的做法是，在调用 String.format() 之前，先对参数做一轮预处理。用三元运算符或者 Objects.toString() 工具方法都很方便：
String name = null;
String msg = String.format("用户: %s, ID: %d",
Objects.toString(name, "(未命名)"),
userId);
- 记住，不要依赖
String.format()来自动处理空值，它没有提供默认值机制。 - 如果某个字段可能为
null，并且业务上不允许直接显示"null"这个单词，那就必须在外层处理掉。比如用Optional.ofNullable(name).orElse("(缺省)")就是个清晰的写法。 - 对于集合或者数组，直接用
%s格式化会调用其toString()方法，结果往往是类似[Lja va.lang.String;@1b6d3586这种难以阅读的内存地址。正确的做法是，先用Arrays.toString(arr)等方法转换成可读的字符串格式，再传入进行格式化。
性能和替代方案要注意什么
性能问题，是使用 String.format() 时另一个需要考量的点。每一次调用，它都会在内部解析格式字符串、创建一个 Formatter 实例、执行类型校验，最后才完成拼接。这个开销，可比直接用字符串连接符 + 或者 StringBuilder 要大得多，在密集循环里可能慢上3到5倍。所以，简单的字符串拼接，就别非得套用 format 了。
- 在日志记录这种高频场景下，优先考虑使用 SLF4J 这类日志框架的占位符语法，例如
logger.info("user {} age {}", name, age)。它的优势在于底层是惰性求值，只有当日志级别确实需要输出时才会进行格式化，对性能更友好。 - 如果是 Android 开发，还得留意版本兼容性。在较低版本的 API（比如 API 16）下，
String.format()可能不支持像%,d（千位分隔符）这样的格式符，需要添加@TargetApi注解或者准备降级方案。 - 当格式字符串固定不变而参数经常变化时，可以考虑预编译策略来提升效率。例如使用 Apache Commons Lang 库里的
StrSubstitutor，或者自己缓存MessageFormat的实例（不过要注意线程安全问题）。
说到底，想在 Ja va 里写出“C 语言风格”的格式化代码，关键不在于语法长得有多像，而在于真正理解 Ja va 自身的类型边界和 null 值处理逻辑。否则，格式字符串看着都对，一运行就出问题，那才真是让人措手不及。
