Java 编译器（javac）严格遵循语言规范，不会省略任何显式写出的 String.format 调用——即使参数仅为纯字符串且不含格式说明符（如 %s、%d），该调用仍会完整保留在字节码中，由 JVM 在运行时执行。
java 编译器（`javac`）不会优化掉无格式化占位符的 `string.format` 调用——即使参数仅为纯字符串且不含格式说明符（如 `%s`、`%d`），该调用仍会完整保留在字节码中，由 jvm 在运行时执行。
在 Java 生态中，编译期优化极其有限。javac 的核心职责是将 .java 源文件精确、逐字地翻译为符合 JVM 规范的 .class 字节码，不得擅自删减、替换或内联任何方法调用——哪怕语义上看似“冗余”。例如：
String s = String.format("Number of items: 100");这段代码会被原样编译为对 String.format(String) 的静态方法调用指令（invokestatic），而绝不会被简化为 String s = "Number of items: 100";。原因在于：
- ✅ 规范强制性：Java 语言规范（JLS）要求编译器行为可预测、可重现。若允许
javac擅自优化String.format，则不同编译器或同一编译器不同版本可能产生不一致字节码，破坏“一次编写，到处运行”的基石。 - ✅ 语义不确定性：
String.format是一个普通静态方法，其行为依赖于String类的具体实现。未来 JDK 版本完全可能修改其逻辑（例如增加日志、国际化预处理等）。编译器无权假设其“永远无副作用”。 - ✅ 运行时才是优化主场：真正的优化（如方法内联、逃逸分析、常量折叠）由 HotSpot JVM 的 JIT 编译器在运行时完成。但即便如此，
String.format("literal")也极少被 JIT 消除，因为其内部仍需遍历字符串查找%符号——这本身就有开销。
更优替代方案：字符串模板（JDK 21+）
为解决传统 String.format 的性能与可读性痛点，JDK 21 引入了预览特性：字符串模板（String Templates）（JEP 430），提供编译期解析、零运行时解析开销的字符串拼接能力：
// 需启用预览特性：--enable-preview
String name = "Jane";
int age = 8;
String formatted = STR."My name is \{name}, and I am \{age} years old";
// 等价于编译期拆解为：STR.process("My name is ", name, ", and I am ", age, " years old")✅ 关键优势：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 编译器直接将模板解析为固定字符串片段与表达式参数序列，完全跳过运行时正则/字符扫描；
-
STR是可插拔的处理器接口，支持自定义安全策略（如 SQL 注入防护）； - 语法清晰、类型安全（IDE 可校验
\{expr}中的表达式有效性）。
⚠️ 注意：当前（JDK 21/22）该特性仍为预览版，需显式启用
--enable-preview；正式 GA 后将成为标准字符串拼接首选，逐步替代String.format和+连接。
实践建议
| 场景 | 推荐方式 | 说明 |
|---|---|---|
| 简单字面量拼接（无变量） | 直接使用字符串字面量 |
"Number of items: 100" —— 零开销，最高效 |
| 含变量的格式化（JDK 21+） |
STR."..." 模板 |
编译期解析，安全、高效、可扩展 |
兼容旧 JDK 或需 Locale 支持 |
String.format(...) |
功能完备，但注意性能损耗；避免 format("plain string") 这类无意义调用 |
| 构建动态消息（如日志） |
MessageFormat 或 SLF4J 参数化日志 |
避免字符串拼接，支持延迟格式化 |
总之，切勿依赖 javac 优化 String.format——它不会发生。应主动选择语义更明确、性能更优的现代替代方案，并在性能敏感路径中优先使用编译期确定的字符串构造方式。
