Go bitset NextSet返回的布尔值为何不能忽略

在 Go 中使用 github.com/bits-and-blooms/bitset 枚举置位索引时，NextSet 返回的两个值要一起处理：第一个是找到的索引，第二个是“是否找到”的布尔值。真正决定这次结果能不能使用的是第二个值，而不是第一个值。

因此，空位图、起点超过最高置位索引时，都不能只读取索引变量。下面用一个小场景说明为什么。

官方文档：https://pkg.go.dev/github.com/bits-and-blooms/bitset

NextSet 的两个返回值分别表示什么

NextSet(i) 表示从索引 i 开始查找下一个已置位位置，返回值类型是 (uint, bool)。第一个值是候选索引，第二个值说明这次查找是否命中。命中时，索引可以交给业务逻辑；未命中时，索引只是返回协议的一部分，不能当成有效标记。

这也是下面这种写法容易出错的原因：

index, _ := bits.NextSet(0)
fmt.Println(index) // 中文说明：忽略 found 后，无法区分命中和空集

如果位图没有已置位元素，或者起点已经越过最高置位索引，代码仍然会打印一个整数，但这个整数不代表业务中的有效位置。

正确遍历时要把索引和布尔值一起处理

遍历时可以把 found 放在循环条件中，每次成功拿到一个索引后，再从它的下一个位置继续查找。这样既不会把未命中结果加入输出，也不会反复读取同一个位置。

package main

import (
	"fmt"

	"github.com/bits-and-blooms/bitset"
)

func main() {
	bits := bitset.New(16)
	// 只设置三个离散编号，示范 NextSet 会跳过中间的空位。
	bits.Set(2).Set(7).Set(12)

	// found 决定 index 是否是本轮可用的业务结果。
	for index, found := bits.NextSet(0); found; index, found = bits.NextSet(index + 1) {
		fmt.Println(index)
	}
}

这个循环的关键不是语法简洁，而是两个边界：第一次从 0 开始，意味着索引 0 本身也会被检查；下一轮使用 index + 1，避免再次得到同一个置位索引。示例中的静态结果应理解为 2、7、12 这三个位置，配图用于解释结构关系，不是运行截图。

空集和起点边界不要靠索引猜

空位图调用 NextSet(0) 时，应先看 found：

empty := bitset.New(32)
index, found := empty.NextSet(0)
if !found {
	// 中文说明：未命中时只处理“没有置位”的事实，不使用 index。
	fmt.Println("没有可枚举的索引")
	return
}
fmt.Println("第一个置位索引：", index)

同样地，从已经超过最高置位位置的起点开始查找，也应该由 found 判断是否结束。不要用 index == 0、index >= bits.Len() 之类的猜测代替返回布尔值；返回索引的具体值不是“未命中”的业务信号。

如果业务需要从某个分片起点开始枚举，可以把起点直接传给 NextSet(start)，但仍保持同一个原则：命中就消费索引，未命中就结束或转入空结果分支。

Count 和 Len 解决的是另一类问题

NextSet 负责找位置，Count 和 Len 则用于描述位图状态。Count() 是已置位的数量；Len() 表示逻辑长度，通常是最高已访问或已置位索引之后的位置，因此它不是最后一个有效索引。

例如设置 2、7、12 后，Count() 对应三个置位项，而 Len() 的关注点是逻辑范围到最高索引之后的位置。高编号但很稀疏的位图还可能占用较大的存储空间，不能仅凭 Count 估计内存。

常见追问

为什么不能只用 Count 判断后再读 NextSet？ 因为位图可能在两次调用之间被修改；真正消费某一轮结果时，仍应检查该次 NextSet 返回的 found。

NextSet 的起点会跳过起点本身吗？ 不会把这个假设写进业务逻辑。按“从给定索引开始找”的语义使用，并用返回的 found 与索引推进循环；需要排除当前位置时，调用方明确传入下一个索引。

只需要所有置位索引时还有更短的写法吗？ 如果项目使用 Go 1.23 或更高版本，可以考虑文档提供的 EachSet 迭代方式；但理解 NextSet 的布尔返回值，仍有助于处理起点、空集和旧代码兼容场景。