Go位运算核心是类型安全与位宽控制：标志必须为2的幂且显式指定uint类型（如FlagA uint64 = 1），判断用flags & ReadPerm != 0，组合用|需类型一致，右移务必转uint再操作，bits包函数依赖硬件指令故极快。
Go 里位运算不是炫技手段，而是处理协议解析、权限控制、内存压缩时绕不开的底层动作；用错类型或忽略符号位，编译就报错，运行就翻车。
Go 中 & | ^ 判断/设置/切换标志位的正确写法
最常出错的是把标志位当普通整数比较。比如定义 const ReadPerm = 1，然后写 <code>if flags & ReadPerm == 1 —— 这在 <code>ReadPerm = 4 时直接失效。
- 标志常量必须是 2 的幂：
const ( ReadPerm uint8 = 1 - 判断是否启用：用
flags & ReadPerm != 0，不能省略 <code>!= 0（Go 不允许整数直接进 <code>if） - 组合多个标志：
flags | WritePerm | ExecPerm，但两边类型必须一致，<code>uint8(1) | uint16(2) 编译失败 - 切换某一位（开→关 或 关→开）：
flags ^= DebugMode，比 <code>if/else 更简洁且原子
为什么右移 >> 在 int 上容易出问题
Go 对有符号整数做 >>
- 对
int 类型右移，高位补符号位（算术右移），<code>int8(-1) >> 1 得到 <code>-1，不是预期的 <code>0x7F - 对
uint 类型右移，高位补 0（逻辑右移），行为确定且跨平台一致 - 实际操作中，永远显式转成无符号类型再移位：
uint32(x) >> 3，别依赖 <code>int 的右移语义 - 网络协议解析中常见字节流右移提取字段，若原始数据来自
byte 或 <code>uint8，直接 <code>>>
math/bits 包比手写循环快得多的三个原因
bits.OnesCount64 不是 Go 函数，是编译器内联的硬件指令；自己写 <code>for x != 0 { c++; x &= x-1 } 既慢又易错。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 输入类型强制为
uint64 等无符号类型，从源头杜绝负数补码干扰 - 在支持 POPCNT 指令的 CPU 上，直接编译为单条指令，速度差一个数量级
- 函数名后缀必须匹配参数类型：
OnesCount32 只接受 <code>uint32，传 <code>uint64 会编译失败，不是自动转换 - 统计是否为 2 的幂，
x != 0 && x&(x-1) == 0 是经典写法，但可读性差；若性能不敏感，<code>bits.OnesCount64(x) == 1 更直白
用 const iota 定义标志位时最常踩的坑
很多人写 const ( A; B ) 就以为 <code>B == 2，结果发现 <code>A|B == 1，因为 <code>iota 默认从 0 开始，且没指定位宽。
- 位标志必须是 2 的幂，不能靠
iota 自动递增实现：<code>const ( A = 1 - 默认类型是
int，32 位系统上只有 31 位可用，64 位系统上可能溢出；应显式指定类型：<code>const ( FlagA uint64 = 1 - 掩码推荐用
1 而非 <code>0x08，避免手算错误；第 3 位（从 0 开始）就写 <code>1 - Go 没有原生位域语法，所有“字段”都得靠掩码 + 移位维护，封装成方法才能避免重复出错
真正难的不是写对一行位运算，而是在跨平台、混用 signed/unsigned、对接 C 接口或解析网络字节流时，保持类型干净、掩码精准、移位语义明确——这些细节不会报错，但会在某个凌晨三点的生产环境里突然咬你一口。
