Java 11+ 的 stripLeading() 和 stripTrailing() 精准移除 Unicode 空白字符（如\u3000、\u2000），基于 Character.isWhitespace()，覆盖更广且不修改原字符串；但不处理 null，性能略低于 trim()，仅适用于国际化文本或需精细空白控制的场景。
String.stripLeading() 和 stripTrailing() 在 Java 11+ 中怎么用
Java 11 引入了 stripLeading() 和 stripTrailing()，它们比 trim() 更精准：只处理 Unicode 空白字符（如 '\u2000'、'\u3000'），且不碰制表符 '\t' 或换行符 '\n' —— 这点和 trim() 不同。trim() 只删 ASCII 控制字符（U+0000–U+0020），漏掉很多全角空格、不间断空格等。
-
stripLeading()只从开头移除 Unicode 空白（Character.isWhitespace(c)为 true 的字符） -
stripTrailing()同理，只动结尾 - 两者都返回新字符串，原字符串不变
- 空字符串或全空白字符串返回空字符串，不会抛异常
stripLeading() vs trim()：为什么你该换掉 trim()
如果你处理的是国际化文本（比如含中文全角空格 '\u3000'、日文空格、Unicode 不间断空格 '\u00A0'），trim() 完全无效。它只认 ' '、'\t'、'\n'、'\r'、'\f' 这几个 ASCII 控制符。
- 示例：
" hello".trim()（开头是全角空格'\u3000'）→ 结果仍是" hello"；而" hello".stripLeading()→"hello" -
stripLeading()底层调用Character.isWhitespace()，覆盖更广，包括'\u2000'–'\u200F'、'\u2028'、'\u2029'、'\u3000'等 - 但注意：
'\t'、'\n'、'\r'仍被识别为 whitespace，所以它们也会被删 —— 这和直觉可能不符，别误以为“只删全角空格”
常见误用：stripLeading() 后接 length() 判断空字符串？小心 NPE 风险
有人写 if (s.stripLeading().length() == 0) 来判断“是否只有前导空白”，这逻辑没问题，但容易忽略原始字符串为 null 的情况 —— stripLeading() 本身不接受 null，会直接抛 NullPointerException。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 错误写法：
s.stripLeading().length()（没判空） - 安全写法：
s == null ? true : s.stripLeading().isEmpty() - 或者统一用
Objects.toString(s, "").stripLeading().isEmpty() - 别依赖
stripLeading()做空值防护 —— 它不是StringUtils.stripStart()那种工具方法
性能与兼容性：什么情况下不该用
纯 ASCII 场景下，trim() 比 stripLeading() 快约 2–3 倍（JDK 17 测试），因为 trim() 是纯数组扫描，而 stripLeading() 每个字符都要进 Character.isWhitespace() 查表。
立即学习“Java免费学习笔记（深入）”；
- 高频短字符串处理（如日志字段清洗）、确定只含 ASCII 的场景，继续用
trim()更稳 - Android 开发注意：Android API 26+ 才支持这些方法，低版本会
NoSuchMethodError - 不能替代正则：比如要去掉开头的特定字符（如
'0'或'x'），得用replaceAll("^0+", "")，不是stripLeading()的设计目标
真正需要精细化控制首尾 Unicode 空白时才上 stripLeading()/stripTrailing()；否则，简单场景 trim() 依然够用，也更轻量。别为了“用新 API”而改，尤其在性能敏感路径里。
