math/bits 比手动位运算更快更安全，因其函数被编译器优化为单条硬件指令、只接受 uint 类型杜绝符号陷阱、行为确定且跨平台一致、零分配内联友好。
为什么 math/bits 比手动位运算更快更安全
Go 编译器对 math/bits 中的函数做了特殊优化：很多函数（如 bits.OnesCount64、bits.Len64）在支持 BMI/POPCNT 指令的 CPU 上会直接编译为单条硬件指令，而不是循环或查表。手动写 n & (n-1) 算置位数，不仅慢，还容易漏掉边界情况（比如 n == 0）。
更关键的是，math/bits 所有函数都明确处理了符号位和无符号语义——它只接受 uint 类型，从源头杜绝了负数右移、符号扩展等陷阱。
-
bits.LeadingZeros32(0)返回 32，而32 - bits.Len32(0)也等于 32，行为确定；自己手写 while 循环容易在0上死循环或返回错误值 - 所有函数都内联友好，没有函数调用开销；而自定义工具函数哪怕再短，Go 1.22 前默认不内联带分支的逻辑
- 跨平台一致：ARM64、AMD64、RISC-V 下结果完全相同；自己用
>>和&组合时，若误用int，在 32 位环境可能因截断出错
bits.ReverseBytes16 和字节序转换的常见误用
这个函数只翻转字节顺序，不改变数值解释方式。它不是用来“把小端转大端”的通用方案，而是针对特定场景：比如把一个 uint16 的内存表示（2 字节）按字节倒过来，常用于某些硬件协议或图像像素排列。
常见错误是把它和 binary.BigEndian.PutUint16 混用：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 传入
0x1234→bits.ReverseBytes16(0x1234)返回0x3412（纯字节翻转） - 但如果你本意是“把主机序的
uint16写成网络序”，应该用binary.BigEndian.PutUint16(buf, v)，而不是先ReverseBytes16再写 - 在 ARM64 或现代 x86 上，
ReverseBytes16编译为rev16或bswap指令，极快；但若误用于结构体字段批量翻转（比如想反转整个[]uint32），得自己循环调用，别指望自动向量化
用 bits.OnesCount 替代 fmt.Sprintf("%b", x) 数 1 的个数
有人为了统计 bit 数，先转成二进制字符串再 strings.Count，这在性能敏感路径上是灾难：分配堆内存、触发 GC、字符串解析开销比直接位运算高 100 倍以上。
bits.OnesCount 系列函数（OnesCount8 到 OnesCount64）是零分配、纯计算，且对齐 CPU 最优路径：
- 输入必须是无符号整数；传
int要显式转uint64(x)，否则编译报错——这是保护你免于符号位干扰 -
OnesCount64(0xffffffffffffffff)返回 64，OnesCount64(1)返回 1，行为直观；而strconv.FormatUint(x, 2)后计数，x==0时得到空字符串，容易漏判 - 如果目标是找最低位的 1（LSB），别用
OnesCount+ 循环，直接用bits.TrailingZeros64(x)，它底层就是tzcnt指令，比任何软件实现都快
注意 bits.Len 和 bits.Len64 的 0 值行为
bits.Len64(0) 返回 0，不是 panic，也不是 -1。这点和 C 的 __builtin_clzll(0)（未定义行为）完全不同，是 Go 明确规定的安全语义。
但正因为返回 0，容易在条件判断里埋坑：
- 想判断“是否至少有 8 位有效数据”，写
bits.Len64(x) >= 8是对的；但若写成bits.Len64(x) > 8，x == 256（即1）就会被错误排除 -
bits.Len64返回的是“最高位位置 + 1”，所以bits.Len64(1 恒等于 <code>n+1；别和bits.LeadingZeros64搞混——后者返回高位 0 的个数，LeadingZeros64(1 - 如果需要兼容 32 位系统且变量可能是
int，优先用bits.Len32(uint32(x))而非Len64，避免在 32 位机器上因高位零扩展引入额外开销
真正难的不是记住函数名，而是每次用前下意识确认：我传的是无符号数吗？0 值在这里是否合理？这条路径会被编译成硬件指令，还是退化成软件回退？
