为何Fish Shell中switch/case语句执行速度远低于else if分支？

这个问题和switch语法本身的通用设计完全无关，纯粹是fish的switch实现机制、常规写法带来的额外开销，具体拆解为三个核心原因：

• fish的switch根本没有短路求值优化
  你最初写switch版本时，为了用正则匹配文件后缀，大概率是把判断逻辑写在case的命令替换块里，类似这种结构：

  for entry in (ls $all)
    switch $entry
      case (string match -rq '\.sh$' $entry; and echo $entry)
        echo "   $entry"
      case (string match -rq '\.md$' $entry; and echo $entry)
        echo "   $entry"
      # 其他十几个匹配分支
    end
  end
  

  fish处理这类结构时，会在进入switch的第一时间把所有case内部的命令替换全部执行完毕——哪怕第一个case已经完全匹配，也不会跳过后面的所有字符串匹配判断。相当于你每遍历一个文件，就要无意义地跑完全部十几组匹配命令，没有任何短路节省的开销，这是最主要的性能损耗来源。
• 循环体内的switch会重复消耗语法解析成本
  fish的语法解析器不会对循环块内部的switch结构做跨迭代的语法树缓存：每处理一个文件、每进入一次switch块，都会重新解析所有case的通配符规则、参数展开逻辑。而你改写的else if判断链，fish会在首次进入循环时就完成全部条件表达式的预解析和编译，整个遍历过程只做值判断，不会重复消耗解析开销。
• 早期fish版本的switch缺少fallthrough机制带来的额外负担
  你需要单独匹配目录类型（这类文件没有统一的后缀规则）的逻辑，在fish 3.1之前的版本里没法在switch内部实现合法的分支穿透：比如你把目录判断写在匹配所有文件的case '*'分支里，如果判断结果不是目录，根本没法自动落到后面的后缀匹配分支，你只能把所有后缀判断逻辑塞到这个case内部，进一步放大了无短路的性能损耗。

你现在用的else if结构，fish是严格按顺序做短路求值的：只要某一个条件满足，就直接跳出整个判断链，后面的匹配命令根本不会执行；同时整个判断链的语法解析是一次性完成的，没有循环内的重复解析开销，自然和经过长期优化的bash版本性能拉平。

可进一步压缩耗时的优化点 #

• 去掉循环里的外部ls调用，直接用fish内置的for entry in *遍历当前目录的文件列表，完全省去ls的进程启动开销
• 把后缀匹配的顺序调整为高频类型优先，比如常见的可执行文件、配置文件判断放在前面，减少平均匹配次数
• 优先用fish原生通配符做判断，同场景下原生通配符匹配比正则匹配快30%左右

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