Java字符串转大小写必须显式指定Locale，因默认依赖JVM Locale易致多语言错误；推荐优先用Locale.ROOT保证ASCII确定性映射，纯英文场景可用Locale.ENGLISH，需判空并注意String不可变性。
Java 字符串转大小写时，不带 Locale 参数的 toUpperCase() 和 toLowerCase() 方法极易在多语言环境出错——核心问题不是“能不能转”，而是“按谁的规则转”。默认依赖 JVM 当前 Locale，而不同语言对大小写的定义差异很大，比如土耳其语中 "I" 小写是 "ı"（无点），不是 "i"；希腊语词尾 σ 小写会变成 ς。这些规则若被忽略，会导致字符串比较失败、哈希不一致、搜索漏匹配等隐蔽 Bug。
必须显式传 Locale，不能依赖默认值
只要涉及业务逻辑（如权限校验、缓存 key 生成、数据库查询条件、JSON 字段标准化），一律禁用无参版本。系统 Locale 可能随时变化（比如服务器部署在土耳其机房，或容器镜像 locale 设置为 tr_TR），导致同一段代码在测试和生产行为不一致。
- 推荐优先使用
Locale.ROOT：它绕过所有语言规则，只做 ASCII 字母的确定性映射（a-z ↔ A-Z），适用于技术性字符串，如 HTTP 头名、枚举常量、URL path、配置项 key - 纯英文业务场景可用
Locale.ENGLISH，但需确认输入不含非英语字符（如用户昵称含中文或 emoji） - 面向特定语言用户的界面文本或搜索，则必须用对应语言的 Locale，例如土耳其用户输入：
"İSTANBUL".toLowerCase(Locale.forLanguageTag("tr"))→"istanbul"（正确），而用ENGLISH会得到"istanbul"（错误，丢失语言特性）
Null 安全和不可变性要一起处理
这两个方法对 null 直接抛 NullPointerException，且返回新字符串（String 不可变）。别写 str.toLowerCase().equals("abc") 这类链式调用——一旦 str 为 null 就崩。
- 判空再调用：
str != null ? str.toLowerCase(Locale.ROOT) : "" - 或用工具方法兜底：
Objects.toString(str, "").toLowerCase(Locale.ROOT) - 注意：即使用了 Locale，返回仍是新字符串，原对象不变；频繁调用要考虑 GC 压力，超长文本可考虑复用
char[]的自定义实现
关联操作也要统一 Locale
大小写转换很少孤立存在。equalsIgnoreCase()、正则匹配、甚至 HashMap 的 key 比较都可能隐式依赖 Locale。若只在 toLowerCase() 加 Locale，其他地方没跟上，照样出错。
立即学习“Java免费学习笔记（深入）”；
-
equals不区分大小写？改写为：s1.toLowerCase(trLocale).equals(s2.toLowerCase(trLocale)) - 正则忽略大小写？启用 Unicode 模式：
Pattern.compile("pattern", Pattern.CASE_INSENSITIVE | Pattern.UNICODE_CASE) - Spring 等框架中，从请求头或用户配置动态获取 Locale，并全程透传，避免硬编码
Locale.US等固定值
怎么选对 Locale 实例
别手写 new Locale("tr", "TR")——大小写、分隔符稍错就失效。JDK 提供更健壮的方式：
- 用预定义常量：
Locale.US、Locale.CHINA、Locale.JAPAN最安全 - 动态构造用
Locale.forLanguageTag("zh-Hans-CN")：支持 BCP 47 标准，自动归一化 - 避免
new Locale("zh_CN")（下划线非法）或new Locale("zh", "cn")（地区码小写可能在某些 JDK 版本导致 ResourceBundle 查找不到）
