Java 7+才支持switch(String)，但用户输入的字符串可能因未驻留字符串池导致匹配失败；应先校验白名单或转为char处理，且除零检查须在case内立即执行，不可依赖try-catch或遗漏default异常抛出。
Java里用switch-case写计算器，为什么不能直接传字符串运算符
因为switch在Java 7之前只支持byte、short、int、char和枚举；Java 7+才支持String，但必须是编译期确定的常量——用户输入的String（比如"+"）虽然看起来一样，但运行时对象可能不是字符串池里的同一引用，容易触发default分支或抛NullPointerException（如果没判空）。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 对用户输入的运算符先用
.trim()去空格，再用.equals()做安全判断，别依赖switch(String)直接兜底 - 更稳妥的做法是把运算符映射成
char：用operator.charAt(0)取首字符（前提是只支持单字符运算符，如+、-、*、/），然后switch这个char - 如果一定要用
String版switch，确保输入来自白名单：if (!Arrays.asList("+", "-", "*", "/").contains(op)) { throw new IllegalArgumentException(); }
switch-case处理除零和非法操作符的典型错误现象
常见错误是只在case "/"里检查除数是否为0，却忘了把检查逻辑放在实际执行前——结果switch进了case "/"，但除法语句写在break之后，或者被default吞掉异常，导致返回0或抛ArithmeticException而没提示。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 所有
case分支里，数值计算前先校验：比如case '/'中，立刻写if (b == 0) { throw new IllegalArgumentException("除数不能为零"); } - 不要把异常处理甩给
try-catch包整个switch——那样会掩盖哪个case出的问题，也违背“明确错误来源”原则 -
default分支必须显式抛异常或返回错误码，禁止留空或只写System.out.println("未知操作符")——控制台输出不等于错误反馈，调用方无法感知失败
double类型参与switch-case时的兼容性陷阱
Java不支持switch(double)，编译直接报错incompatible types: possible lossy conversion from double to int。有人试图转成int再switch，结果3.9和3.1全变成3，逻辑全乱。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 运算逻辑本身用
double，但switch只负责分发运算符（char或String），别让它碰数值类型 - 如果真要根据数值范围分支（比如税率分级），改用
if-else if-else，switch不适合浮点区间判断 - 需要序列化/网络传输时，避免把
double强制转long再switch——精度丢失不可逆，且Double.doubleToLongBits()生成的值没法人工维护可读分支
Android或老版本JDK环境下switch-string的降级写法
Android minSdk switch(String)，硬写会编译失败。这时候不能靠IDE自动替换，得手动拆解。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用
if (op.equals("+")) { ... } else if (op.equals("-")) { ... }，顺序按使用频率排（比如+、-放前面），减少平均判断次数 - 如果运算符较多（比如带
%、^、==），抽成Map<string bifunction double>></string>，初始化一次，运行时map.getOrDefault(op, illegalOp)——比长if-else更易扩展，也规避了switch限制 - 别用
op.hashCode() == "+".hashCode()做判断——哈希冲突虽小但存在，比如"Aa"和"BB"哈希值相同，线上出过真实bug
真正难的不是写对四个case，而是让每个分支的边界检查、类型处理、错误传播都和主流程耦合得足够紧——松一点，输入“1 + 2 / 0”就可能返回NaN而不是报错；再松一点，加个空格或换行符，整个switch就静默走default。
