Java switch仅支持String、枚举、基本类型及对应包装类，不支持boolean、任意对象或复合逻辑；需单值等值判断，多条件或链式调用必须用if-else。
switch 在 Java 中只支持有限类型，别硬套
Java 的 switch 从 14 开始支持 String、枚举、基本类型和封装类（Integer、Character 等），但不支持任意对象或 boolean。如果条件是 user.getStatus().getCode() 这种链式调用结果，或者需要判断 list.size() > 5 && list.get(0) != null 这类复合逻辑，switch 直接写不了——不是性能问题，是语法不通过。
常见错误现象：switch 表达式返回 boolean 或自定义对象，编译报错 incompatible types: xxx cannot be converted to int, char, String, or enum。
- 能用
switch的前提是：分支依据是单个可枚举/可哈希的值，且类型在白名单内 - 如果条件依赖多个变量（比如
status == ACTIVE && role == ADMIN），只能用if-else - JDK 17+ 可用
switch表达式（带->和yield），但依然不扩展支持类型范围
简单等值判断时 switch 通常更快，但 JIT 会让差距变小
对 5 个以上等值分支，switch 编译后常生成跳转表（tableswitch）或二分查找（lookupswitch），时间复杂度接近 O(1)；而长串 if-else if 是顺序判断，最坏 O(n)。但现代 JVM（HotSpot）会对频繁执行的 if-else 做分支预测优化，实际差异往往在纳秒级。
关键影响点不在“写法”，而在“是否被 JIT 编译”：冷路径下 switch 可能略快；热路径下两者几乎无差别。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 测试时别用
System.nanoTime()测单次调用——JIT 没生效，数据没意义 - 用 JMH 基准测试，且确保预热充分（如
@Fork(jvmArgs = {"-XX:+TieredStopAtLevel=1"})可禁用 C2 编译，观察原始差异 - 字符串
switch底层仍靠hashCode()+equals()，和if (s.equals("a"))多次调用相比，可能更省一次equals，但不绝对
可读性与维护性比微秒级性能更重要
当分支逻辑开始包含 guard clause、前置校验或副作用（如日志、状态变更），硬塞进 switch 会让代码难读。比如：
if (user == null) throw new IllegalArgumentException();
if (user.isBlocked()) return Status.REJECTED;
switch (user.getRole()) { ... }
这种混合场景下，强行统一成 switch 反而增加理解成本。
-
if-else更灵活：支持布尔表达式、短路求值、提前 return/break -
switch更安全：Java 14+ 默认switch表达式要求穷尽所有 case，编译器能帮你 catch 遗漏分支（配合sealed类效果更好） - 团队已有规范优先：如果代码库约定“状态机走
switch，权限校验走if”，就别为性能破例
容易被忽略的细节：default 分支和 null 安全
用 switch 处理 String 或 Integer 时，null 会直接抛 NullPointerException，而 if-else 可以显式判空。另外，switch 忘写 default 在语句式（非表达式）中虽不报错，但可能掩盖逻辑漏洞。
- 字符串 switch 前务必先判空：
if (s == null) handleNull(); else switch(s) { ... } - 用
switch表达式（switch (x) { case "a" -> 1; default -> 0; }）时，default是强制的，但null仍会 NPE - 枚举
switch若未来新增枚举值，又没写default，运行时可能走到意外分支——用sealed类 +switch表达式可让编译器强制覆盖
性能数字永远在变，但 null、类型边界、分支覆盖这些坑，每次写都得重新想一遍。
