go位运算不能混用int和uint8，因为其无隐式类型提升，&、|、^等运算符要求操作数类型完全一致，如uint8(1) | uint16(2)会直接编译失败；常见错误是将uint8与默认int类型的const标志位进行&运算报错，须显式声明const readperm uint8 = 1，并确保位运算中索引等变量为无符号类型以避免负值问题。
Go位运算为什么不能混用int和uint8
因为Go没有隐式类型提升，&、|、^等运算符要求操作数类型完全一致。写uint8(1) | uint16(2)会编译失败，不是警告而是硬错误。
常见错误现象：从syscall或网络协议读到一个byte（即uint8），直接跟const ReadPerm = 1做&——结果ReadPerm默认是int，类型不匹配报错。
- 定义标志时显式指定类型：
const ReadPerm uint8 = 1 ，而不是<code>const ReadPerm = 1 - 若需64位标志空间，统一用
uint64，避免32位系统上int只有31位有效位 - 从二进制流读取后，先转成目标类型再运算：
b := buf[0]; if uint8(b)&ReadPerm != 0 { ... }
如何安全地用&判断标志位是否启用
必须写成flags & FLAG != 0，不能写flags & FLAG == FLAG或if flags & FLAG { }——前者在多标志组合时失效，后者Go语法根本不允许。
使用场景：权限校验、TCP flag解析、服务控制命令判断（如svc.AcceptStop | svc.AcceptShutdown）。
-
flags & (ReadPerm | WritePerm) == (ReadPerm | WritePerm)用于检查多个标志是否**同时存在** - 掩码别手写十六进制：
1 比<code>0x08更安全，避免位序理解偏差（尤其协议文档按bit 0为LSB时） - TCP flags是大端序，FIN在最高位，取法是
b & 0x01还是b & 0x80取决于文档定义的bit编号方向，不是固定套路
math/bits函数为什么比手写循环快
因为它们被Go编译器特殊处理：在支持POPCNT指令的CPU上，bits.OnesCount64(x)直接编译成单条硬件指令，速度差一个数量级；且只接受uint类型，从源头杜绝负数右移、符号扩展等陷阱。
容易踩的坑：函数名后缀必须匹配输入类型——OnesCount32传uint64会编译失败，不会自动转换。
- 统计置位数：用
bits.OnesCount64(x)，别写for x != 0 { c++; x &= x-1 } - 判断是否为2的幂：
x != 0 && x&(x-1) == 0性能高但可读性差；校验场景用bits.OnesCount64(x) == 1更直白 -
bits.ReverseBytes16只翻转字节顺序，不是“主机序转网络序”的替代品；该转序请用binary.BigEndian.PutUint16
位移运算>>在有符号数上有多危险
对int类型右移是算术移位，负数高位补1；对uint才是逻辑移位，高位补0。Go官方明确建议只对无符号类型做位移，否则行为依赖符号位，跨平台不可靠。
实际影响：比如int(-8) >> 1在不同架构下可能得-4或-5（取决于填充规则），而uint(8) >> 1永远是4。
- 定位bitset中第i位：
i >> 6（等价于i / 64）必须确保i是uint，否则负索引会出问题 - 用
1 定义标志时，<code>i也应是无符号整数，避免左移溢出或符号位干扰 - 协议解析中提取字段，如取byte低4位：
b & 0x0F比b >> 4更安全——后者若b是int且值为负，结果不可控
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
