先说结论：Redis 本身并不解析 SQL，也不会执行任何查询命令，因此它无法像数据库防火墙那样直接拦截注入攻击。但别急着跳过这一层——你完全可以将它设计成数据库前的第一道过滤网，在恶意输入抵达 SQL 引擎之前就将其拦下。关键不在于让 Redis “防注入”，而在于你的缓存接入逻辑是否足够智能。
缓存 key 必须实施输入白名单校验
一个非常典型的误区是直接将原始 HTTP 参数拼入缓存 key，例如 "user:" + user_id + ":profile"。如果 user_id 传入的是 123' OR '1'='1，key 就变成了 user:123' OR '1'='1:profile。Redis 并不会因为这个 key 执行任何操作，但后续业务代码拿到这个 key 后很可能认为它合法，跳过校验直接拼入 SQL —— 隐患就此埋下。
- 数字型 ID 最简单：使用正则
^[0-9]{1,12}$或直接强转为long/int再构造 key，非数字直接挡在门外。 - 非数字字段（如邮箱、用户名）必须进行格式校验。邮箱至少应匹配
^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$，不允许杂乱字符串进入。 - 包含单引号、分号、注释符（
--、/*）或空格的 key，直接返回 400 或触发限流，根本无需继续处理。
空值缓存不能无差别写入
在缓存穿透场景中，攻击者会使用大量不存在的 user_id 来刷你的接口。如果你对每个不存在的 ID 都执行 SET user:abc:profile "" EX 60，那等于帮助对方将恶意请求固化到缓存中，既浪费内存又加剧了穿透问题。该如何应对？
- 只对“明确合法但暂无数据”的 ID 缓存空值，例如注册流程中查询邮箱是否已使用——这类场景下的 ID 是可控的。
- 对高频出现的异常 key（如连续 5 次
user:-1、user:select）直接拒绝写入缓存，也不查询数据库。 - 空值 TTL 控制在 60–300 秒，避免长期占用位置。同时记录日志，重点监控那些包含
SELECT、UNION、OR等 SQL 关键词的 key 模式——这些几乎就是攻击信号。
避免将原始 SQL 作为缓存 key 存储
如果你在 Redis 中看到大量类似 sql_cache:SELECT%20*%20FROM%20users%20WHERE%20name%3D'admin' 这样的 key，说明业务层正在用用户输入拼接完整 SQL 字符串，再对整个字符串做哈希作为 key。这相当于将 SQL 注入 payload 直接塞入缓存系统，风险极高——一旦缓存被污染，后续所有查询都可能绕过校验。
- 绝对禁止以原始 SQL 或其 URL 编码形式作为 key。key 应该基于结构化参数，比如
user_id=123，而不是查询语句本身。 - 所有数据库查询必须走预处理语句（MyBatis 的
#{}、JDBC 的PreparedStatement等），缓存层不参与任何 SQL 构造。 - 如果非要缓存查询结果，key 应由参数签名生成，例如
user_search:v1:md5("name=xxx&age=25")，并且签名前先校验每个参数的合法性。
归根结底，真正起作用的从来不是 Redis 的某个配置或命令，而是你在调用 get() 或 set() 之前写下的那行校验逻辑。它并不复杂，但在许多项目中偏偏被忽略——而这一忽略，往往就是漏洞的入口。
