用途：把数据库读取改为永久缓存优先模式。读取时先查缓存命中即返回，未命中则查库、写入缓存后返回；写入时更新数据库后立即失效或更新对应缓存条目。核心理念是每个数据项在变更前只查一次数据库，不使用 TTL、轮询或后台刷新，缓存始终有效且正确，因为只在源数据变化时精确失效。作者认为 TTL 缓存会用陈旧读取换简单，且每次过期都必然产生一次数据库读取；仅当无法预知数据何时变化（如第三方 API）时才适合用较长 TTL 兜底。
主要能力：先检测项目中的缓存设施（Redis、Memcached、进程内缓存如 lru-cache、node-cache、caffeine、guava 等），报告可用项；若无缓存层则建议默认使用 Redis 并提供接入。随后扫描数据库查询模式，区分高价值缓存候选（用户资料、设置、商品详情、配置表、参考数据、昂贵聚合）与不适合缓存的候选（实时库存、聊天消息、会话数据、每次写入都变化的数据）。为每个候选给出缓存键模式与写入位置。
使用方式：按步骤实施。读取采用缓存优先模式，示例包含 Node.js/TypeScript、Ruby/Rails、Python、Play Framework（Scala）写法；未命中时查库并写缓存且不设过期。写入在数据库成功后立即调用缓存删除或更新，删除操作同样要失效缓存；列表集合中某项变化时需同时失效集合键。缓存键约定如 实体:标识、实体:list:过滤、实体:标识:关系、aggregate:实体:过滤，并在缓存模块顶部注释记录。可选步骤包括应用启动时对关键数据执行缓存预热，最后汇总已缓存的读取、已添加的失效点与数据库负载下降估算。
限制：技能资料未提供安装命令、依赖版本、性能价格等具体信息，相关事实暂未提供。对无法拦截写入的第三方数据源，建议改用较长 TTL（数小时而非分钟）作为兜底，并单独标记以便日后若有失效 webhook 再调整。