为什么单独聊"取文章"这一步
前台和后台之间其实只做一件事：拿数据。听起来简单，但取数据的方式没选好，后面会一直别扭。我把用过的三种写法列出来，说说各自适合什么场景。
写法一：页面构建时一次性拉全量
适合文章总量在几百篇以内、更新频率不高的站。构建的时候调一次接口，把所有文章拉下来，生成静态页。优点是最省事，缺点是文章一多构建就慢，每加一篇都要重新构建一遍。
写法二：按需拉取单篇
适合文章多、但每篇详情可以独立生成的站。构建某篇文章的时候，只按 slug 去接口取这一篇。这样构建单个页面很快，增量更新也友好。
写法三：列表走缓存，详情走实时
适合更新频繁、又不想每次都重建整站的站。分类页和首页的列表数据加上一段时间的缓存，文章详情走接近实时的获取。兼顾了速度和内容的及时可见。
不管用哪种，别忘这三件事
- 接口返回的字段要裁剪，别把正文里用不到的元数据全带回来
- 图片地址、作者、分类这些关联信息，要在取文章的时候一并解决，别留到前台再拼
- 分页要跟着接口的返回走，别自己在前端猜总页数
我最后用的组合
示例站用的是"构建时按需取 + 列表缓存"：文章详情在构建时按 slug 拿，列表数据缓存一小段时间。既保证了打开速度，新文章也不会等太久才出现在列表里。