很多后端面试会先让候选人手写 LRU。表面看是算法题，实际上它非常适合继续深挖缓存系统：为什么需要哈希表加双向链表？容量满了淘汰谁？并发访问怎么办？真实业务里是不是所有缓存都适合 LRU？
如果只把 LRU 当成一道固定题，写完 get 和 put 就结束，会错过它背后的工程价值。缓存从来不是“把数据放进内存”这么简单，它同时牵涉速度、容量、命中率、一致性和故障兜底。
代码题先讲清结构选择
标准 LRU 通常用哈希表加双向链表。哈希表负责常数复杂度找节点，双向链表负责常数复杂度移动节点和淘汰尾部节点。get 命中后要把节点移动到头部，表示最近使用；put 更新已有 key 时也要移动；插入新 key 超过容量时，删除尾部最久未使用节点，同时从哈希表里删掉对应 key。
这道题容易错在细节：忘记更新已有 key 的值，删除链表节点时没同步删除 map，容量为 0 或 1 时边界出错，移动头节点时重复操作。面试现场可以边写边说这些边界，面试官会更容易判断你不是机械背代码。
真实缓存不只有 LRU
系统设计里，LRU 只是淘汰策略之一。它假设最近访问过的数据未来还会被访问，这在很多场景成立，但不是所有场景都成立。比如一次性扫描大量冷数据，可能会把真正热点数据挤出去；某些业务更看重过期时间、优先级或成本，而不是最近访问。
用户详情、配置缓存：LRU 是否合适是通常合适，更需要关注的点是命中率、过期时间、容量。大批量离线扫描：LRU 是否合适是可能污染缓存，更需要关注的点是扫描隔离或跳过缓存。
- 强一致业务字段：LRU 是否合适是不能只靠淘汰策略，更需要关注的点是数据源权威和失效顺序。
- 热点榜单：LRU 是否合适是只靠 LRU 不够，更需要关注的点是预热、逻辑过期、热点保护。
并发和一致性会把代码题拉回项目
如果面试官追问“多线程访问这个 LRU 怎么办”，不要只说加锁。先说风险：链表移动和 map 更新必须保持一致，否则结构会坏。可以用一把锁保护整个结构，简单但并发度低；也可以分段或使用成熟缓存库，但复杂度更高。选择取决于缓存访问量、写入频率和一致性要求。
如果再追问数据库更新后缓存怎么办，就进入缓存一致性。常见策略是先更新数据库，再删除缓存；如果删除失败，需要重试或补偿。对读多写少的数据，可以接受短时间不一致；对余额、库存这类字段，不能把本地 LRU 当作权威数据。
这道题的高分表达
可以这样收束：LRU 代码题我会用哈希表和双向链表保证查找、移动、淘汰都是常数复杂度；但真实项目里，我还会看缓存容量、淘汰策略是否适合访问模式、并发访问是否安全、数据库和缓存的一致性如何兜底。这样一来，算法题就自然延伸成了缓存系统设计题。