必须用 equals()，因为 == 比的是地址而非内容；字符串比较需防 null（推荐 "value".equals(str) 或 Objects.equals）、注意大小写/空格/区域设置等业务细节，并在高频场景优先预处理转小写后用 equals()。
必须用 equals()，因为 == 比的是地址，不是内容 —— 这不是约定，是 Java 对象模型决定的铁律。
为什么 == 在字符串上几乎总是错的
Java 中 == 对引用类型只判断“是不是同一个对象”，和内容完全无关。哪怕两个字符串字面量一模一样，只要不是来自常量池或没被 intern() 过，== 就可能返回 false。
- 用户输入（
Scanner.nextLine()）、JSON 解析结果、数据库查出的字段，全都是堆中新创建的String实例，== "yes"必然失败 - 即使写
new String("abc") == "abc"，也返回false—— 前者在堆，后者在常量池，内存地址不同 - 唯一能靠
==蒙对的场景：两个字面量（如"hello" == "hello"），但这是常量池优化的副作用，绝不能当逻辑依赖
equals() 的安全写法：顺序和 null 处理
直接调用 str.equals("value") 有风险：如果 str 是 null，立刻抛 NullPointerException。生产环境常见崩溃点。
- 推荐把字面量放前面：
"value".equals(str)—— 字面量不可能为null，安全兜底 - 更通用方案：用
Objects.equals(str1, str2)，它内部已判空，null和任何值比较都返回false - 别写
str != null && str.equals("x")—— 多一次判空，代码啰嗦，且易漏
大小写、空格、区域设置这些“业务细节”不能靠 equals() 一刀切
equals() 严格区分大小写、不忽略首尾空格、也不适配土耳其语或德语等特殊规则。业务逻辑一旦涉及这些，就得主动处理。
Android数据格式解析对象JSON用法 WORD版
下载
本文档主要讲述的是Android数据格式解析对象JSON用法；JSON可以将Java对象转成json格式的字符串，可以将json字符串转换成Java。比XML更轻量级，Json使用起来比较轻便和简单。JSON数据格式，在Android中被广泛运用于客户端和服务器通信，在网络数据传输与解析时非常方便。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
立即学习“Java免费学习笔记（深入）”；
- 忽略大小写？优先用
str.equalsIgnoreCase("ABC")，但注意性能损耗（见下条） - 防空格误输？先
trim()："abc".equals(str.trim()) -
多语言场景慎用
equalsIgnoreCase()：它底层调用Character.toLowerCase()，对某些字符（如德语ß）会做字符串扩展，单次比较可能触发多次内存分配，百万级匹配时 CPU 直接飙高 - 高频比较（如风控规则引擎、日志关键词扫描）？预处理统一转小写 +
equals()，比反复调用equalsIgnoreCase()快 37% 以上
性能与可读性的平衡点在哪
别迷信“高级方法”。equals() 是最轻量、最可控的内容比较；equalsIgnoreCase() 是带代价的便利；正则或 Pattern.compile() 更重，只在真正需要模式匹配时才用。
- 登录校验、菜单选项、配置开关这类确定性字符串匹配，无脑用
"login".equals(input) - 搜索框输入、用户昵称模糊匹配？考虑
toLowerCase()预处理后equals()，或引入Apache Commons Lang的StringUtils.equalsIgnoreWhitespace() - 永远避免同时写
str.equals("x") || str.equalsIgnoreCase("X")—— 逻辑冗余，且equalsIgnoreCase()已覆盖前者
最常被忽略的一点：字符串比较从来不是孤立操作。它往往嵌在 if 判断、switch 表达式、Map key 查找里。一旦用了 == 或忘了判 null，问题不会立刻暴露，而是在某个边界输入、某次部署后突然崩掉 —— 而修复成本远高于写对第一行 equals()。
