做这类导航站、聚合站，很多人第一反应都是：“不就是拉个接口，把数据展示出来吗？”我一开始也是这么想的。但真把项目做起来后会发现，页面展示本身反而不是最麻烦的，真正容易踩坑的，往往是这些问题：

• 上游接口不能直接暴露给前端
• 页面不能完全靠客户端渲染
• 数据源偶尔波动，首页不能直接白屏
• 原始指标拿到了，但用户不一定看得懂

最近在看一个 AI API 导航站 CodePK，它本质上就是这类典型项目。业务不算复杂，但前端工程里的几个关键点处理得还比较完整，拿来当成一个 Nuxt 3 小项目案例还挺合适。这篇不讲产品本身，主要聊聊这类站点在实现时，为什么最后往往都会走到“服务端代理 + 缓存兜底 + SSR/SEO”这条路上。

1. 为什么没有直接做成纯静态页面

如果只是做个简单展示页，前端直接请求接口当然也能跑。但只要你的项目有下面两个条件，纯静态方案基本就不太够用了：

• 需要隐藏上游接口地址、Token 或鉴权信息
• 需要一定的 SEO 和首屏可访问能力

因为一旦浏览器直接请求上游接口，就会出现两个问题：

1. 敏感信息没法安全地留在服务端
2. 页面数据完全依赖客户端，首屏和 SEO 都会比较被动

所以这类项目更稳的做法，通常是前端只请求自己站内的 /api，再由 Nuxt 服务端去对接真实数据源。这样做的好处很直接：

• 上游接口不会暴露给浏览器
• SSR 页面更容易保住
• 后面要加缓存、限流、降级也方便

缺点也有，就是部署时不再是纯静态托管思路，而是需要保留服务端能力。不过从长期维护看，这个代价通常是值得的。

2. 请求层一定要尽早收口

很多项目初期为了快，都是页面里直接各调各的接口：

• 列表页自己调
• 详情弹窗自己调
• 筛选条件变化再单独写一套

前面看起来没什么问题，后面接口一改、鉴权一改、错误文案一改，整个前端就会变得很散。这类项目比较合理的做法，是尽早把请求层统一起来，至少把这几件事收掉：

• 请求头和鉴权逻辑
• 返回结构解包
• 异常状态处理
• 通用错误提示

很多人会把这个理解成“架构设计”，其实没那么玄。本质上就是一句话：不要让每个页面都自己和接口细节强绑定。对聚合站、后台页、带筛选的内容页来说，这一步越早做，后面越省事。

3. 信息聚合页最怕的不是慢，是直接空

做列表型页面时，很多人最先盯的是性能。但这类信息聚合站在线上更常见的问题，其实不是“慢 300ms”，而是上游一抖，整个页面直接没内容，这时候体验会非常差。

因为用户来这种站点，很多时候不是立刻下单或提交，而是先看、先比、先筛选。所以它更像“信息浏览型页面”，而不是“强交易页面”。这也意味着它的优先级通常是：先保证能看，再保证尽量新。

因此这类页面建议至少做两层保护：

• 请求切换时，避免旧请求结果覆盖新状态
• 数据异常时，保留兜底内容，别让首页直接空掉

这两个处理平时看不出价值，但只要线上接口抖过一次，就会知道有没有做，差别真的很大。

4. 服务端做代理还不够，最好顺手把缓存做了

如果服务端只是把请求从 A 转发到 B，那它只是“中转站”，价值其实有限。更有意义的做法，是让服务端额外承担两件事：

• 做一层缓存
• 做一层数据整理

为什么这一步重要？因为聚合型页面常见的痛点并不只是“请求成功”，而是“请求不稳定”。加上缓存以后，至少能带来几个好处：

• 降低上游接口压力
• 减少重复请求
• 上游短时波动时，前台页面不至于立刻失稳
• 可以把零散字段整理成前端更好消费的数据结构

很多时候，缓存的意义不是为了极致性能，而是为了可用性。尤其是这种目录站、导航站、聚合页项目，稳定性往往比某一次请求快一点更有价值。

5. 原始指标不要直接丢给用户

像延迟、状态、价格、可用性这类字段，如果只是原样堆到列表页里，从开发角度看确实最省事，但从用户角度看，不一定最容易理解。比较合理的展示方式，一般都是分层：

• 列表页负责快速扫读
• 详情层负责补充判断

比如首页卡片里给一个简洁的状态表达，用户先能快速比较；更细的趋势、波动、历史变化，再放到详情弹窗或二级页面里。这样做的核心不是“图表更炫”，而是信息密度更合理，因为首页最重要的是筛选效率，不是一次性塞满所有细节。

6. SEO 这件事，导航站也别完全忽略

很多人会默认觉得 SEO 只和博客、资讯站有关，其实目录型产品、导航型产品一样有搜索入口，尤其是这些页面：

• 首页
• 帮助页
• 说明页
• 固定专题页

如果这些页面连基础 SEO 都没做，后面很多自然流量入口其实等于白白浪费。至少建议把这些基础项补上：

• title
• meta description
• canonical
• sitemap
• robots
• 社交分享相关元信息

不一定要把它做成重 SEO 项目，但基础设施最好别缺。

7. 这类项目里，真正有价值的是这些工程判断

回头看这类站点，最值得复用的通常不是某个页面样式，也不是某段图表代码，而是下面这些判断：

• 哪些事情必须放服务端做
• 哪些页面要优先保证“异常时还能看”
• 哪些原始指标需要转译后再展示
• 哪些基础 SEO 虽然不显眼，但应该一开始就补

这些点单拆出来都不复杂，但合在一起，基本就决定了这个小站上线后到底稳不稳、能不能持续维护。

8. 适合复用到哪些项目

如果你最近在做下面这些类型的项目，这套思路都可以直接参考：

• AI 工具导航站
• API 目录站
• SaaS 聚合页
• 数据榜单页
• 带筛选和详情展示的信息站

它们虽然业务不同，但底层会反复遇到同一类问题：

• 上游接口怎么藏
• SSR 和 SEO 怎么保
• 数据波动时页面怎么兜
• 指标展示怎么做得更容易看懂

9. 结尾

CodePK 这个案例让我比较有感触的一点是：这类项目真正考验的，不是功能多复杂，而是你有没有提前想到那些“小而关键”的工程问题。

页面展示不难，难的是：

• 前后端边界怎么划
• 接口波动时怎么保可用
• 数据展示怎么做分层
• 小站该有的 SEO 和稳定性能力有没有补齐

如果最近也在做 Nuxt 3 的聚合页、目录站、导航站，这种实现思路基本都绕不开，早点考虑会省掉后面不少返工。

文中案例站点：CodePK
地址：https://codepk.net