推荐使用 Character.toUpperCase() 和 Character.toLowerCase() 处理单个字符大小写转换，因其遵循 Unicode 标准，正确支持 ß、İ、Σ 等特殊字符；避免用 ASCII 加减法硬算，易致乱码或逻辑错误。
用 Character.toUpperCase() 和 Character.toLowerCase() 最安全
直接调用 Character 类的静态方法，是处理单个字符大小写转换的推荐方式。它不只是简单加减 ASCII 值，而是按 Unicode 标准处理，能正确应对德语 ß、土耳其语 İ、希腊语 Σ 等特殊字符。
常见错误现象：用 ch + 32 或 ch - 32 硬算，结果在非 ASCII 字符（比如中文、emoji、带重音字母）上返回乱码或不变；甚至对大写 'Z' 加 32 变成 'z' 是对的，但对 'É' 就完全失效。
- 只对单个
char有效，字符串需配合String.toCharArray()+ 循环 - 遇到 null 字符或无效 Unicode 码点会抛
IllegalArgumentException - 性能略低于纯 ASCII 加减（但差距微乎其微，别过早优化）
字符串批量转换别手写循环，用 String.toUpperCase() / toLowerCase()
对整个字符串做大小写转换，不要自己遍历每个 char 再调 Character 方法拼接——这容易丢掉 locale 行为，也忽略字符串不可变性带来的额外开销。
使用场景：HTTP 头字段名标准化、SQL 关键字预处理、用户输入归一化等。
立即学习“Java免费学习笔记（深入）”；
-
"HELLO".toLowerCase()默认用系统 locale，可能在土耳其环境把'I'转成'ı'（无点 i），导致 bug；如需确定行为，显式传Locale.ENGLISH - 空字符串、
null输入会 NPE，务必先判空 - 返回新字符串，原字符串不变——这是 Java 字符串设计决定的，不是 bug
纯 ASCII 场景下用加减法可以，但必须加范围检查
如果 100% 确定输入只有 a–z / A–Z（比如协议解析、固定格式编码），用 ASCII 差值（32）确实快且无 locale 干扰。但跳过校验等于埋雷。
错误示例：ch += 32 直接作用于所有字符，导致数字 '9' 变成 'i'，符号 '@' 变成 '`'。
- 判断条件必须是：
ch >= 'a' && ch 或 <code>ch >= 'A' && ch - 小写转大写：用
(char)(ch - 'a' + 'A')比ch - 32更自文档，避免魔数 - Java 中
char是无符号 16 位整数，减法不会溢出，但逻辑错照样出错
StringBuilder 处理长字符串时注意避免重复创建
当要对几千字符以上的字符串做逐字符大小写翻转（比如把 "HelloWorld" → "hELLOwORLD"），用 String 的 toUpperCase() 不适用，得手动操作。此时直接改 StringBuilder 内部数组比反复 substring() 拼接高效得多。
容易踩的坑：有人用 sb.replace(i, i+1, String.valueOf(...))，每次调用都新建子串对象，GC 压力陡增。
- 正确做法：用
sb.charAt(i)取字符 → 判断 →sb.setCharAt(i, newChar) -
setCharAt()是 O(1)，而replace()是 O(n)，长度越大差距越明显 - 记得提前
sb.ensureCapacity()，避免内部数组多次扩容
实际项目里最常出问题的，不是“该用哪种方法”，而是混用不同层级的 API —— 比如对用户昵称（可能含 emoji）用 ASCII 加减，或对 HTTP Header 名（应全 ASCII）却依赖 locale 敏感的 toLowerCase()。边界意识比语法细节更重要。
