logging.level.org.springframework.data.redis.core=debug仅记录spring api调用，不输出实际resp命令；需用redisson trace日志、redis monitor命令或自定义拦截器才能获取真实协议指令。
为什么logging.level.org.springframework.data.redis.core=DEBUG只能看到部分命令
这个日志级别确实能打出RedisTemplate的调用痕迹，比如execute、opsForValue().get()等方法名，但**不包含实际发送到 Redis 服务器的 RESP 命令**（如*2\r\n$3\r\nGET\r\n$5\r\nuser:1\r\n）。它只反映 Spring 层的 API 调用，不是 wire-level 协议日志。如果你需要审计或排查 Redis 命令执行失败、耗时异常等问题，光靠这个远远不够。
用 Redisson 的 TRACE 日志看真实 RESP 命令
Redisson 默认会输出原始 RESP 格式命令，只要把日志级别设对就行：
-
logging.level.org.redisson.client.handler=TRACE（关键） -
logging.level.org.redisson=DEBUG（可选，辅助信息）
启用后你会看到类似这样的日志：
2026-07-13T13:44:22.101 TRACE 12345 --- [ntLoopGroup-2-1] o.r.client.handler.CommandEncoder : channel: [id: 0xabc123, L:/127.0.0.1:56789 - R:localhost/127.0.0.1:6379] message: *3\r\n$3\r\nSET\r\n$4\r\ntest\r\n$1\r\n1\r\n
注意：必须用 Redisson 客户端替换掉默认的 Lettuce 或 Jedis，否则该日志不会出现。Spring Boot 默认用 Lettuce，所以得显式引入 Redisson 并配置为 Redis 客户端。
用 MONITOR 命令临时抓全量命令（慎用于生产）
这是 Redis 自带的调试命令，无需改代码，但有明显副作用：
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 每条命令都会被广播，严重拖慢 Redis 性能，QPS 可能跌 30% 以上
- 只支持单连接监听，不能持久化，断连即丢
- 命令输出不含客户端 IP、耗时、上下文，纯裸命令流
适合开发/测试环境快速验证某次请求是否发出了预期命令，比如：
redis-cli -p 6379 MONITOR | grep "SET"
别在压测或线上流量高峰时开它。
自定义 RedisTemplate 拦截器真正可控但要绕过坑
想在 Spring 原生栈里记录完整命令，得自己包装 RedisConnection。常见写法是继承 DefaultStringRedisConnection 并重写 get、set 等方法，但容易踩两个坑：
-
RedisTemplate内部可能复用连接对象，直接代理会导致线程安全问题 —— 必须用ThreadLocal隔离实例 - 某些操作（如 pipeline、transaction）走的是底层
RedisConnection直接调用，不经过模板方法，得额外拦截executePipelined和execute回调
更稳妥的做法是用 AOP 切 RedisTemplate 的 execute 方法，再结合 RedisCallback 提取实际命令参数，但要注意：Lettuce 的 RedisFuture 是异步的，日志打点必须放在回调里，否则拿到的是空结果。
真正要落地，优先选 Redisson + TRACE；临时诊断用 MONITOR；长期审计需求才值得投入成本做自定义拦截器 —— 后者一旦漏掉 pipeline 或 eval 类命令，日志就残缺。
