Java 21 的 switch 模式匹配是编译器级优化，支持类型检查、变量绑定与分支分发；case Integer i -> 比 instanceof + 强转更安全，因避免重复类型声明和 ClassCastException；需显式处理 null；守卫模式要求纯布尔表达式；record 解构要求字段名一致且非 private；分支按书写顺序匹配，首个匹配即执行。
Java 21 已将 Pattern Matching for switch 转为正式特性，无需启用预览标志即可直接使用；它不是语法糖，而是编译器级优化，能同时完成类型检查、变量绑定与分支分发——这才是真正减少样板代码的核心。
case Integer i -> 这种写法为什么比 instanceof + 强转更安全
传统 instanceof 后手动强转存在两个隐患：一是重复写类型（(Integer)obj），二是若类型判断逻辑和转换位置不一致，可能引发 ClassCastException。而 case Integer i -> 把类型校验和变量声明合并在一步，编译器保证 i 在箭头右侧必然非 null 且是 Integer 类型。
- 不支持未声明类型的通配绑定，比如
case Object o ->是合法的，但case var v ->在 switch 模式匹配中不被允许（那是instanceof模式匹配才支持的） -
null值会被跳过所有类型模式，必须显式写case null ->或收进default，否则编译报错 - 如果多个
case分支类型可兼容（如case Number n ->和case Integer i ->），编译器会按书写顺序匹配，前者会吞掉后者，触发编译错误
守卫模式（Guarded Pattern）怎么避免逻辑耦合
当仅靠类型不够，还需额外条件时，用 case Integer i && i > 0 -> 这类守卫表达式，比在分支体内加 if 更清晰。它把“类型 + 条件”压缩成单个匹配单元，语义更紧凑。
动态切换AI模型以优化成本与性能。当用户发出“eco mode”、“balanced mode”、“smart mode”或“max mode”等模式指令，或使用“/modes status”查询状态及“/modes setup”配置模式时触发。
- 守卫表达式必须是纯布尔表达式，不能有副作用（如调用修改状态的方法）
- 不支持方法调用返回布尔值以外的类型，例如
case String s && s.length() ->会编译失败，必须写成s.length() > 0 - 守卫中可安全使用已绑定变量（如
i），但不可访问外部作用域中同名局部变量（会遮蔽）
和 record 解构嵌套使用时的典型陷阱
Java 21 支持在 switch 中对 record 做解构匹配，比如 case Point(int x, int y) -> x + y。但要注意：record 字段名必须与构造器参数名完全一致，且字段不可为 private 或带自定义 accessor。
- 若 record 定义为
record Point(Integer x, Integer y) { }，则case Point(int x, int y)仍可匹配，但绑定的是拆箱后的int，遇到null字段会抛NullPointerException - 嵌套 record（如
record Line(Point start, Point end)）支持多层解构：case Line(Point(int sx, int sy), Point(int ex, int ey)) -> ...，但每层括号内字段数必须与 record 声明严格对应 - 不支持部分解构，例如
case Point(int x, _) ->是非法语法，下划线占位符仅在 Java 22+ 预览版中引入，当前（Java 21）不支持
最易被忽略的是：模式匹配的分支顺序不是“最优匹配”，而是“首个匹配”。哪怕你写了更具体的 case Point(int x, int y) 在后，只要前面有个宽泛的 case Object o，它就永远执行不到——这种问题在线上环境很难被单元测试覆盖到，建议用 IDE 的模式匹配高亮或编译期警告（-Xlint:pattern) 提前拦截。
