Java框架应避免字符串隐性延迟：拼接用预估容量的StringBuilder，解析用指定编码的new String(bytes, UTF_8)，子串切片后显式new String断开引用，状态标识优先用字面量或intern()复用。
Java 框架底层处理字符串时，重复创建对象是隐性延迟的主要来源之一——不是单次开销大，而是高频累积后加剧 GC 压力、抬高响应毛刺。关键不在于“少用字符串”，而在于让每次构造、拼接、解析都避开无谓的副本和中间对象。
拼接统一走 StringBuilder，且预估容量
框架中大量存在日志组装、SQL 拼写、HTTP 路径生成等场景，若用 + 或 +=，每次都会新建 StringBuilder → toString() → 丢弃，循环中极易产生数十甚至上百个临时 String 实例。
- 始终用
new StringBuilder(预估长度)，比如拼接 URL 路径可按 “/api/v1/user/” + 12位 ID + “/profile” 预估为 48，避免内部 char[] 多次扩容复制 - 不要在方法外声明一个
StringBuilder然后在循环里反复setLength(0)——JVM 对短生命周期对象优化很好，新建反而更轻量 - 多线程共享拼接逻辑极少，优先选
StringBuilder；真需同步，也应由上层加锁，而非盲目换StringBuffer
解析阶段绕过隐式 new String(byte[])
框架常从网络或磁盘读取字节数组（如 HTTP body、JSON payload），再转成 String。直接调用 new String(bytes) 会触发两次拷贝：一次进 JVM 默认编码解析器，一次复制到新 char[]；若未指定编码，还可能因平台差异导致乱码或额外异常处理。
- 一律使用
new String(bytes, StandardCharsets.UTF_8)，跳过 Charset 查找和默认编码适配开销 - 对固定格式响应（如 JSON 中的 status 字段），解析后立即
intern()（仅限已知低基数值，如 "OK"、"NOT_FOUND"），避免后续反复 equals 判定时堆中存多份 - 若同一字节数组需多次构建字符串（如重试日志、调试输出），缓存
String引用，而非每次 new
字段提取与子串处理强制隔离
框架解析 JSON、CSV 或表单数据时，常通过 substring() 提取字段值。JDK7+ 虽已修复共享底层数组问题，但若原始文本极大（如 1MB 日志行），而只取其中 10 字符的字段，仍可能因引用滞留拖慢 GC。
立即学习“Java免费学习笔记（深入）”；
- 对超长源串做切片后，显式用
new String(str.substring(...))断开与原 char[] 的联系 - 避免
jsonNode.get("name").asText().intern()这类链式调用——先生成堆对象再入池，白占一次内存 - 字段名（如 "id"、"email"）属于典型低基数高复用字符串，建议在反序列化入口（如 Jackson 的
KeyDeserializer）统一intern()，而非业务层零散处理
状态标识与配置键优先复用字面量或静态常量
框架内部大量使用字符串表示状态、协议方法、配置路径等，如 "GET"、"application/json"、"redis.host"。这些值本质是枚举语义，完全可用不可变对象安全复用。
- 禁止写
new String("POST")或String.valueOf("PUT")，直接用字面量，由 JVM 自动入常量池 - 对动态加载的配置键（如 Spring Environment 获取的
environment.getProperty("db.timeout")），若确认取值集合有限，可在首次获取后intern()并缓存引用 - 自定义注解属性、AOP 切点表达式中的字符串字面量，编译期即固化，无需 runtime 干预
