最近给一个 Next.js 页面补功能时，发现文章列表接口从原来的几十毫秒涨到了接近一秒。数据量并不大，所以第一反应不是增加缓存，而是先确认时间究竟花在哪里。

先测量，再优化

我把请求过程拆成数据库查询、数据转换和页面渲染三段，结果发现真正的问题是循环里的重复查询。每篇文章都会再次读取分类和标签，数据越多，额外查询就越明显。

调整后的处理方式很简单：

1. 一次读取当前页需要的文章。
2. 批量读取关联分类和标签。
3. 在内存中按文章 ID 进行组合。
4. 只给稳定且重复使用的数据增加缓存。

本地检查命令：

pnpm typecheck
pnpm build

缓存不是第一答案

缓存能隐藏慢查询，却不能消除不合理的数据访问方式。先减少无效工作，再考虑缓存失效策略，通常会得到更稳定的结果。

这次排查提醒我：性能优化最重要的不是某个技巧，而是让每一步耗时都变得可观察。