基于整数的开关可以优化为非常高效的代码。基于其他数据类型的开关只能编译为一系列if()语句。

因此，C和c++只允许对整型进行切换，因为它对其他类型没有意义。

c#的设计者认为风格很重要，即使它没有什么优势。

Java的设计者显然和C的设计者思想相似。

除了以上好的论点，我还要补充一点，今天很多人认为switch是Java过去过程化的过时残余(回到C时代)。

我不完全同意这个观点，我认为switch在某些情况下有它的用处，至少因为它的速度，无论如何，它比我在一些代码中看到的一系列级联数字要好…

但实际上，有必要考虑一下需要开关的情况，看看它是否不能被更面向对象的东西所取代。例如Java 1.5+中的枚举，也许是哈希表或其他集合(有时我后悔我们没有(匿名)函数作为第一类公民，就像Lua -没有开关-或JavaScript)，甚至是多态性。

从1.7开始直接使用String的例子如下:

public static void main(String[] args) {

    switch (args[0]) {
        case "Monday":
        case "Tuesday":
        case "Wednesday":
            System.out.println("boring");
            break;
        case "Thursday":
            System.out.println("getting better");
        case "Friday":
        case "Saturday":
        case "Sunday":
            System.out.println("much better");
            break;
    }

}

如果您没有使用JDK7或更高版本，可以使用hashCode()来模拟它。因为String.hashCode()通常为不同的字符串返回不同的值，并且总是为相同的字符串返回相同的值，所以它是相当可靠的(不同的字符串可以产生与评论中提到的@Lii相同的哈希代码，例如“FB”和“Ea”)。

所以，代码看起来是这样的:

String s = "<Your String>";

switch(s.hashCode()) {
case "Hello".hashCode(): break;
case "Goodbye".hashCode(): break;
}

这样，你在技术上开启了一个整型。

或者，你可以使用下面的代码:

public final class Switch<T> {
    private final HashMap<T, Runnable> cases = new HashMap<T, Runnable>(0);

    public void addCase(T object, Runnable action) {
        this.cases.put(object, action);
    }

    public void SWITCH(T object) {
        for (T t : this.cases.keySet()) {
            if (object.equals(t)) { // This means that the class works with any object!
                this.cases.get(t).run();
                break;
            }
        }
    }
}

不是很漂亮，但这里是Java 6的另一种方式:

String runFct = 
        queryType.equals("eq") ? "method1":
        queryType.equals("L_L")? "method2":
        queryType.equals("L_R")? "method3":
        queryType.equals("L_LR")? "method4":
            "method5";
Method m = this.getClass().getMethod(runFct);
m.invoke(this);

James Curran简洁地说:“基于整数的开关可以优化为非常高效的代码。基于其他数据类型的开关只能编译为一系列if()语句。因此，C和c++只允许在整数类型上切换，因为这对其他类型是没有意义的。”

My opinion, and it's only that, is that as soon as you start switching on non-primitives you need to start thinking about "equals" versus "==". Firstly comparing two strings can be a fairly lengthy procedure, adding to the performance problems that are mentioned above. Secondly if there is switching on strings there will be demand for switching on strings ignoring case, switching on strings considering/ignoring locale,switching on strings based on regex.... I would approve of a decision that saved a lot of time for the language developers at the cost of a small amount of time for programmers.