Java中应优先使用String.toUpperCase(Locale)转大写，它正确处理Unicode、Locale及特殊字符（如德语ß、土耳其语i）；手动ASCII加减易出错且不支持国际化，仅当100%确定输入为ASCII a–z时才可考虑。
Java里用toUpperCase()转大写最稳妥
绝大多数场景下，直接调用String.toUpperCase()就完事了，它内部已处理好Unicode、Locale、非ASCII字符（比如德语ß、土耳其语i）等边界情况。硬掰ASCII加减看似快，实则错得离谱——Java的char是UTF-16码元，不是ASCII；而且小写字母不连续分布在Unicode里（比如带重音的à、ç），更别说某些语言的大写规则根本不是“+32”能覆盖的。
常见错误现象："café".toUpperCase()用ASCII加减会把é变成ï（因为只改了e，没动é），而正确结果应是"CAFÉ"；再比如土耳其语"i".toUpperCase()在默认Locale下返回"I"，但在new Locale("tr")下必须返回"İ"（带点大写I），toUpperCase()能自动适配，手算完全做不到。
- 始终传入明确
Locale参数，比如str.toUpperCase(Locale.ENGLISH)，避免受系统默认Locale影响（尤其服务器部署环境可能和本地不同） - 不要对单个
char用toUpperCase()，它返回的是int且可能超出char范围（如德语ß转大写是"SS"，长度翻倍） - 性能上，
toUpperCase()确实有对象创建开销，但除非你在循环里每秒处理百万级字符串，否则别过早优化
什么时候真得碰ASCII加减？几乎不用
只有当你**100%确定输入全是ASCII a–z**，且**不需要考虑任何国际化、Locale、可读性、维护性**时，才可能用c >= 'a' && c 。但这种假设极脆弱：前端传参混入全角字母、日志里截取的字符串含emoji、数据库字段意外存入中文标点……都会让这个逻辑静默出错。
使用场景极其狭窄：嵌入式Java（资源极度受限）、某段只跑内部测试数据的脚本、或做算法题（题目明确限定输入为ASCII小写字母）。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- ASCII加减本质是
(c - 'a') + 'A'，比- 32稍安全，但依然掩盖了类型意图 - 如果真要用，务必加校验：
if (c >= 'a' && c ，否则数字或空格会被错误转换 - 注意
char是无符号16位，减法不会溢出，但结果若不在\u0000-\uFFFF范围内，强转char会截断高位——不过ASCII范围内没问题
toUpperCase()的坑：Locale不传就踩雷
不传Locale参数的toUpperCase()会用Locale.getDefault()，而这个值在JVM启动后就固定了，可能被其他代码篡改（比如Spring Boot里某个Bean调用了Locale.setDefault()），导致同一行代码在不同模块行为不一致。
典型错误现象：本地开发时"i".toUpperCase()返回"I"，上线后因容器镜像Locale设为tr_TR，突然返回"İ"，前端页面排版错乱或校验失败。
- 生产环境一律显式指定
Locale.ROOT（最中立，无视语言规则）或Locale.ENGLISH（兼容大部分拉丁系需求） - 如果业务真依赖Locale（比如多语言后台生成PDF标题），必须确保整个调用链路的Locale可控，而不是靠默认值
- 注意
String.toUpperCase(Locale.ROOT)仍会处理Unicode大小写映射（如ffi→FFI），它只是不应用语言特定规则
性能敏感场景怎么选？先测，别猜
有人以为ASCII加减一定更快，但HotSpot对toUpperCase()做了深度优化（比如短字符串内联、分支预测、避免新建char[]），实际差异往往在纳秒级。真正拖慢的从来不是这个函数，而是你把它放在高频循环里反复调用，或者对超长字符串（如10MB日志文本）无脑调用。
可给出简短示例对比：
// 慎用：看起来快，但错
String fastButWrong = input.chars()
.mapToObj(c -> (char)(c >= 'a' && c <= 'z' ? c - 32 : c))
.collect(StringBuilder::new, StringBuilder::append, StringBuilder::append)
.toString();
<p>// 推荐：清晰、正确、JVM优化过
String safeAndFastEnough = input.toUpperCase(Locale.ROOT);</p>- 如果压测发现
toUpperCase()是瓶颈，优先考虑缓存结果（比如对常量字符串提前转好），而不是手写ASCII逻辑 - 对byte数组操作（如网络协议解析）才值得考虑ASCII位运算，但那是
byte层面的事，和String无关 - 记住：Java字符串不可变，每次
toUpperCase()都返回新对象——如果原字符串已经全大写，JVM会返回自身引用（避免复制），这点手写逻辑很难复现
事情说清了就结束。真正难的不是选哪个方法，而是想清楚：你的字符串到底从哪来、会经过哪些系统、未来要不要支持其他语言——这些决定了该用toUpperCase(Locale.ROOT)，还是连String都不该碰。
