PHP 中无原生布隆过滤器，需通过 ext-bloom 扩展或 Redis + redisbloom 实现；不可手写，须配合数据库唯一约束兜底，避免误判导致数据不一致。
布隆过滤器在 PHP 中不是原生支持的
PHP 标准库没有内置 BloomFilter 类，直接 new BloomFilter() 会报错 Fatal error: Class 'BloomFilter' not found。想用就得靠扩展或纯 PHP 实现——但后者性能差、易写错，不推荐线上用。
实操建议：
- 优先安装
ext-bloom扩展（C 实现，速度快，内存可控），编译安装或通过pecl install bloom获取 - 若无法装扩展，可用
redis+BF.ADD/BF.EXISTS（需 Redis 4.0+ 及redisbloom模块），比纯 PHP 实现可靠得多 - 别手撸哈希函数组合——误判率算错、位图越界、扩容逻辑漏掉，三天后就出数据一致性问题
用 ext-bloom 判断重复项的最小可行代码
装好扩展后，核心就三步：建过滤器、加元素、查是否存在。注意所有输入必须是字符串，数字得先 (string) 转换，否则行为未定义。
示例：
立即学习“PHP免费学习笔记（深入）”；
$bf = new BloomFilter(10000, 0.01); // 容量1w，期望误判率1%
$bf->add('user_12345');
var_dump($bf->exists('user_12345')); // true
var_dump($bf->exists('user_67890')); // false（大概率）
关键点：
-
10000是预估最大元素数，不是当前数量；设太小会导致误判率飙升，太大浪费内存 -
0.01是目标误判率，实际值受底层哈希轮数影响，ext-bloom默认用 7 个哈希，够用 - 过滤器实例不能跨请求复用（PHP-FPM 每次请求都是新进程），得持久化到 Redis 或文件（用
$bf->serialize()）
Redis + redisbloom 的 fallback 方案
当服务器不允许装 PHP 扩展，但能连 Redis，这是最稳的选择。命令简单，误判率可调，且天然支持分布式。
前提：
- Redis 已加载
redisbloom模块（MODULE LIST查看） - PHP 用
phpredis或predis连接
操作示例（phpredis）：
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$redis->rawCommand('BF.RESERVE', 'users_bf', 0.01, 10000); // 首次建
$redis->rawCommand('BF.ADD', 'users_bf', 'user_12345');
var_dump($redis->rawCommand('BF.EXISTS', 'users_bf', 'user_12345')); // 1
注意：
-
BF.RESERVE必须显式调用，且只在 key 不存在时生效；重复调用会报错ERR cannot create existing key - 误判率参数是浮点字符串，传
'0.01'，不是0.01（某些客户端会转成科学计数法） - 没命中不等于“绝对不存在”，只是“大概率不存在”——业务上得配合 DB 查询兜底
为什么不能只靠布隆过滤器做唯一性校验
布隆过滤器只保证「不存在的一定不存在」，但「存在的是可能存在的」。它天生有误判率，且不支持删除（标准版）。拿它当主校验，会漏掉真实重复数据。
典型翻车场景：
- 注册接口用
BF.EXISTS拒绝邮箱，结果因误判把合法新用户挡在外面 - 用布隆过滤器代替数据库
UNIQUE约束，导致两条相同记录写入 DB - 以为
BF.ADD返回true就代表成功插入，其实它永远返回1（已存在）或0（新增）——这俩都不是“写入成功”的语义
真正该做的：布隆过滤器放前面快速拦截大部分重复请求，后面再走 DB 唯一索引或 INSERT ... ON DUPLICATE KEY UPDATE 做最终裁决。缓存和 DB 之间那层“大概率”判断，别让它越界。
