参数篡改是缓存穿透的常见入口，需在参数解析后、缓存查询前完成非法值拒绝和布隆过滤器拦截；前端校验不可信，后端必须强转类型并校验；布隆过滤器须在redis查询前调用，key须与缓存一致，且需监控误判率。
参数篡改本身不会直接导致缓存穿透，但它是穿透攻击的常见入口——攻击者靠伪造非法 ID（如负数、超长字符串、UUID）绕过基础校验，再高频刷接口，让布隆过滤器和空值缓存都失效。 真正有效的防御必须在参数解析后、缓存查询前完成两件事：立刻拒绝明显非法的值；对“合法格式但业务不存在”的 key，用布隆过滤器快速拦截。否则，哪怕加了 BF.EXISTS，请求也早已打到 Redis 或 DB。
为什么前端校验不能只靠 JS 或表单限制
前端校验只是体验层优化，完全不可信。攻击者用 curl、Postman 或脚本直接发 GET /user?id=-1 或 GET /product?id=abc123xyz，就能跳过所有前端逻辑。服务端收到的 id 已是原始字符串或数字，必须重新解析并校验。
- 后端必须做类型强转 + 范围检查，比如
Long.parseLong(id)后判断是否 > 0，而不是只检查字符串非空 - 对 UUID 类字段，不能只用正则匹配格式，还要结合业务规则（如是否属于已开通区域）
- 签名验证（如 HMAC-SHA256）必须覆盖所有参与查询的参数，防止篡改后重放
- 网关层做统一参数白名单（如只允许
id、page、size），多出的字段直接 400
布隆过滤器必须在参数校验之后、Redis 查询之前调用
这是最容易错的位置。很多团队把 BF.EXISTS 放在「查 Redis 未命中」之后，等于穿透已经发生。正确顺序只能是：解析参数 → 校验合法性 → 布隆过滤器判断 → （若 false）直接返回 404 → （若 true）查 Redis。
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 布隆过滤器的 key 必须和缓存 key 完全一致，比如缓存用
user:1001，布隆里也要注册user:1001，不能只存1001 - 初始化时要把全量合法 ID（如用户表主键、商品 SKU 列表）一次性
BF.MADD进去，不能靠运行时“查一次 DB 就 add 一次”，否则冷启动期大量穿透 - 布隆过滤器实例必须是进程单例，且容量按真实数据量预估：1 亿用户、误判率要求 ≤ 0.01%，位数组至少需 ≈ 1.2 GB 内存，硬塞进 100MB 是无效的
- 不支持删除，所以软删除的用户（如
status = 'deleted'）仍会通过布隆检查，得靠空值缓存 + 短 TTL 兜底
空值缓存不是补丁，而是布隆过滤器的语义延伸
布隆过滤器回答的是“这个 key 是否可能合法”，空值缓存回答的是“这个合法 key 对应的数据当前是否为空”。两者定位不同，不能互相替代。
- 空值缓存的 key 和 value 必须带明确标记，比如
SET user:9999999999 "@@NULL@@" EX 300，避免和真实数据混淆 - TTL 严格控制在 5–10 分钟，太长会导致新上线用户因历史空缓存被拦截；太短则起不到缓冲作用
- 空值写入必须在 DB 查询确认为空之后，且要捕获异常（如 DB 连接失败），避免把错误状态当空值缓存
- 如果布隆过滤器部署在网关，空值缓存必须由业务服务写入，网关不感知 DB 结果，否则链路断裂
最常被忽略的一点：布隆过滤器的误判率不是理论值，它会随非法 key 的实际分布漂移。线上必须监控 BF.EXISTS 返回 true 但最终 DB 查无结果的比例，一旦超过预设阈值（如 5%），说明容量不足或哈希冲突严重，得触发重建流程——这比加机器更关键。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
