Java 7+ 的 switch 对 String 不是语法糖，而是编译器生成查找表并结合 hashCode() 与 equals() 双重校验；所有 case 必须是编译期常量，null 值仍抛 NPE，性能优于 if-else 但弱于 int switch。
Java 7+ 的 switch 对 String 不是语法糖，而是编译器生成的查找表 + hashCode() 双重校验
Java 7 开始允许 switch 接 String，但背后没用反射或动态分发——JVM 本身不支持字符串跳转，所以编译器必须把它“翻译”成 JVM 能执行的指令。核心思路是：先用 hashCode() 快速分流，再用 equals() 逐个确认，避免哈希冲突导致误判。
常见错误现象：switch 中两个不同 String 值如果 hashCode() 相同（比如 "Aa" 和 "BB"），编译器会在对应分支前插入显式的 equals() 判断，否则可能走错分支。
- 编译后实际生成的是
lookupswitch或tableswitch指令，取决于 case 数量和 hash 分布密度 - 所有
case字符串在编译期就被计算出hashCode()，硬编码进字节码；运行时只做一次hashCode()调用，然后查表 - 空指针风险仍在：如果
switch表达式为null，会直接抛NullPointerException，不会进 default
String switch 编译后性能不如 int switch，但比 if-else 链稳定
虽然编译器做了优化，但相比原始 int 类型的 switch，String 版本多出至少一次方法调用（hashCode()）和若干次 equals() 比较。不过它比手写的长 if-else if-else 更可控——后者是线性查找，最坏 O(n)，而编译后的 String switch 平均接近 O(1)（哈希表查找），且分支顺序不影响性能。
- case 数少于 3 个时，javac 可能直接退化为
if-else，不生成查找表 - 大量 case 且字符串 hash 分布集中（比如都以相同前缀开头），会导致哈希碰撞增多，
equals()调用次数上升 - 注意 JIT 优化边界：HotSpot 对频繁执行的
String switch会内联hashCode()和部分equals()，但前提是字符串内容稳定、无逃逸
编译期要求严格：所有 case 必须是常量表达式，且不能有重复逻辑值
所谓“常量表达式”，不只是字面量——可以是 static final String，但不能是运行时拼接（如 "a" + getSuffix()）、不能是 new String("abc")。编译器需要在编译阶段就拿到每个 case 的确切值和 hash，才能建表。
立即学习“Java免费学习笔记（深入）”；
- 重复的
case值（比如两个"hello"）会报编译错误：duplicate case label - 看似不同但
equals()为 true 的字符串（如new String("x")和"x"）不能同时作为 case，因为前者不是常量表达式，编译直接失败 - 使用
var声明的局部变量即使赋了字符串字面量，也不能用在 case 中——var s = "a"中的s不被视为编译时常量
反编译验证是最靠谱的判断方式，别信文档或猜测
想确认某段 String switch 到底怎么实现的？唯一可靠办法是编译后用 javap -c 看字节码。你会看到类似这样的结构：先调 hashCode()，接着一堆 lookupswitch 表项，每个表项指向一段含 if_acmpeq 或 invokevirtual String.equals 的校验代码。
- 示例命令：
javac MySwitch.java && javap -c MySwitch - 重点关注字节码中是否出现
lookupswitch/tableswitch，以及紧随其后的if_acmpeq或invokevirtual指令 - 如果 case 全是编译期可算出 hash 的字面量，但数量极少（如只有 2 个），字节码里可能根本看不到
lookupswitch，而是纯if_icmpeq——这是 javac 主动降级的结果
底层没有魔法，只有编译器在字节码层面做的务实权衡。真正容易被忽略的是：hash 冲突处理逻辑完全由编译器生成，你无法干预，也看不到源码里的对应语句——它藏在字节码里，且每处 case 的校验顺序可能因编译器版本微调而变。
