两种JavaScript Switch写法的时间复杂度对比及底层原理探究

问题背景 #

我写了一段根据URL路径执行逻辑的代码，最初用的是常规Switch写法，在default分支处理正则匹配场景：

const pathname = document.location.pathname;
switch (pathname) {
    case "/foo": //...
    case "/bar": //...
    case "/baz": //...
    default:
        if (/^\/user\/\w+\/likes/.test(pathname)) {
            // ...
        }
        else if (/^\/blog\/\d+/.test(pathname)) {
            // ...
        }
}

有人建议改成switch(true)的写法，把所有判断都放在case分支里：

switch (true) {
    case pathname === "/foo": //. ..
    case pathname === "/bar": // ...
    case pathname === "/baz": // ...
    case /^\/user\/\w+\/likes/.test(pathname): // ...
    case /^\/blog\/\d+/.test(pathname): // ...
}

想对比这两种写法的时间复杂度差异，同时搞清楚JavaScript中Switch语句的底层实现机制——毕竟Java会把常量case编译成查找表，但JS不是编译型语言，不确定是否有类似优化。

一、时间复杂度差异分析 #

第一种写法（常量case + default分支） #

• 对于/foo、/bar这类常量字符串case，JS引擎可以做哈希表优化，直接通过pathname的值快速定位对应的分支，时间复杂度为O(1)。
• 只有当所有常量case都不匹配时，才会进入default分支执行if-else链的正则匹配，这部分是顺序判断，最坏时间复杂度为O(n)（n是正则分支的数量）。
• 整体来看，绝大多数场景下是O(1)的快速命中，只有少数不匹配常量的场景才会触发O(n)的判断，性能更稳定。

第二种写法（switch(true) + 表达式case） #

• 这种写法下，switch的判断条件是固定的true，每个case都需要先计算表达式的值（比如pathname === "/foo"、正则test方法），再判断是否等于true。
• 由于每个case的表达式结果依赖实时计算，引擎无法提前构建哈希表做优化，只能从上到下逐个遍历判断，最坏时间复杂度为O(m)（m是所有case的总数量，包括常量和正则分支）。
• 哪怕前面的常量case能命中，也需要逐个执行表达式判断；如果是后面的正则分支命中，前面所有case的表达式都要先执行一遍，性能随case数量增加线性下降。

二、JavaScript中Switch语句的底层实现逻辑 #

JavaScript虽然是解释型语言，但现代JS引擎（比如V8）会对代码做即时编译（JIT）优化，Switch语句的实现会根据case的类型和数量动态调整：

1. 常量case优化：当case都是字符串、数字等可哈希的常量，且数量达到一定阈值时，引擎会把这些常量构建成哈希表，执行switch时直接用目标值（比如pathname）查哈希表，跳转到对应的分支，避免逐个判断。
2. 无优化场景：如果case包含表达式（比如switch(true)里的pathname === "/foo"、正则test），或者常量类型混杂、数量太少，引擎会退化成顺序判断逻辑，和一串if-else语句的执行逻辑几乎一致——逐个检查case表达式是否等于switch的条件，匹配到就执行对应分支。

简单来说，第一种写法能享受到常量case的哈希优化，而第二种写法完全无法触发这种优化，只能走低效的顺序判断。

内容的提问来源于stack exchange，提问作者Cardinal System