Java字符串switch必须调用hashCode()是因为JVM跳转指令只支持int类型，编译器需将其转为整型跳转表；哈希匹配后仍需equals()校验以防范冲突，确保准确性。
字符串 switch 为什么必须调用 hashCode()
Java 编译器不支持原生的字符串跳转指令，JVM 的 tableswitch 和 lookupswitch 只接受 int 类型。所以当你写 switch(str)，javac 必须把它“翻译”成 JVM 能执行的形式：先算 str.hashCode()，再拿这个整数去跳。
这步不是可选优化，是强制转换路径——没有 hashCode() 就没法生成跳转表，也就谈不上性能提升。
hashCode() 匹配后为什么还要 equals()
哈希冲突真实存在："Aa".hashCode() 和 "BB".hashCode() 在 Java 中恰好相等（都是 2112），但字符串内容完全不同。
编译器在每个候选 case 分支开头都插入了 str.equals("Aa") 或类似校验。只有 hashCode() 匹配 且 equals() 返回 true，才算真正命中。
常见错误现象：
- 把两个不同字符串故意设成相同哈希值（比如做单元测试时），发现 switch 错误跳进某个分支 → 实际是 equals 没过，会 fallback 到
default或下一个 case - 自定义类重写了
hashCode()但没同步改equals()→ 编译不过，因为 switch 要求 case 值是编译期常量，而非常量对象不被允许
性能差异到底体现在哪几个环节
-
hashCode()值在编译期就计算好了，字节码里直接存着数字，运行时无计算开销 -
tableswitch在分支密集（如 case 值哈希连续）时是 O(1) 跳转；lookupswitch在稀疏时是 O(log n)，仍远快于 if-else 的 O(n) - 但每次匹配都要触发一次虚方法调用
str.equals(...)，如果字符串很长，这个开销可能抵消哈希优势
关键参数差异：
- 分支数 ≤ 3：if-else 通常更快，避免了 hashCode + equals 两次方法调用
- 分支数 ≥ 8 且 case 字符串较短（如命令词 tableswitch
- 输入字符串来自网络或用户输入，未做
intern()：不会复用常量池，但不影响 hashCode 计算逻辑，equals 仍是安全的
null 输入和大小写处理怎么影响底层行为
switch(str) 遇到 null 会直接抛 NullPointerException，连 hashCode() 都不会调——这是语法层面的硬性限制，不是 equals 校验失败。
大小写问题不改变底层机制，但会影响结果：
-
switch(cmd.toLowerCase())是安全的，但每次调用都新建字符串对象，GC 压力上升 - 更高效的做法是预处理输入（比如统一转小写后缓存），或用枚举替代字符串，避免运行时 equals 开销
容易被忽略的一点：所有 case 值必须是编译期常量，这意味着不能是 new String("start") 或拼接表达式（如 "st" + "art" 在某些上下文中也不被认定为常量），否则编译报错 constant string expression required。
