用 & 判断标志位时 == 1 是错的，因为标志位检测应判断某位是否为1，而非结果是否等于1；如 FLAG_READ 为 1，flags & FLAG_READ != 0 才正确，而 == 1 在 flags 含其他位时恒假。
&、|、^ 这些运算符在 Go 里不是语法糖，是直接映射 CPU 指令的底层操作；但新手常因类型隐式转换、符号位误判或比较写法错误导致结果完全不对——比如 flags & FLAG_READ == 1 永远不成立，int8(-1) & 0x0F 得到 0xFF 而非 0x0F。
用 & 判断标志位时为什么 == 1 是错的
这是最常踩的坑。标志位本质是“某一位是否为 1”，不是“整个值是否等于 1”。
-
FLAG_READ通常定义为1 （即 <code>1），但FLAG_WRITE是1 （即 <code>2），FLAG_EXEC是4……它们互不重叠 -
flags & FLAG_READ的结果要么是0（未设置），要么是FLAG_READ自身（如1、2、4等），绝不会是1以外的值去“碰巧等于 1” - Go 不允许整数直接进
if条件，必须显式转布尔：if flags & FLAG_READ != 0 - 若
flags是int类型而FLAG_READ是uint，会编译报错：invalid operation: flags & FLAG_READ (mismatched types int and uint)
^ 是异或还是取反？为什么翻转标志位有时没效果
^ 在 Go 中永远是**按位异或**，没有单目逻辑非含义；它只有两个操作数时才有效。
- 单目写法如
^x是按位取反（即~x），但结果取决于类型宽度和符号：对uint8(0)得0xFF，对int8(0)得-1（补码） - 用
flags ^ FLAG_DEBUG切换标志位，前提是FLAG_DEBUG必须是 2 的幂（如1 ），否则只影响最低几位，高位被忽略 - 失效常见原因：变量初始为零值
0，0 ^ FLAG_DEBUG == FLAG_DEBUG，但下一次再执行又变回0，看起来“没变化”；更隐蔽的是，如果flags是int而FLAG_DEBUG是uint32，编译不过
移位和 &^ 的安全写法：避免算术移位陷阱
左移 和右移 <code>>> 对有符号/无符号数行为不同，&^ 是 Go 特有清零操作，比手写 & (^b) 更清晰。
- 对
int右移（如-8 >> 1）是算术移位，高位补符号位，结果仍是负数；而uint右移是逻辑移位，高位补 0 - 推荐统一使用无符号类型做位操作：
uint8、uint32、uint64；输入来自网络或文件时先清洗：uint8(x) & 0xFF -
a &^ b等价于a & (^b)，但语义明确：把a中所有b为 1 的位清零；比如清除调试位：flags &^ FLAG_DEBUG - 移位右操作数必须是非负整数，且不能超过目标类型的位宽（如
uint8移8位以上结果恒为0）
超长二进制串或大数位运算别硬刚，用 math/big
当二进制长度超过 64 位（比如解析协议头、处理哈希摘要、密钥运算），int64 或 uint64 直接溢出，strconv.ParseInt(s, 2, 64) 会失败。
立即学习“go语言免费学习笔记（深入）”；
- 改用
*big.Int：它支持任意精度，原生提供Or、And、Xor、Lsh、Rsh等方法 - 解析字符串：
a.SetString("1010101010101010", 2)，返回是否成功 - 注意：
big.Int方法都是就地修改（接收指针），需传地址：result.Or(&a, &b) - 不要试图用循环手动逐位操作——性能差、易出错、难以维护
& 是与，而是每次写 flags & FLAG_X 前，确认两边类型一致、FLAG_X 是 2 的幂、且判断条件写了 != 0。 
