Next.js 应用除了部署在函数服务上，还可以选择运行在边缘节点。IGA Pages 是火山引擎的产品，和阿里云 ESA 属于相近的边缘加速类产品：它们都把站点加速能力和一部分边缘运行能力结合起来，让应用有机会在距离用户更近的节点处理请求。
但边缘部署并不是所有 Next.js 应用的最佳选择。真正需要考虑的问题是：服务端到底在做多少计算、需要访问多少次数据库，以及这些数据服务是否靠近边缘节点。
一、IGA Pages 和函数服务有什么区别？
IGA Pages 与阿里云 ESA 可以放在同一类产品中理解，但它们不是同一个产品，运行时支持、部署方式和配置限制也不能直接类比，实际使用时仍然要以各自的官方文档为准。
函数服务通常是在某个中心区域运行应用，再通过 DCDN 把用户请求加速到这个区域。它的特点是应用代码和数据库可以放在相近的区域，服务端访问数据库的路径比较短。
IGA Pages 更接近边缘运行模式：应用代码或服务端逻辑可以部署到边缘节点，用户请求有机会在距离自己更近的节点得到处理。它本身就依托边缘加速产品提供访问加速，不是一个需要再额外挂一层 DCDN 的普通源站。
两种方式的核心区别可以简单概括为：
- 函数服务 + DCDN：应用集中运行，DCDN 负责把用户请求和静态资源加速到应用所在区域。
- IGA Pages：应用的一部分运行能力下沉到边缘节点，用户请求可以在更靠近用户的位置处理。
这里的“更靠近用户”不等于“更靠近数据库”。边缘节点带来的收益，最终要和服务端访问数据的代价一起评估。
二、先区分 SSR 和服务端 API
这两个词经常一起出现，但它们描述的不是同一件事。
**SSR（服务端渲染）**描述的是页面生成方式：用户请求页面时，由服务端生成 HTML，再返回给浏览器。SSR 的过程中可以读取数据库、调用外部服务，也可以完全不访问数据库。
服务端 API描述的是接口形态：浏览器或其他服务请求一个接口，服务端通常返回 JSON 或其他数据。Next.js 中常见的实现是 Route Handler。它主要用于数据读写、鉴权、调用第三方服务等，并不等于页面渲染。
一个 Next.js 应用可以同时拥有 SSR 页面和服务端 API，但两者的请求路径和职责应该分开理解：
- SSR：服务端生成页面 HTML。
- 服务端 API：服务端响应数据或执行操作。
- 服务端组件直接读取数据库：这是服务端数据访问，不自动等于一个对外 API。
因此，不能把所有服务端逻辑都称为 SSR，也不要因为代码运行在 Next.js 服务端，就把它统称为 API。
三、为什么数据库位置很重要？
如果页面是纯静态的，边缘节点离用户越近，通常越有优势。但如果页面使用 SSR，或者服务端 API 需要访问数据库，情况就复杂了：边缘节点处理请求时，仍然要访问数据库和其他后端服务。
假设数据库还在大陆，而某个用户的请求被分配到海外边缘节点，那么一次 SSR 请求可能经过这样的路径：
用户 → 海外边缘节点 → 大陆数据库 → 海外边缘节点 → 用户
这时，代码虽然离用户近了，但服务端访问数据库变远了。每次页面渲染都要跨区域请求，延迟可能抵消边缘部署带来的收益，数据库连接、网络稳定性和跨区域流量成本也需要关注。
不过，不能简单地认为“只要用了数据库，就不适合边缘节点”。关键要看计算和数据访问的比例：
- 计算很密集、数据库查询较少：这类服务端逻辑通常比较适合放到边缘节点。请求可以在靠近用户的地方完成较多计算，只进行少量数据读取或校验。
- 数据库查询非常密集：这类逻辑通常不适合直接放到边缘节点，尤其是查询之间存在串行依赖、读写频繁，或者数据库集中在单一区域时。大量边缘节点到数据库的往返调用，会让网络延迟成为主要瓶颈。
这里要关注的不只是“查询次数”，还包括每次查询是否必须等待上一次结果、数据量大小、读写比例，以及数据库是否在边缘节点附近。边缘节点解决的是用户到计算节点的距离，并不能自动解决计算节点到数据库的距离。
也因此，给数据库服务（例如 Supabase）再套一层加速，通常不是优先方向。数据库请求包含鉴权、读写、连接和一致性等问题，不是把一个静态文件放到 CDN 上那么简单。更值得先问的是：数据库是不是本来就应该部署在海外？国内和海外的应用、服务端以及数据库，是否应该完全拆成两套？
如果用户、计算和数据主要在海外，把数据库直接部署在海外，通常比让国内服务端或边缘节点跨区域访问数据库更合理。对于同时面向国内和海外的应用，也可以评估国内、海外分别部署服务端和数据库，让两边的请求尽量在本地闭环，减少跨境调用和数据流动。这种按地域拆分的架构通常也更容易做数据隔离和合规管理，但具体方案仍然需要结合业务类型、数据分类和适用法规单独评估。
下面用一个相对复杂的典型场景说明这种数据流向。它不是把 Supabase 当成普通源站交给 DCDN 加速，而是先按用户地域拆分接入层、Next.js 服务端和数据库，让 SSR 页面渲染与服务端 API 的数据请求都尽量在同一区域完成。
四、哪些应用适合部署到边缘节点？
纯静态应用
这是最适合的场景。页面构建后就能直接分发，不需要在边缘节点实时访问数据库，用户可以从附近节点获取静态文件。
计算密集、数据访问较少的服务端逻辑
如果请求主要是在做计算，而不是反复查询数据库，例如请求改写、轻量级鉴权、规则计算、内容处理或数据预处理，并且只需要少量数据读取，那么把这类逻辑放到边缘节点通常比较合适。
前后端已经分离的应用
如果前端只是展示页面，服务端 API 集中部署在靠近数据库的区域，那么可以把前端放到边缘节点，把数据请求交给服务端 API 处理。
这种方式需要单独考虑跨域、鉴权、接口延迟和缓存策略，但整体架构边界比较清晰。这里要注意，前端部署在边缘节点，不代表服务端 API 也必须部署在边缘节点。
数据库和边缘运行区域匹配的应用
如果数据库本身有合适的全球化部署方案，或者应用的用户、计算节点和数据都集中在相近区域，边缘 SSR 或边缘服务端 API 才更有机会体现优势。
五、哪些应用不适合直接放到边缘？
如果应用有大量动态页面，SSR 需要频繁访问一个距离边缘节点很远的数据库，或者服务端 API 的一次请求需要多次串行查询数据库，就不建议为了“全球加速”直接迁移到边缘节点。
这类应用更适合先把服务端逻辑部署在靠近数据库的函数服务中，再用 DCDN 加速静态资源和用户访问。这样虽然代码不是全部运行在边缘，但数据访问路径更可控。
尤其需要注意下面这种部署方式：
服务端部署在海外边缘节点，数据库部署在大陆；每个请求又需要多次读写数据库。
这种情况下，边缘节点离用户近，但离数据库远，整体响应速度可能反而更差。对于数据库访问密集的应用，应优先保证服务端和数据库之间的低延迟，再考虑把用户侧的静态内容和可缓存内容交给 DCDN。若业务确实主要在海外，还应该优先评估把数据库直接部署在海外，而不是继续尝试给现有数据库链路叠加加速层。
六、IGA Pages 不能再在前面叠加一层 DCDN
边缘加速产品本身通常就依托 DCDN 提供全球或区域加速能力。IGA Pages 已经属于这一类产品，因此不应该再在它的前面挂另一层 DCDN。
如果把一个边缘加速产品的域名，再配置成另一个 DCDN 的加速对象或源站，两个加速层之间可能形成回环。平台会进行回环检测，发现这种配置后通常会禁止接入或拒绝生效。
所以需要先区分两种架构：
- 函数服务作为源站 + DCDN：这是常见的“中心区域计算、边缘加速访问”架构。
- IGA Pages：它本身已经包含边缘加速能力，不要再在前面叠加 DCDN。
如果需要精细控制 DCDN 的缓存、路由和传输参数，通常应该选择函数服务加独立 DCDN，而不是把 IGA Pages 当作普通源站再接入一层 DCDN。
七、IGA Pages 的配置限制
IGA Pages 的优点是把一部分部署和加速能力整合起来，但代价是可调参数相对少。
例如，HTTP/2、Gzip 等能力不一定能像独立配置 DCDN 那样由用户自由调整，部分配置可能需要通过工单开通。如果你需要精细控制缓存、路由和传输参数，独立使用函数服务加 DCDN 会更灵活。
结论：先看计算和数据路径，再看节点距离
IGA Pages 适合纯静态站点、计算密集且数据库访问较少的服务端逻辑、前后端分离的前端应用，以及计算节点和数据服务能够就近部署的应用。
如果你的 Next.js 应用使用 SSR，或者有服务端 API，并且服务端要频繁访问固定区域的数据库，边缘节点未必更快。此时更应该优先保证服务端和数据库之间的低延迟，再使用 DCDN 加速用户访问。
判断是否使用 IGA Pages，可以先问自己四个问题：
- 这是纯静态内容，还是需要 SSR 或服务端 API？
- 服务端逻辑主要是计算，还是主要在查询数据库？
- 数据库是否靠近应用将要运行的边缘区域？
- 是否已经使用了边缘加速产品，避免再叠加一层 DCDN 形成回环？
如果服务端计算量较大、数据库访问较少，并且没有明显的跨区域数据访问问题，边缘部署值得优先评估。反过来，如果数据库查询密集、调用链很长，或者数据库距离边缘节点很远，就应该谨慎选择边缘部署。