PHP无法直接new BloomFilter()，因该类非内置，需依赖ext-bloom扩展或Redis的BF.*命令；手写实现易出错且性能差；Redis实现需注意BF.RESERVE参数类型、容量预估及字符串输入要求，并须配合DB兜底与降级策略。
PHP 里没法直接 new BloomFilter()，必须靠扩展或 Redis 才能真正用上布隆过滤器做同步去重；手写实现既慢又容易出错，线上千万别试。
为什么 new BloomFilter() 会报错
PHP 标准库不带布隆过滤器类，BloomFilter 不是内置类。你写 new BloomFilter()，PHP 直接抛 Fatal error: Class 'BloomFilter' not found。这不是配置问题，是根本不存在这个类。
- ext-bloom 是 C 实现的独立扩展，需编译安装或
pecl install bloom，装完才有BloomFilter类 - 纯 PHP 手撸（比如用
bitarray模拟）性能差、哈希轮数/位图扩容逻辑极易写错，误判率失控后会导致数据漏判或重复入库 - Composer 包如
phpbloom或redis-bloomfilter本质只是封装了 Redis 的BF.*命令，底层仍依赖 Redis + redisbloom 模块
BF.RESERVE 必须只调一次，且不能传错参数类型
用 Redis 实现时，BF.RESERVE 是建过滤器的唯一入口，但它有强约束：只在 key 不存在时生效，重复执行会报 ERR cannot create existing key。更隐蔽的坑是误判率参数——必须传字符串 '0.01'，不是浮点数 0.01，否则某些 phpredis 版本会转成 1e-2 导致命令失败。
- 建过滤器前先
$redis->exists('my_bf')判断，避免重复BF.RESERVE - 容量参数（如
10000）是预估最大元素数，不是当前数量；设小了误判率飙升，设大了浪费内存 - 所有输入值必须是字符串，
$redis->rawCommand('BF.ADD', 'my_bf', 123)中的123会被当成整型处理，行为未定义，应显式转成(string)123
布隆判断只是“大概率不存在”，业务层必须兜底查 DB
BF.EXISTS 返回 false 表示“绝对不存在”，但返回 true 只代表“可能存在”——这是布隆过滤器的本质限制。如果去重逻辑要求 100% 准确（比如用户注册、订单幂等），仅靠布隆结果就跳过数据库查询，必然导致误判数据被拒绝或重复写入。
立即学习“PHP免费学习笔记（深入）”；
- 典型流程：先
BF.EXISTS→ 若false，直接放行；若true，再查 DB 确认是否真存在 - 不要把布隆当唯一真理，它只是前置快筛；DB 唯一索引仍是最终防线
- Redis 故障时，布隆失效，整个链路会降级为全量 DB 查询，得提前设计 fallback 逻辑（比如加熔断或降级开关）
布隆过滤器真正的复杂点不在怎么调用命令，而在于容量和误判率这两个参数要根据实际数据规模反推——设高了内存爆炸，设低了误判率超标。线上跑之前，务必拿真实数据集压测验证 BF.INFO 返回的 size 和 items 比值是否稳定。
