我的缓存会自己补货：LruLink 与三个并行功能分支
内容提要
作者优化博客缓存与性能：合并四个GraphQL请求，耗时从1100ms降至446ms；发现WPGraphQL默认限制100条数据，改用分页拉取；开发LruLink缓存机制，实现SWR自动补货、分级TTL和用户隔离。最后并行开发三个功能分支，并预告下篇关于MC皮肤吉祥物的故事。
延伸解读
缓存设计的核心：状态机而非 if-else
作者三次推翻缓存方案，最终总结出缓存不是简单的“存起来”，而是需要明确的状态机：数据变动频率、过期策略、写后读一致性、失效方式。LruLink 通过分级 TTL 和 SWR 机制，在缓存过期或半衰时自动后台刷新，实现了“会自己补货”的缓存仓库。这提醒我们，设计缓存时应先定义清晰的状态转换规则，避免临时打补丁。
GraphQL 的默认限制与分页陷阱
WPGraphQL 默认将 first 参数截断为 100，且不报错，导致数据统计不准确。作者改用 offsetPagination 并依据服务器返回的 total 判断终止，而非依赖返回条数不足，避免了总数恰好为 100 的倍数时多请求一次的问题。这提示开发者：使用 GraphQL 时需注意默认限制，并信任服务端提供的 total 字段，而不是自行猜测分页终点。
并行开发分支的实践与教训
作者在完成 LruLink 后并行开发三个功能分支，每个分支先写 ADR 再写代码，最后合并。这种“先备菜谱再下锅”的方式有助于明确需求，但作者也提醒要统一合并节奏，避免分支堆积。对于个人项目，并行分支虽能提高效率，但需注意冲突管理和合并时机，确保代码质量。
Q&A
如何将多个GraphQL请求合并为一个以减少加载时间？
作者将首页的四个独立GraphQL查询（文章、标签、分类、评论）合并成一个megaQuery，通过一次HTTP请求获取所有数据，耗时从1100ms降至446ms。
WPGraphQL默认限制查询多少条数据？如何绕过这个限制？
WPGraphQL的posts连接默认将first参数上限截断为100条，即使传入更大的值也只返回100条且不报错。解决方法是使用offsetPagination分页循环拉取，每次取100条，并根据服务器返回的total值判断是否终止循环。
LruLink缓存机制的核心特点是什么？
LruLink是一个自定义ApolloLink，实现SWR（Stale-While-Revalidate）策略，核心特点包括：分级TTL（不同查询有不同的缓存时间）、自动补货（缓存过半时后台刷新）、用户隔离（缓存key包含用户token哈希）。
LruLink如何处理过期缓存？
对于普通查询，过期时返回旧数据并后台刷新；对于强一致查询（如文章/评论），过期时等待网络获取最新数据。
作者在缓存方案上经历了哪些版本迭代？最终方案是什么？
作者经历了三个版本：v1三层缓存+主动失效（一周后删除）、v2分层缓存+手动Map伪LRU、v3 LruLink（会自己补货的缓存仓库）。最终采用LruLink。
作者并行开发了哪三个功能分支？
作者并行开发了三个功能分支：feature/hover-preview（悬浮预览卡）、feature/stats-dashboard（统计仪表盘）、feature/mc-live2d（MC皮肤看板娘）。
