Next.js + TanStack Query 架构中三种常见的数据请求模式

这三种模式各有优劣，适用于不同的场景。

---

模式一：BFF 代理模式 (Frontend -> Next.js API Route -> Backend)

这种模式的完整流程是：
前端页面组件 -> useXXX (自定义 Hook) -> xxxService -> fetch('/api/backend') -> Next.js API Route -> proxyBackendUtils.request -> 真正的后端服务

这是一个典型的 BFF (Backend for Frontend) 模式。Next.js 的 API Route 充当了前端和后端之间的代理层和适配层。

优点 (Pros):

1. 安全性高: 这是最大的优点。后端的真实地址、API Keys、Secrets、数据库连接字符串等敏感信息永远不会暴露在浏览器端。所有认证和鉴权逻辑都可以在这个安全的服务器环境（Next.js API Route）中处理。
2. 解决CORS问题: 浏览器请求的是同源的 /api/backend，完全没有跨域问题。Next.js 服务器与后端服务之间的通信是服务器到服务器的，不受浏览器同源策略的限制。
3. 数据聚合与裁剪: 可以在 API Route 中调用多个后端服务，将数据聚合成一个前端需要的格式，或者剔除掉前端不需要的敏感字段。这大大简化了前端的逻辑。
4. 协议转换: 如果后端服务使用的是 gRPC、GraphQL 等不同协议，BFF 层可以将其转换为前端易于消费的 RESTful API。

缺点 (Cons):

1. 增加了一次网络跳跃: 请求链路变长了（浏览器 -> Next.js 服务器 -> 后端服务器），理论上会增加一点点延迟。但在内网环境（如 Vercel Serverless Function 与后端服务在同一云服务商的同一区域），这个延迟通常可以忽略不计。
2. 增加了维护成本: 你需要编写和维护这层 API Route 代理逻辑。

适用场景:

这是绝大多数生产级应用推荐的模式，尤其是当需要处理认证、隐藏敏感信息、或者前端需要的数据格式与后端直接提供的不一致时。

---

模式二：前端直连后端模式 (CSR - Client-Side Rendering)

这种模式的完整流程是：
前端页面组件 -> useXXX -> xxxService -> fetch('https://api.my-real-backend.com/data')

这是最经典的客户端渲染（CSR）数据请求方式。

优点 (Pros):

1. 简单直接: 架构最简单，不需要额外的 BFF 层。
2. 延迟较低: 少了一次网络中转，请求直达后端服务。

缺点 (Cons):

1. 安全性差: 后端服务的地址直接暴露在前端代码中。如果需要 API Key，也只能使用那些可以安全暴露在前端的 “Public Key”。
2. CORS 配置复杂: 后端服务必须正确配置 CORS (Cross-Origin Resource Sharing)，允许来自你前端应用的域名请求。
3. <