将布尔数组转为ushort实现函数可选参数多路复用的效率如何？

首先得明确说：这种方式其实非常高效，完全不用担心性能层面的问题。

为什么高效？ #

位运算本身就是CPU的原生指令，几乎没有额外开销——你把bool数组转成ushort的过程，本质就是把每个bool值映射到ushort的某一位上，就算循环处理16次（因为ushort是16位），这个循环的开销小到可以忽略不计，现代CPU处理这种操作简直是眨眼间的事。而且用这个ushort值做switch条件也很高效，C#对整数类型（包括ushort）的switch会生成跳转表，比嵌套的if-else快得多，分支越多优势越明显。

可以优化的点（不是效率，是健壮性和可读性） #

虽然效率没问题，但可以给你几个小建议让代码更靠谱：

• 边界检查：如果传入的bool数组长度超过16，超出的元素会被忽略，最好在函数里加个判断（比如抛出参数异常或者截断），避免意外丢数据；如果数组长度不足16，要明确剩下的位是设为false还是有其他默认值。
• 可读性优化：直接用ushort做switch条件，后续维护的人可能搞不清每一位对应哪个参数。可以用[Flags]枚举来包装这些位：

  [Flags]
  public enum FunctionArgs : ushort
  {
      None = 0,
      Arg1 = 1 << 0,
      Arg2 = 1 << 1,
      Arg3 = 1 << 2,
      // 按你的参数依次定义
  }
  

  然后把转换函数改成返回这个枚举类型，switch的时候直接用枚举值，代码可读性会提升很多，而且底层还是ushort，效率完全没变。

简化转换代码的示例 #

你可以把转换函数写成这样，更简洁且高效：

namespace firstAsp.Helpers
{
    public class ArgMux
    {
        public static ushort BaToUshort(bool[] parms)
        {
            ushort result = 0;
            // 只处理前16个元素，避免溢出
            for (int i = 0; i < parms.Length && i < 16; i++)
            {
                if (parms[i])
                {
                    result |= (ushort)(1 << i);
                }
            }
            return result;
        }

        // 如果用枚举的话
        public static FunctionArgs BaToFunctionArgs(bool[] parms)
        {
            return (FunctionArgs)BaToUshort(parms);
        }
    }
}

总的来说，你的思路非常棒——利用C#的位运算能力解决可选参数多路复用的问题，既高效又符合你的使用习惯，完全可以放心用。

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