bitmap 无法直接做字符串存在性判断，因其依赖整数偏移量映射，易因哈希碰撞导致确定性错误、内存浪费且需业务承担映射逻辑；布隆过滤器则原生支持任意字符串输入，误判率可控、空间可估、无需预热，更适配缓存穿透场景。
Bitmap 无法直接做「字符串存在性判断」
Bitmap 的 SETBIT 和 GETBIT 操作依赖整数偏移量（offset），你得把待查数据（比如商品 ID "item:123456" 或 URL "https://a.com/p/789"）先映射成一个非负整数。但这个映射过程本身就有风险：
- 哈希后取模可能碰撞：多个不同字符串哈希到同一个 offset，导致
GETBIT返回 1，但实际只存过其中一个 —— 这不是误判，是人为引入的确定性错误； - 无法保证全局唯一映射：你没法为所有可能的字符串预分配足够大的 offset 空间，
SETBIT key 9999999999 1会强制 Redis 分配约 1.2GB 内存（按 8bit/byte 算），而布隆过滤器用同样内存能支持上亿元素； - 业务侧必须承担映射逻辑：一旦换哈希函数或扩容策略，历史数据就失效，Bitmap 不提供透明的哈希抽象。
布隆过滤器天然适配「未知字符串输入」场景
缓存穿透的本质是大量随机、不可枚举的非法 key（如恶意构造的 item:id=1234567890）打到后端。布隆过滤器的 BF.ADD / BF.EXISTS 接口直接接受任意字符串，内部自动完成 K 个哈希 + 取模 + 位设置，你不需要知道它用了多少 bit、映射到哪几个位置。
- 误判率可控：默认约 0.81%，可通过初始化时指定
ERROR参数调低（代价是内存略增）； - 空间严格可估：插入 N 个元素、目标误判率 p，所需 bit 数 m ≈ −N·ln(p) / (ln2)²，Redis 模块会按需分配；
- 不依赖业务编号体系：哪怕你的商品 ID 是 UUID 或 base64 编码，也能原样传入，无须提前“编号化”。
空间效率对比不是看“单条数据占几字节”，而是看“支撑相同误判率所需的总内存”
假设你要判断 1 亿个商品 ID 是否合法：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用 Bitmap：必须把每个 ID 映射为整数 offset。若 ID 是 64 位整型，最大 offset 可达 2⁶⁴−1 → 无法分配；若强行哈希取模到 1 亿范围，碰撞概率飙升，
GETBIT返回 1 完全不可信； - 用布隆过滤器：按公式 m ≈ −1e8 × ln(0.0081) / (ln2)² ≈ 9.5×10⁸ bit ≈ 113MB，且这是理论最小值，Redis 实际分配接近该值；
- 反例：有人试过用
SETBIT存 1 亿个随机 int，选 offset 范围为 1.2 亿，结果内存占用 15MB 左右 —— 但此时误判率超 30%，已失去防穿透意义。
真正容易被忽略的点：Bitmap 防穿透必须搭配「白名单预热」，而布隆过滤器可以增量构建
如果你用 Bitmap 做防穿透，必须在服务启动前把所有合法 ID 全部算出 offset 并 SETBIT 一遍，否则漏掉一个，用户就穿透一次。而布隆过滤器允许：
- 上线后边查边建：
BF.EXISTS返回 0 → 查库 → 若存在则BF.ADD； - 冷热分离：高频合法 ID 先进布隆，低频的慢慢补；
- 无需担心“预热不全”问题 —— 它本来就不承诺 100% 准确，只要误判率压在可接受范围即可。
硬用 Bitmap 替代，等于把概率控制问题强行转成工程强一致性问题，反而更难落地。
