BitArray是布尔值紧凑容器而非位运算工具；其And()为逐元素逻辑与，非二进制位与，要求等长且原地修改；CopyTo默认LSB-first，协议常用MSB-first，需手动翻转；固定长度开关推荐直接用int。
BitArray 不是位运算工具，它只是布尔值的紧凑存储容器；真要位运算，请直接用 int、long 或 byte 配合 &、|、^、、<code>>>。
BitArray.And() 是逐元素逻辑与，不是二进制位与
调用 bitArray1.And(bitArray2) 时，它对两个数组相同索引位置执行 true && true → true，不是把整个数组当一个整数做二进制位与。这意味着：
- 长度必须严格相等，否则抛出
ArgumentException - 短数组不会自动补零——它根本不接受不同长度的参数
- 结果是原地修改
bitArray1，返回的是this引用，不是新对象 - 如果你本意是“把两个掩码合并成一个整数标志”，这一步就完全走偏了
BitArray.CopyTo() 的字节序默认是 LSB-first，协议常用 MSB-first
想把 BitArray 转成 byte[] 发网络或存文件？别直接 CopyTo(bytes, 0) 就完事。它的位序是低位在前（LSB-first），而绝大多数协议（如 MQTT、HTTP header flag 字段）要求高位在前（MSB-first）。
- 例如
new BitArray(new byte[] { 0b10000000 })构造后，Get(0)返回true，但CopyTo(bytes, 0)得到的字节仍是0b10000000——看似一样，实则内部索引映射已反转 - 正确做法：先用
CopyTo得到原始字节数组，再对每个字节调用System.Numerics.BitOperations.RotateLeft(b, 4)或查表翻转位序 - 如果只是临时调试，用
BitConverter.ToString(bytes)看十六进制更安全，别依赖控制台打印的True/False序列
固定长度开关管理别用 BitArray，直接用 int
管理 32 个功能开关？别用 BitArray。直接用 int 更自然、更快、更兼容：
flags |= 1 — 开启第 5 位（从 0 开始）flags &= ~(1 — 关闭第 3 位(flags & (1 — 查询第 7 位
优势明显：
- 编译器能内联、CPU 单指令完成
- 调试器可直接切十六进制视图
- 能传给 Win32 API 或序列化框架
-
BitArray每次Get()都要算index / 32、index % 32、查int[]、再位移掩码，还带同步锁开销
BitArray 唯一勉强适用的场景非常窄
只有当同时满足以下条件时，才考虑 BitArray：
- 长度动态且远超 65536（比如百万级用户在线状态缓存）
- 内存极度敏感（堆节省 >85% 是硬指标，不是“可能省点”）
- 必须对接旧接口（如 .NET Framework 2.0 COM 组件明确要求
BitArray参数） - 随机读写频率远高于批量操作，且无法预估上限（
bool[]容易爆内存，byte[]+ 手动位操作又得自己管扩容）
它不是线程安全的；多线程读写必须加锁，而 int 的单次位操作通常是原子的（前提是不对齐跨字长）。最容易被忽略的是：你根本不需要它——99% 的权限/标志位场景，int 或 Enum with [Flags] 就够了。
