Go中位运算符&、|、^、>>需严格类型匹配，&提取标志位，|组合标志，^切换标志，>>建议仅用于无符号类型；const iota定义标志时需显式指定类型或用1
Go 里 & | ^ 到底怎么用才不翻车
位运算不是“炫技”，而是处理标志、协议解析、内存优化时绕不开的底层动作。Go 的运算符行为和 C 类似，但没有隐式类型提升，int 和 uint8 混用会直接报错。
-
&（与）常用于提取标志位：比如flags & ReadPerm != 0判断是否含读权限 -
|（或）用于组合多个标志：flags | WritePerm | ExecPerm，注意两边类型必须一致，uint8(1) | uint16(2)编译失败 -
^（异或）是开关利器：flags ^= DebugMode可切换调试位，比条件判断更简洁 - 右移
>>在无符号数上是逻辑移位，有符号数（如int）上是算术移位——但 Go 官方强烈建议只对无符号类型做位移，避免负数行为差异
用 const iota 定义标志位时为什么老出错
很多人照抄示例写 const ( A = 1 ，结果发现 <code>A|B|C 算出来不对，或者传给 syscall 时被截断。根本原因是没控制底层类型和位宽。
- 显式指定类型，比如
const ( Read = 1 ，否则默认是 <code>int，在 32 位系统上可能只有 31 位可用 - 如果要支持 64 位标志，直接用
uint64：const ( FlagA uint64 = 1 - 别依赖
iota自动递增来表示“第几个”，位标志必须是 2 的幂；const ( A; B )这种写法会让B == 1，不是2，极易埋雷
bits.OnesCount64() 这类函数为啥比手写循环快得多
Go 标准库的 math/bits 包里一堆 OnesCount、TrailingZeros 函数，它们不是纯 Go 实现——在支持 POPCNT 指令的 CPU 上，会直接编译成单条硬件指令，速度差一个数量级。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 统计一个
uint64里有几个 1，用bits.OnesCount64(x)，别写for x != 0 { c++; x &= x-1 } - 判断是否为 2 的幂：用
x != 0 && x&(x-1) == 0是经典写法，但可读性差；若只是校验，bits.OnesCount64(x) == 1更直白（性能略低但通常可接受） - 注意函数名后缀必须匹配类型：
OnesCount32输入uint32，传uint64会编译失败，不是自动转换
从网络字节流里解析 bitfield 时容易漏掉的细节
比如解析 TCP flag 字段、自定义二进制协议里的紧凑标志组，常见做法是先读一个 byte，再用位运算拆解。问题往往出在“顺序”和“掩码范围”上。
立即学习“go语言免费学习笔记（深入）”；
- TCP flags 是大端序，bit 0 是最低位（CWR），bit 7 是最高位（FIN）；所以取 FIN 要用
b & 0x01，而不是b & 0x80—— 取决于你按文档定义的 bit 编号方向 - 掩码别手写十六进制：用
1 更安全，比如第 3 位（从 0 开始）就写 <code>1 ，而不是 <code>0x08，减少换算错误 - 读到的原始字节是
uint8，但若后续要做多字节拼接（如 3-bit + 5-bit 字段），记得先转成足够宽的类型再移位，避免截断：uint16(b1)
位运算本身很简单，难的是和协议约定、类型宽度、CPU 架构、编译器优化这些隐性层对齐。少一个类型声明，或错一位掩码，调试时可能花半天才意识到是位序理解反了。
