1. 先分清三兄弟：穿透、击穿、雪崩，很多面试者挂在这一步
先说个我在面试里反复遇到的场面：很多人背了一堆八股文，能很顺溜地说出“缓存雪崩是大量key同时失效”“缓存穿透是查询不存在的数据”“缓存击穿是热点key过期”，但一旦我追问“你现在收到一条告警说QPS掉了一截，DB压力飙升，你怎么判断是哪一种”，立刻就卡壳了。原因很简单：定义背得太溜，分类逻辑没建立起来。
实际上穿透、击穿、雪崩这三种问题的分类标准，不是“现象看起来像什么”，而是“请求到底为什么绕过了缓存，最终打到了DB上”。你可以从两个维度去划分：
- 数据本身是否存在：缓存里查不到，是因为数据本来就不存在，还是因为数据存在但缓存没生效？
- 失效范围是单个还是全局：出问题的是一个热点key，还是一大片key同一时间集体失效？
用这两个维度交叉，三类问题就能分得很干净：
- 缓存穿透：请求查询的数据在DB里根本不存在，缓存和DB都查不到。每次请求都直接穿透缓存打到DB，相当于缓存层完全被架空。
- 缓存击穿：数据在DB里有，但某个热点key在缓存过期的瞬间，大量并发请求同时涌入，全部打到DB。
- 缓存雪崩：数据在DB里有，但一大批key在同一时间集中过期（或者缓存实例直接宕机），导致大量请求同时越过缓存打到DB。
我画了一张诊断顺序图，平时排查问题的时候，我是按这个顺序判断的，比背定义可靠得多：
收到告警：DB压力上升、缓存命中率骤降 第一步：确认缓存服务本身是否存活 ├─ 缓存实例宕机/网络分区 → 雪崩（全局性） └─ 缓存实例正常 → 进入第二步 第二步：确认DB里有没有这批数据 ├─ 数据根本不存在 → 穿透（单次请求绕过缓存） └─ 数据存在 → 进入第三步 第三步：确认失效key的数量 ├─ 大量key同时失效 → 雪崩（局部但量大） └─ 单个热点key失效 → 击穿记住这个判断链，面试官怎么绕你都能回来。
2. 缓存穿透：数据都不存在，缓存自然永远查不到
2.1 穿透为什么比想象中可怕
穿透的本质是：请求查的数据在DB里不存在，因此缓存里永远没有对应数据，每次请求都会老老实实打到DB。单看一次请求，DB扛住完全没问题，但穿透的危险性在于它可以被无限放大。
举个例子：某系统的用户ID是自增长整型，从1开始。攻击者写一个循环，持续请求ID为99999999、99999998这类不存在的用户信息，每次请求DB都得去查一次，查不到就返回空。如果并发拉满，DB的连接池、CPU、磁盘IO会同时被打爆。
更隐蔽的一种穿透场景是内部错误触发：某个上游服务传参有bug，把参数里的某些字段拼错，导致查询了一个不可能存在的维度组合。这类穿透不是恶意攻击，但同样会造成大量无效查询打到DB，而且往往是在业务高峰期才暴露出来。
2.2 空值缓存：最简单的第一道防线
应对穿透的第一反应，也是最容易落地的方案，就是把“查不到”这个结果本身也缓存起来。
public User getUserById(Long id) { // 先从缓存查 String key = "user:info:" + id; String json = redisTemplate.opsForValue().get(key); // 缓存里有明确的值，直接返回（包括空值占位） if (json != null) { return JSON.parseObject(json, User.class); } // 缓存没有，去DB查 User user = userMapper.selectById(id); if (user == null) { // 数据不存在，也写一个短期占位缓存 redisTemplate.opsForValue().set(key, "", 60, TimeUnit.SECONDS); return null; } redisTemplate.opsForValue().set(key, JSON.toJSONString(user), 3600, TimeUnit.SECONDS); return user; }有几个细节要注意：
第一，空值缓存一定要设置短TTL。比如60秒，而不是和正常数据一样一小时。因为如果业务上后来真的写了这条数据，你要让新数据尽快对用户可见，而不是被空占位挡住。
第二，空值缓存的value不能直接用null表示。不同语言的Redis客户端对null的处理不一致，统一用空字符串 "" 或者特殊标记如 "EMPTY" 更稳妥，避免出现“读缓存拿到null，以为没有缓存，又去打DB”的死循环。
第三，占位符的空值校验逻辑要和正常数据区分开。正常用户数据不可能是一个空串，所以读到 "" 时直接返回 null，不要尝试反序列化，这点很容易被遗漏。
2.3 布隆过滤器：大规模场景下的进阶手段
空值缓存的问题是：如果攻击者持续换新ID打过来，比如每次请求的ID都是不存在的，那空值缓存就存不住（因为key一直在变）。这时候就需要布隆过滤器。
布隆过滤器是一个很巧妙的数据结构，本质是一个位数组加多个哈希函数：
- 写入时：把一个数据（如用户ID）经过K个哈希函数得到K个下标，把这些下标对应的位全部置为1。
- 查询时：同样算出K个下标，如果这K个位全部为1，就说“可能存在”；只要任何一个位是0，就确定“一定不存在”。
它最大的优点是节省内存，一个亿的ID，用布隆过滤器也就百MB量级，而且判断“是否存在”是O(1)复杂度。缺点是存在误判率，它只会漏过少数“明明不存在但被判为可能存在”的请求，但绝不会误杀“真实存在的数据”。这个特性对缓存穿透场景来说非常合适——少量误判的请求打到DB，DB完全扛得住；而绝大多次不存在的攻击请求在过滤器这一层就被拦掉了。
实际落地的时候，我建议直接使用Guava的BloomFilter，不要在面试里手写实现，但代码你得能讲清楚：
// 初始化布隆过滤器：预计数据量1000万，误判率0.01 BloomFilter<Long> userIdBloomFilter = BloomFilter.create( Funnels.longFunnel(), 10_000_000, 0.01); // 系统启动时，把已有用户ID全量灌入过滤器 // （也可以定时增量更新） List<Long> allUserIds = userMapper.selectAllIds(); for (Long id : allUserIds) { userIdBloomFilter.put(id); } // 查询前先用布隆过滤器判断 public User getUserByIdWithBloom(Long id) { if (!userIdBloomFilter.mightContain(id)) { // 一定不存在，直接返回null，连Redis都不查 return null; } // 可能存在，走正常的缓存+DB逻辑 return getUserById(id); }误判率参数怎么选？我一般按业务容忍度来定。如果是用户ID这类相对稳定的数据，0.01（1%）够用了；如果数据量特别大，可以调到0.001，内存消耗会增加一些，但误判会显著下降。注意一点：布隆过滤器不支持删除操作，如果业务上有“ID被回收后不可再用”的逻辑，要评估清楚会不会导致过滤器膨胀。选型时优先考虑ID空间是否单调递增、是否会有大量删除，避免过滤器脏数据越积越多。
2.4 穿透场景的参数校验和限流兜底
布隆过滤器和空值缓存是“防穿透”的主力，但还有一层兜底逻辑值得提：参数合法性校验和限流降级。
参数校验很简单：比如ID不能为负数、不能超出合理范围、分页参数不能超过最大值。这层在Web层就能堵掉一批明显非法的请求，成本极低。
限流降级则是针对恶意流量风暴的最后一层保险：就算布隆过滤器有误判，就算存在合法但极高频的查询，一旦某个接口维度的QPS超过预设阈值，直接返回默认数据或友好提示，把DB保护住。很多线上穿透事故最后都是靠限流兜住的，只靠前面几层，总归心里不踏实。
3. 缓存击穿：热点key失效瞬间，并发全来了
3.1 击穿和穿透的本质差异
击穿和穿透最大的区别在于：击穿的数据在DB里是存在的，只是缓存在某一刻过期了。
场景还原一下：某个商品详情页，高峰期每秒几万次请求，商品数据缓存TTL是1小时。某一秒缓存恰好过期，还没来得及重建，下一秒就有5000个并发请求同时发现缓存为空，然后5000个全部打到DB。DB瞬间收到5000个相同的查询请求，压力直接翻倍，严重时会拖垮数据库。
这就引出了击穿问题的核心难点：不是“要不要重建缓存”，而是“同一时刻只允许一个请求去重建缓存，其他人等着用新缓存”。只要保证重建缓存这个过程是串行的、有互斥的，击穿问题就解决了一大半。
3.2 互斥锁重建：先到者重建，后来者等待
互斥锁方案是击穿问题最经典的做法。核心就一句话：缓存失效后，不是每个线程都去DB查询，而是先抢锁，抢到锁的线程去查DB并重建缓存，其他线程等待锁释放后直接读新缓存。
代码实现如下，用Redis的SETNX天然支持原子性：
public User getUserByIdWithMutex(Long id) { String key = "user:info:" + id; String json = redisTemplate.opsForValue().get(key); if (json != null) { return JSON.parseObject(json, User.class); } // 缓存未命中，尝试获取分布式锁 String lockKey = "lock:user:info:" + id; String requestId = UUID.randomUUID().toString(); boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, 10, TimeUnit.SECONDS); if (locked) { try { // 抢到锁，查DB User user = userMapper.selectById(id); if (user == null) { redisTemplate.opsForValue().set(key, "", 60, TimeUnit.SECONDS); return null; } redisTemplate.opsForValue().set(key, JSON.toJSONString(user), 3600, TimeUnit.SECONDS); return user; } finally { // 释放锁：先比较后删除 String lockValue = redisTemplate.opsForValue().get(lockKey); if (requestId.equals(lockValue)) { redisTemplate.delete(lockKey); } } } else { // 没抢到锁，短暂等待后重试 try { Thread.sleep(50); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } json = redisTemplate.opsForValue().get(key); if (json != null) { return JSON.parseObject(json, User.class); } // 递归重试，等待抢到锁的线程重建完 return getUserByIdWithMutex(id); } }这段代码有几个细节要特别强调：
分布式锁为什么要带requestId？因为要防止“锁被别人释放”的问题。假如线程A拿到锁后执行时间很长，锁超时自动过期了；线程B又拿到了同一把锁，然后A执行完去释放锁，如果不比较value，A就把B的锁误删了。带上requestId做比较，能确保只有持有锁的线程自己才能释放自己的锁。
自旋重试的间隔不是越大越好。50到100毫秒是比较常见的值。太短会导致大量无意义的重试请求打到Redis；太长会导致接口响应时间明显变慢，用户体验受损。
万一持锁线程挂掉怎么办？锁过期时间不能设太短。按DB查询耗时来估算，一般设5到10秒足够了。如果业务上查DB偶尔会超过这个时间（比如多表关联很重），要适当调大，否则会出现“锁提前过期，多个线程同时重建”的退化情况。
这种自旋 + 递归的实现方式在面试里很讨喜，因为面试官能看到你已经考虑到了锁超时、锁误删、重试策略这些细节。
3.3 逻辑过期：不给数据设过期时间
互斥锁方案逻辑清晰，但也有一个明显短板：每次缓存失效后，总有一个线程要同步去DB查询一次（即使加了锁，DB还是被打了一次）。如果这个热点key一天失效很多次，DB的负载其实还是不小的。
逻辑过期是另一种思路：压根不给key设置TTL，让它永远在Redis里存着。但在value里塞一个过期时间戳，业务上自己判断逻辑上是否过期。如果逻辑上过期了，就先返回旧数据给调用方，同时只允许一个线程去后台更新缓存。
@Data public class RedisData { private LocalDateTime expireTime; private Object data; } public User queryByIdWithLogicalExpire(Long id) { String key = "user:info:" + id; String json = redisTemplate.opsForValue().get(key); // 缓存不存在，直接查DB重建（核心数据缓存启动预加载，正常不会走到这里） if (json == null) { User user = userMapper.selectById(id); // 写入逻辑过期缓存，永不物理过期，过期时间设为当前时间+30秒 RedisData redisData = new RedisData(); redisData.setData(user); redisData.setExpireTime(LocalDateTime.now().plusSeconds(30)); redisTemplate.opsForValue().set(key, JSON.toJSONString(redisData)); return user; } RedisData redisData = JSON.parseObject(json, RedisData.class); LocalDateTime expireTime = redisData.getExpireTime(); // 未过期，直接返回 if (expireTime.isAfter(LocalDateTime.now())) { return (User) redisData.getData(); } // 逻辑已过期，尝试抢锁异步重建 String lockKey = "lock:user:info:" + id; boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS); if (locked) { try { // 为了防止多个线程同时走到这里，再查一次缓存判断是否已被其他线程重建 json = redisTemplate.opsForValue().get(key); redisData = JSON.parseObject(json, RedisData.class); expireTime = redisData.getExpireTime(); if (expireTime.isAfter(LocalDateTime.now())) { return (User) redisData.getData(); } // 真正去查DB，并更新逻辑过期时间 User user = userMapper.selectById(id); RedisData newRedisData = new RedisData(); newRedisData.setData(user); newRedisData.setExpireTime(LocalDateTime.now().plusSeconds(30)); redisTemplate.opsForValue().set(key, JSON.toJSONString(newRedisData)); } finally { redisTemplate.delete(lockKey); } } // 没抢到锁，直接返回旧数据 return (User) redisData.getData(); }我理解你会问：逻辑过期这么方便，为什么不全都用它？有两个制约因素：
第一，缓存中的数据永远不会被Redis主动清理，会导致内存占用持续增长。对内存容量有限的服务来说是硬伤。通常这套方案只用在高频热点key上，而且要配合定期的清理任务做冷数据淘汰。
第二，返回旧数据存在一个最长“过期期”。如果DB数据更新了，缓存里的旧值最多在30秒内被替换（具体取决于你设置多长的逻辑过期时间）。对强一致性要求高的业务，这种“短暂的不一致”需要评估能不能接受。
3.4 如何识别哪些key值得做击穿保护
击穿方案是有成本的，不可能给每一个key都加互斥锁、都做逻辑过期。实际项目中，我会在系统启动或定时任务里统计缓存访问频率，筛选出QPS排行靠前的热点key，只对这些key套用互斥锁或逻辑过期方案。
另外，有些key天然具备“热点”属性：秒杀商品、首页Banner、热门榜单、明星用户主页。这类key在活动开始前就应该主动预热（缓存提前写入），并且设置比普通key更长的过期时间，比如普通数据TTL 1小时，热点数据直接不设物理过期，用逻辑过期策略兜底。
4. 缓存雪崩：不是某一根稻草，而是一大片key集体失效
4.1 雪崩的两个独立成因
雪崩是这个话题里最危险的一个，因为它的影响面是全局性的。它有两个完全不同的成因，排查思路也完全不同：
- 大量key同时过期：比如上线的代码给一批商品设置了相同的TTL，都是整点过期，一到整点DB就被打爆。
- 缓存实例宕机：Redis进程挂了、内存满了被淘汰、网络分区导致客户端全部连不上，此时所有请求全部越过缓存，DB压力瞬间拉满。
这两种情况都叫雪崩，但处理方式截然不同。前者主要靠“打散过期时间”，后者主要靠“缓存高可用”和“应用本地降级”。
4.2 把过期时间打散：最简单有效的预防手段
针对“大量key同时过期”这个成因，思路很朴素：让它们不要在同一时间过期。
最常见做法是在设置TTL时，加一个随机数，让过期时间在基础值附近波动：
// 基础过期时间1小时，加一个0到60秒的随机偏移 int base = 3600; int randomOffset = ThreadLocalRandom.current().nextInt(0, 60); int ttl = base + randomOffset; redisTemplate.opsForValue().set(key, value, ttl, TimeUnit.SECONDS);这个方案的好处是零成本、侵入性小，几十行代码就能把集中过期的时间摊开。但它不是万无一失：如果业务上有“一批数据必须在同一时刻对用户可见”的约束，加随机数会让部分数据提前/延后过期，所以逻辑上要权衡好。
还有一种做法是从数据上游入手：缓存key不设置统一过期时间，而是采用“每个key独立过期策略”，按数据热度动态计算TTL。比如访问频率越高的key，TTL越长，甚至常驻内存。这需要引入一个简单的热度统计模块，复杂度会高一些，但能有效避免“一刀切”式过期的隐患。
4.3 压垮DB的最后一根稻草：缓存实例宕机
如果Redis本身挂了，以上所有“打散TTL”的手段就全部失效了。这种情况下，防线要从缓存层向应用层迁移。
第一道防线是Redis高可用。主从架构 + 哨兵或集群模式，能在主节点宕机后自动切换到从节点，对应用层几乎无感知。这类基础设施方案属于运维范畴，但作为Java开发者，你至少要能讲清楚主从切换的原理，以及它为什么能降低雪崩概率。
第二道防线是多级缓存。在Redis之外再加一层本地缓存（如Caffeine或Guava Cache）。Redis挂掉时，请求先命中本地缓存，只有本地也没有才打到DB。本地缓存的好处是和应用进程绑在一起，天然不依赖外部服务。要注意的是，本地缓存需要处理“多个应用实例之间的数据一致性”，通常设置为十几秒的短TTL就够了，核心目的是让DB撑过Redis故障期。
实现一个极简的二级缓存结构：
// 本地缓存：5秒有效，避免长时间数据不一致 private final Cache<String, Object> localCache = Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(5, TimeUnit.SECONDS) .build(); public Object queryWithLocalCache(String key) { // 第一层：本地缓存 Object localValue = localCache.getIfPresent(key); if (localValue != null) { return localValue; } // 第二层：Redis缓存 try { Object redisValue = redisTemplate.opsForValue().get(key); if (redisValue != null) { localCache.put(key, redisValue); return redisValue; } } catch (Exception e) { // Redis异常时，不能影响主流程，继续走DB log.warn("Redis异常，降级到DB查询: {}", e.getMessage()); } // 第三层：DB查询 Object dbValue = queryDb(key); localCache.put(key, dbValue); // 异步写Redis asyncSetRedis(key, dbValue); return dbValue; }这段代码里有个重要的设计思想：Redis读取必须做异常兜底。很多时候线上出问题不是Redis真的挂了，而是网络抖动、连接池耗尽导致Redis客户端抛异常。如果你的代码里Redis查询直接抛异常影响主流程，那Redis一抖，接口全挂，雪崩就被放大了。正确姿势是：Redis层包一层try-catch，降级到本地缓存或DB，这比“硬扛高可用”更符合线上实际。
第三道防线才是限流和熔断。当DB压力已经飙升到危险水位时，接口层面直接拒绝部分请求（返回默认值或快速失败），保护DB不被打死。这属于最后的安全阀，代价是牺牲可用性，但总比DB宕机导致全站瘫痪好。
4.4 雪崩的“善后”：缓存重建流程不能乱
雪崩后的恢复阶段，有一个非常关键但容易被忽略的细节：不要在恢复瞬间把所有缓存全部重建，否则会造成“第二次小规模雪崩”。
正确做法是“分批重建”：控制缓存重建的并发度，比如每个类型的数据只允许固定线程数去重建，重建期间其他请求走本地缓存或返回降级数据。很多团队在第一次雪崩后手动把缓存全量写回Redis，结果瞬间DB又被同一批重建请求打挂了，这就是“二次雪崩”。所以，恢复流程必须事先演练，不能等出事再想。
5. 一个热点key终身学习指南：面试官爱问的追问场景
5.1 布隆过滤器误判率是怎么算的
面试官如果听到你说布隆过滤器，大概率会接着问一句：误判率怎么控制？
误判率公式是 (1 - e^(-k*n/m))^k，其中m是位数组长度，n是已插入元素数量，k是哈希函数个数。这个公式不用背，但要理解三个趋势：
- 位数组越大，误判率越小；
- 插入数据越多，误判率越高；
- 哈希函数个数有一个最优值，不是越多越好，太多了反而会让位数组很快被置满。
实际开发中不需要手推公式，Guava的BloomFilter.create传入预计数据量和误判率，它会自动计算最合理的位数组大小和哈希函数数量。能把这个原理讲清楚，比会默写公式加分得多。
5.2 互斥锁为什么不用synchronized，而用Redis分布式锁
这是个高频追问。如果只有一个应用实例，用synchronized就够了。但线上Redis缓存往往被多个应用实例共享，每个实例的JVM锁只对自己进程内的线程有效，没法跨实例互斥。多个客户端同时发现缓存失效，各自实例内都能拿到锁，最终还是会同时打到DB。
Redisson提供了现成的分布式锁实现，内部基于Redis脚本保证加锁和解锁的原子性，还有看门狗机制自动续期，避免线程没执行完锁就过期。如果项目已经引入了Redisson，建议直接用，手写Redis分布式锁更多是为了面试考察原理，生产上还是用成熟库来得稳。
5.3 逻辑过期为什么“最多只能延迟一段时间”
逻辑过期方案返回的旧数据，最坏情况会“旧”多久？答案是：从逻辑过期到异步重建完成之间的时间。在这段时间内，所有读请求都会拿到旧值，因为重建线程还没更新缓存。
如果你把逻辑过期时间设为30秒，理论上最坏有30秒的读旧数据窗口。对秒杀场景的库存显示这类对一致性有极端要求的业务，30秒不可接受；但对商品标题、用户昵称这类低敏感数据，完全没问题。所以，逻辑过期到底适不适用，取决于业务对短暂不一致的容忍度，面试时可以主动提这一点，展示你真的思考过。
5.4 Lua脚本在缓存重建中的价值
不管用Redis分布式锁还是逻辑过期，很多框架内部都会用Lua脚本来保证“判断+更新”的原子性，比如Redisson的加锁逻辑就是一段Lua。Redis是单线程执行命令的，Lua脚本能把多条命令打包成一个原子操作，中间不会被其他客户端的命令打断。
如果手写互斥锁，我推荐把释放锁的比较+删除操作封装成一段Lua：
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end这样就能避免“先get再del”在并发下的竞态问题。面试时能提到用Lua保证原子性，说明你对分布式锁的理解已经不限于API调用层面了。
5.5 三兄弟“同屏出现”怎么处理
现实线上，穿透、击穿、雪崩经常不是孤立出现的。比如Redis节点宕机（雪崩），此时大量请求全部落DB，而DB里恰好有些数据不存在（穿透），又有一些热点key失效（击穿）。三件事同时发生，压力会叠加放大。
这种“组合拳”场景，我的处理优先级是：
- 先保住DB：开启限流，限制数据库的最大并发查询数，DB一挂全盘皆输。
- 再启用本地缓存降级：让一部分请求在本地缓存层被响应，分担Redis不可用期的压力。
- 最后才是精确防护：等Redis恢复后，再针对热点key、不存在的数据做精确的互斥锁/布隆过滤器保护。
预案一定要先在压测环境演练一遍，别等线上出事才临时拼方案。
6. 从“背八股”到“讲方案”：我在面试和实战中的几条体会
最后分享几条我自己的体会，都是踩过坑才换来的经验。
第一，面试时不要只讲方案名称，要讲“判断依据”。很多候选人一上来就说“用布隆过滤器防穿透”，但当我问“你怎么确定这个问题是穿透而不是击穿”，就卡住了。其实判断依据非常简单：先看缓存实例是否存活，再看DB里数据是否存在，最后看key失效数量。把判断链路讲出来，哪怕方案没那么完美，面试官也会觉得你有实战思维。
第二，生产环境千万别裸奔。我在某公司遇到过线上DB被穿透流量打满的情况，当时接口连参数校验都没有，攻击者用一个不存在的ID循环刷，DB连接池耗尽，整个服务挂了半小时。后来加了参数校验 + 空值缓存 + 布隆过滤器三层防护，再也没出现过类似问题。项目里常见的问题是只做了其中一层，却以为“做了缓存穿透防护”，三层一定要一起补。
第三，缓存相关的监控比缓存本身重要。上线缓存方案之前，先把监控指标配齐：缓存命中率、DB查询QPS、Redis内存使用率、接口P99耗时。特别是缓存命中率，它是判断缓存是否健康的第一信号。命中率突然往下掉，不论原因是什么，先查一遍以上三类问题的判断链路，基本都在射程范围内。
第四，把这三类问题和“缓存更新策略”关联起来思考。缓存的过期时间设置、更新时机、失效回调，这些业务决策直接影响雪崩和击穿的概率。比如写入DB后主动删缓存（Cache Aside模式），和定时全量刷新缓存，带来的雪崩风险就完全不同。面试官很喜欢问“为什么用了Cache Aside而不是Refresh Ahead”，本质上就是在考察你能不能把这套知识串联起来。
缓存雪崩、穿透、击穿这三个问题，与其说是“知识点”，不如说是一个“排查工具包”。你要记住的，不是每个方案的代码，而是它们适用的场景、判断的链路、以及失效后的兜底策略。把这些讲透，面试和实战都稳。
