必须显式指定locale（如locale.english）并判空，因默认依赖系统locale易出错且方法返回新字符串；null会抛npe；unicode扩展字符可能导致长度变化。
String.toUpperCase() 和 toLowerCase() 怎么用才不踩坑
Java 里转大小写最直接的方法就是 toUpperCase() 和 toLowerCase()，但它们默认依赖系统 locale，一换环境就可能出错——比如土耳其语环境下 "i" 转大写不是 "I"，而是 "İ"（带点大写 i），导致字符串比较失败。
实操建议：
- 只要业务逻辑涉及比较、哈希、存储或跨系统交互，必须显式传入
Locale.ENGLISH或具体确定的 locale，别依赖默认值 - 如果只是界面显示用，且明确知道运行环境（如国内安卓 App），默认调用勉强可用，但不推荐
- 注意 null 安全：这两个方法对
null会抛NullPointerException，调用前务必判空或用Objects.toString(str, "").toUpperCase(Locale.ENGLISH)
示例：
String s = "hello WORLD"; System.out.println(s.toUpperCase()); // 可能因 locale 异常 System.out.println(s.toUpperCase(Locale.ENGLISH)); // 稳定输出 "HELLO WORLD"
为什么 String 是不可变的，转大小写后要重新赋值
String 在 Java 中是不可变类，所有“修改”操作（包括大小写转换）都返回新对象，原变量内容不变。这是最容易忽略的一点，尤其从 Python 或 JavaScript 转过来的人常以为 str.toLowerCase() 是就地修改。
立即学习“Java免费学习笔记（深入）”；
常见错误现象：
- 写了
str.toLowerCase();却没接返回值，结果打印还是原字符串 - 在循环里反复调用但没更新引用，误以为“已经转完了”
正确做法：
- 必须显式赋值：
str = str.toLowerCase(Locale.ENGLISH); - 如果只是临时使用，直接用返回值：
if (input.equals("quit".toLowerCase(Locale.ENGLISH))) { ... }
性能和内存开销：频繁转大小写要不要缓存
每次调用 toUpperCase() 都会新建 String 对象，底层复制 char 数组。对短字符串影响小，但若在高频路径（如解析 CSV 每行字段名、HTTP Header 名标准化）中反复调用，GC 压力会上升。
使用场景判断：
- 静态常量（如配置项、枚举标识）：直接定义成大写/小写形式，避免运行时转换，例如
public static final String STATUS_ACTIVE = "ACTIVE"; - 用户输入或动态文本：无法预知内容，只能按需转换，但可考虑复用
StringBuilder+ 手动遍历（仅当 profiling 确认是瓶颈时） - 不建议自己缓存转换结果（如用
Map<string string></string>），key 的 hash 计算和 map 查找开销通常比直接转换还高
替代方案：Apache Commons Lang 的 StringUtils 更省心吗
如果你已经在用 commons-lang3，StringUtils.upperCase(str) 和 StringUtils.lowerCase(str) 确实更安全：它们自动处理 null（返回 null 而非抛异常），也支持传入 Locale。但要注意——它**不默认指定 locale**，底层仍是调用 JDK 方法，所以 locale 陷阱依然存在。
实操建议：
- 用
StringUtils.upperCase(str, Locale.ENGLISH)替代裸调String方法，null 安全 + locale 明确 - 不要只图方便写
StringUtils.upperCase(str)，它等价于str.toUpperCase()，隐患照旧 - 引入第三方库只为解决 null 安全？不如写个两行工具方法，避免额外依赖
容易被忽略的是：大小写转换本身不改变字符串长度，但 Unicode 中某些字符（如德语 ß → SS）会膨胀，toLowerCase() 在特定 locale 下也可能扩展字符，实际长度可能变长——如果代码里写了固定长度截断或数组索引，这里就埋了雷。
