String.format无法直接实现数字补零兼容负数和小数截断，需手动处理：负数补零用符号+绝对值格式化，截断小数需先Math.floor(x*100)/100.0；日期格式化应优先用DateTimeFormatter；需显式指定Locale防乱码；性能敏感场景建议用StringBuilder或SLF4J占位符。
String.format 里数字补零和小数截断怎么写才不丢精度
用 String.format 格式化数字时，%05d 看似能补零，但遇到负数会把负号挤到最左，变成 -0012；而 %.2f 表面截两位小数，实际是四舍五入，不是截断——比如 1.239 变成 1.24，但业务要的是 1.23。
真正要截断而非四舍五入，得先用 Math.floor(x * 100) / 100.0 手动处理，再格式化；补零若需兼容负数且保持宽度（如总宽 5，负数显示为 -012），不能只靠 %05d，得拆成符号 + 绝对值 + 补零拼接：
int x = -12;
String s = (x < 0 ? "-" : "") + String.format("%0" + (Math.abs(x) + "").length() + "d", Math.abs(x));-
%05d对负数无效：它补的是整个字段宽度，负号占一位，剩下才补零 -
%.2f是舍入，不是截断；Java 没有原生“截断格式符” - 浮点数用
double格式化易出现0.1 + 0.2 = 0.30000000000000004这类问题，货币类场景必须用BigDecimal配合setScale
日期格式化用 SimpleDateFormat 还是 String.format
String.format 不支持日期类型直接格式化——传 Date 或 LocalDateTime 会调用 toString()，输出默认字符串，不是你想要的 yyyy-MM-dd HH:mm。真要格式化日期，必须用 SimpleDateFormat（旧 API）或 DateTimeFormatter（Java 8+ 推荐）。
虽然 String.format 支持 %t 系列转换符（如 %tY-%tm-%td），但它只接受 long 时间戳或实现了 java.util.Formattable 的对象（Date 实现了，但 LocalDateTime 没有），所以：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
-
String.format("%tY-%tm-%td", new Date())可行，但可读性差、难维护 -
String.format("%tY-%tm-%td", LocalDateTime.now())直接抛IllegalFormatConversionException -
SimpleDateFormat非线程安全，多线程下必须每次新建或用ThreadLocal包裹 - Java 8+ 强烈优先用
DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm")，不可变、线程安全
中文乱码、空格截断与 locale 的隐式影响
String.format 默认使用 JVM 启动时的 Locale，这会影响千位分隔符、小数点符号、甚至月份/星期名称。比如在中文环境用 %,d 格式化 1000000，得到 1,000,000（英文逗号），但某些 locale 会用 1.000.000 或 1 000 000；更隐蔽的是，%s 输出字符串时，如果源字符串含中文，而目标控制台或日志系统编码不是 UTF-8，就会显示为 ???——这不是 String.format 的错，但它不负责编码转换。
- 显式指定
Locale可控：String.format(Locale.US, "%,d", 1000000) - 避免依赖默认 locale，尤其做国际化服务时
- 中文文本被截断？检查是否用了
%-10.5s这类带精度限制的格式符——中文字符在 Java 中是 1 个char，但.5s会按 char 数截，5 个 char 可能只有 2–3 个汉字 - 日志中看到方块或问号，先确认输出端（IDE 控制台、Linux terminal、Logback 配置）的字符集是否设为 UTF-8
性能敏感场景下，String.format 和 StringBuilder 拼接怎么选
单纯拼接几个变量，String.format 比 StringBuilder.append 慢 3–5 倍，因为要解析格式串、匹配占位符、做类型检查、再反射调用对应格式化逻辑。JIT 编译后差距缩小，但高频日志（如每毫秒一条）仍建议直拼。
- 日志语句中写
log.debug("user={} balance={}", uid, balance)（SLF4J）比log.debug(String.format("user=%s balance=%.2f", uid, balance))更快且延迟低 -
String.format的缓存机制仅限于编译期常量格式串，运行时拼出来的格式串无法复用解析结果 - 如果格式串本身来自配置（如数据库查出的模板），必须用
String.format，但要注意预编译校验——非法格式符会导致运行时报UnknownFormatConversionException - Android 上
String.format开销更大，官方文档明确建议用Resources.getString(int, Object...)替代
格式化这件事，看着简单，实则每一步都卡在类型、locale、编码、精度四个维度上。最容易被忽略的，是把 String.format 当万能胶水——它不处理编码，不保证线程安全，不支持局部截断，也不该出现在性能热区。
