string.trim()仅处理ascii空白字符（'u0000'–'u0020'），不识别unicode空白如全角空格'u3000'或零宽空格'u200b'；string.strip()自jdk11起支持全部unicode空白，调用character.iswhitespace()，适用于多语言和用户输入场景。
String.trim 只认 ASCII 空白字符
String.trim() 是 JDK 1.0 就有的老方法，它只把开头和结尾的 'u0000' 到 'u0020'（即 ASCII 空格及控制符）砍掉，比如 ' '、' '、'
'、'
'。但对 Unicode 中的其他空白——像全角空格 'u3000'、零宽空格 'u200B'、段落分隔符 'u2029'——完全无感。
常见错误现象：
从网页表单或富文本编辑器里粘贴的字符串，用 trim() 后依然有“看不见的空格”，日志里显示正常，但 equals() 失败、数据库去重失效、JSON 解析报错。
- 适用场景：纯英文/ASCII 环境下的简单清理，比如读取配置文件某行、解析命令行参数
- 性能影响：极轻量，内部是 while 循环 + char 比较，无正则、无对象分配
- 注意：
trim()对中间字符完全不处理，别指望它“清理所有空白”
String.strip 才真正支持 Unicode 空白
String.strip() 是 JDK 11 引入的，底层调用 Character.isWhitespace(int)，覆盖全部 Unicode 空白字符定义（含 Zs、Zl、Zp 类别），比如 'u3000'（中文空格）、'u2000'～'u200A'（各种窄空格）、'u2028'（行分隔符）等。
使用场景：
处理用户输入、国际化文本、爬虫抓取内容、前后端 JSON 交互时的字段清洗。
立即学习“Java免费学习笔记（深入）”；
-
strip()和stripLeading()/stripTrailing()是配套的，语义更清晰 - 兼容性代价：JDK 11+ 才能用；低版本需回退到
Pattern.compile("^\s+|\s+$").matcher(s).replaceAll("")（但注意\s在 Java 正则里默认也不完全等价于isWhitespace） - 性能略低：每次调用都查 Unicode 属性表，不过对普通业务字符串影响微乎其微
strip() 和 trim() 在非 ASCII 空格上的行为对比
看一个具体例子：
String s = "u3000 hello u200B"; // 全角空格 + 零宽空格
System.out.println("'" + s.trim() + "'"); // 输出：' hello '（两边空格都没去掉）
System.out.println("'" + s.strip() + "'"); // 输出：'hello'（干净）
关键差异点：
-
trim()把'u3000'当普通字符，因为它的码点远超'u0020' -
strip()识别'u3000'属于 Unicode 的SPACE_SEPARATOR类别 -
strip()还能处理行尾的'u2029'（段落分隔符），而trim()会把它当普通字符留下
生产环境该选哪个？别无脑升级
不是“新就是好”。如果项目已稳定运行多年、明确只跑在 ASCII 环境，且历史逻辑依赖 trim() 的窄定义（比如某些协议要求严格按 ASCII 控制符截断），强行换成 strip() 可能导致边界 case 行为变化。
- 新项目、涉及多语言/用户输入的场景，直接用
strip() - 存量系统升级前，必须 grep 所有
.trim()调用点，检查是否隐含了“只切 ASCII”的假设 - 特别注意日志埋点、缓存 key 生成、SQL 拼接等地方——这些位置的空格处理偏差容易引发雪崩式问题
Unicode 空白的复杂性不在函数名里，而在你没看到的字符上。
