json存复杂对象不安全，需配置objectmapper的write_nulls和fail_on_unknown_properties；锁粒度应按访问维度生成唯一key并设过期时间；逻辑过期需封装原子写入方法校验expireat；重建耗时长时应异步执行并设超时与重试。
Redis缓存击穿中，JSON字符串存复杂对象是否安全？
直接序列化成String存进Redis是常见做法，但要注意两点：一是JSON本身不带类型信息，反序列化时若字段类型变更（比如int改成Long），可能抛JsonMappingException；二是空值处理不当会导致null字段被忽略，后续读取时字段缺失。建议统一用ObjectMapper配置WRITE_NULLS和FAIL_ON_UNKNOWN_PROPERTIES开关，避免运行时意外失败。
Map或List结构缓存重建时，锁粒度怎么设？
不要对整个业务模块用一个全局锁（如"cache_lock_all"），否则所有key共用一把锁，变成串行瓶颈。应该按实际访问维度生成锁key，例如查询店铺分类列表时，锁key应为"cache_lock_shop_type_list"；查单个店铺用"cache_lock_shop_123"。锁key必须和缓存key有明确映射关系，且带过期时间（如SETNX cache_lock_shop_123 "1" EX 30），防止持有锁的线程崩溃后锁永远不释放。
逻辑过期方案里，如何避免value中expire字段被误删？
把过期时间塞进JSON value里（如{"data":{...},"expireAt":1752429600000}）看似简单，但容易踩坑：
• 业务代码手动拼接JSON字符串时，expireAt字段可能被遗漏或格式错误；
• 使用StringRedisTemplate存原始字符串，如果中间环节调用opsForValue().set()没带EX参数，Redis物理TTL丢失，仅靠逻辑判断会失效；
• 多线程并发写同一个key时，没加锁就覆盖旧值，导致新写入的expireAt被旧逻辑覆盖。
推荐做法：封装统一的setWithLogicExpire()方法，内部用execute(RedisCallback)保证原子写入，且强制校验expireAt字段存在并为long型。
嵌套对象缓存失效后，重建耗时长怎么办？
比如一个商品详情包含SKU列表、规格参数、评论聚合数据，查库+组装要800ms，这时不能让所有请求都卡在锁等待上。关键点是：锁只保护“触发重建”动作，不阻塞返回。
• 互斥锁方案中，拿到锁的线程立即异步提交重建任务（如用CompletableFuture.runAsync()），然后释放锁，不等结果；
• 逻辑过期方案中，主线程判断expireAt已过期后，直接开新线程重建，自己立刻返回旧数据；
• 两者都需配超时机制：异步任务执行超过3s自动中断，避免拖垮线程池；
• 重建失败要记录日志并重试（最多2次），不能静默丢弃。
