直接 mock redis-py 的 setex 会漏掉依赖 ttl/expire/get 的复合逻辑分支；应使用 fakeredis 模拟完整 Redis 语义，它支持精确控制过期状态、并发竞态和多 TTL 场景。
为什么直接 mock redis-py 的 setex 会漏掉逻辑分支？
因为实际缓存失效策略往往不只调用一次 setex，还可能混合 expire、ttl、get 和条件判断（比如“若 key 已存在且剩余 TTL 小于阈值，则重设”）。单纯 patch setex 会导致后续的 ttl 返回 -2（key 不存在）或真实值，和你预期的“模拟过期中状态”不符。
更稳妥的做法是使用 pytest-redis 启一个真实 Redis 实例，或用 fakeredis（纯内存、线程安全、支持 ttl/expire 等完整语义）。推荐后者，启动快、无依赖、行为贴近真实。
安装：
pip install fakeredis
在 conftest.py 中配置 fixture：
@pytest.fixture
def redis_client():
import fakeredis
return fakeredis.FakeStrictRedis(version="6.2")
如何用 fakeredis 模拟“缓存刚过期但尚未被清理”的状态？
fakeredis 默认不会自动执行过期逻辑，它把 key 的过期时间记在内部，但只有在显式调用 get、ttl 或其他读操作时才检查是否已过期。这就给了你精确控制时机的能力。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 先用
setex("user:123", 2, "data")设置一个 2 秒过期的 key - 手动推进 fakeredis 内部时钟：
redis_client.time = lambda: (int(time.time()) + 3, 0)（⚠️注意：这是 hack，仅用于测试；更推荐用redis_client._server.time = ...，但需确认 fakeredis 版本支持） - 更稳定的方式：调用
redis_client.set("user:123", "data"); redis_client.expire("user:123", 2)，然后等待 3 秒后调用redis_client.get("user:123")—— 此时返回None，说明已过期 - 若要验证“过期后首次 get 触发刷新”，得确保业务代码里有类似
if not data: data = fetch_and_cache(...)的逻辑，否则测不到失效后的重建行为
测试缓存穿透防护时，setnx 和 setex 的竞态怎么复现？
缓存穿透常见方案是“空值缓存”，即查不到数据时也写入一个短时效的空标记（如 setex("user:999", 60, "NULL")）。但如果多个请求同时发现 key 不存在，又没加锁，就可能重复回源查询。
用 pytest 模拟并发冲突的关键点：
- 不要用
threading.Thread直接跑，fakeredis 默认不是线程安全的（除非传single_connection_client=False） - 改用
asyncio+aioredis+fakeredis.aioredis，或干脆用concurrent.futures.ThreadPoolExecutor配合带锁的 fake client - 更轻量的做法：在测试中手动模拟两次调用，第一次
get返回None，立刻setnx("user:999_lock", "1", ex=10)成功，第二次调用时setnx返回False，走降级逻辑 - 重点断言：回源查询函数（如
db_query_user）是否只被调用 1 次，而不是 N 次
pytest.mark.parametrize 怎么覆盖不同 TTL 配置场景？
缓存失效策略常按业务分级：用户资料 5 分钟、配置项 1 小时、临时令牌 30 秒。硬编码测试容易遗漏边界。
用参数化快速覆盖：
@pytest.mark.parametrize("ttl,expected_behavior", [
(30, "should_renew_on_access"),
(300, "may_stale_but_valid"),
(0, "never_expires"),
])
def test_cache_ttl_effect(redis_client, ttl, expected_behavior):
redis_client.setex("test:key", ttl, "value")
# 后续验证逻辑...
注意：ttl=0 在 redis-py 中表示“永不过期”，但某些封装层（如 django-redis）可能将其转为 expireat 时间戳，行为不一致。测试时务必确认你项目里实际调用的是 setex 还是 set+expire。
真正容易被忽略的是时区与系统时间精度：fakeredis 基于本地时间，如果测试机器时间跳变（如 NTP 同步），ttl 判断可能错乱。CI 环境建议锁定时钟或统一用 UTC 时间做断言。
