Go roaring 32位位图与64位位图怎样选择

Go roaring 选 32 位还是 64 位，先看集合里的编号是否可能超过无符号 32 位范围，再看数据是否需要和 Java、C++ 或 C 版本交换。编号稳定落在 0 到 4294967295 以内，并且看重标准 Roaring 格式时，优先使用 roaring.Bitmap；业务主键可能超过这个范围，且数据只在 Go 体系内流转时，再考虑 roaring64.Bitmap。

官方文档：https://pkg.go.dev/github.com/RoaringBitmap/roaring

一句话判断：32 位是默认、标准、跨语言边界更清楚的选择；64 位是面向更大整数域的 Go 扩展，不能因为类型更大就默认更合适。

先看编号范围和集合密度

默认导入的 github.com/RoaringBitmap/roaring 处理的是无符号 32 位整数。它适合用户编号、文档编号、分片内对象编号等已经被约束在 32 位范围内的集合。这里的“能不能放下”是第一道边界，和集合里有多少个元素不是一回事：元素很多但编号范围受控，仍然可以用 32 位位图；元素很少但某个编号超过 32 位，就不能靠稀疏性绕过类型范围。

roaring64 位于同一模块的扩展包中，面向 64 位整数。它解决的是编号域变大，不是自动解决稀疏集合、跨语言交换或内存预算。若集合很小、编号又随机分散，直接保存整数数组有时反而更简单；是否使用 Roaring 仍要结合集合密度和交并差操作频率判断。

两个包的调用方式相近，但类型不是一套

两种位图都提供创建、添加、查询和集合运算等相近能力，这很容易让代码看起来可以直接替换。真正需要留意的是导入路径和元素类型：32 位包的数组、方法参数和返回值围绕 uint32，64 位包则围绕 uint64。不要把一个包的位图变量、序列化字节或结果数组当成另一个包的值使用。

package main

import (
    "fmt"

    roaring32 "github.com/RoaringBitmap/roaring"
    "github.com/RoaringBitmap/roaring/roaring64"
)

func main() {
    // 32 位编号适合明确受控的业务集合。
    smallIDs := roaring32.BitmapOf(100, 200, 1

这段代码的重点不是把两个集合做运算，而是把选择固定在导入路径和类型上。若业务层同时支持两种编号，建议在接口命名上直接体现 uint32 或 uint64，不要用一个含义模糊的 []int 在边界处来回转换。特别是从数据库读取有符号整数时，要先确认非负约束和上限，再转换为位图接受的无符号类型。

跨语言交换时，32位格式更稳妥

官方 README 明确说明，32 位 Roaring 格式是 Java、C++、C 和 Go 之间可以互操作的标准格式；64 位版本则没有兼容性保证。也就是说，选 roaring64 不只是把数字从 32 位放大，它还会改变你与其他语言服务、离线工具和历史文件交换的契约。

如果位图要写入对象存储供其他语言读取，或者未来可能被搜索、分析组件消费，优先把 32 位格式当作边界设计，并在业务层把超大编号映射到受控的内部 ID。只有在数据明确只由 Go 侧保存和读取、并且确实需要原始 64 位编号时，才接受 64 位扩展的兼容性范围。

序列化时不要只看方法名相同

两个包都能把位图写入流或从流读取，但“都有 WriteTo 和 ReadFrom”不等于字节格式可以互换。持久化字段应同时记录位图类型、生成方和格式版本；读取时先确认目标是 32 位还是 64 位，再交给对应构造函数。不要先用 32 位对象读取，再把失败归因于文件损坏。

package bitmapstore

import (
    "io"

    roaring32 "github.com/RoaringBitmap/roaring"
    "github.com/RoaringBitmap/roaring/roaring64"
)

func save32(bm *roaring32.Bitmap, w io.Writer) error {
    // 32 位文件必须由 32 位对象写出，格式边界由调用方保存。
    _, err := bm.WriteTo(w)
    return err
}

func load64(r io.Reader) (*roaring64.Bitmap, error) {
    // 读取前已由文件头或元数据确认这是 64 位 Go 扩展格式。
    bm := roaring64.New()
    if _, err := bm.ReadFrom(r); err != nil {
        return nil, err
    }
    return bm, nil
}

示例省略了文件头定义，但生产代码不应省略它。一个简单的头部可以写入逻辑类型、格式版本和业务域，避免以后把 32 位文件交给 64 位读取器。若系统必须与其他语言对接，先把对方支持的格式写进接口契约，再决定 Go 侧的包，而不是反过来。

按场景做最后选择

不要用“64 位更大”作为唯一理由。真正的选择顺序是：先确认编号上限，再确认集合操作和密度，最后确认跨语言与文件格式契约。这样即使将来需要迁移，也能明确是扩大编号域，还是更换交换格式。

32 位位图能不能存放超过 32 位的业务 ID？

不能直接存放。应使用 roaring64，或者在业务层建立稳定的 32 位内部映射；不要先强制转换为 uint32，那会丢失高位信息。

roaring64 能否直接读取 32 位 Roaring 文件？

不能仅凭方法名相同就假设兼容。32 位格式有明确的跨语言标准，64 位版本没有兼容性保证；文件交换必须按双方约定的格式实现。

以上判断依据 Go roaring 官方包文档中的 32 位默认类型、roaring64 扩展说明及格式兼容性说明。示例用于说明接口边界，未把示例输出描述为本机运行结果。