2026 年 Vercel 替代方案：Next.js 与 AI 应用该迁到哪里？

Vercel 替代方案怎么选，取决于应用究竟需要运行什么：静态网站或边缘负载适合 Cloudflare Workers 和 Pages；需要常驻进程的全栈服务可以看 Render 或 Railway；希望保留托管式 Next.js 工作流，则可以看 Netlify。本文比较的 6 家平台还包括便于掌控基础设施的 Fly.io，以及适合已使用 AWS、且应用功能符合其支持范围的 AWS Amplify。如果应用运行正常，问题只是账单太高，迁移前应先检查 Vercel 当前的计费方式和支出控制选项。

本文的价格与文档所列功能已于 2026年11月3日 对照各厂商官网核实。这是一份基于官方文档的选型比较，并非部署性能测试。文中的建议会区分两件事：哪些代码可以直接迁移，哪些托管行为需要重新实现。

Vercel 替代方案速览

需要常驻进程的全栈应用，优先考虑 Render；静态网站及兼容的边缘负载，优先考虑 Cloudflare。 如果保留托管式 Next.js 发布流程比获得一台常规服务器更重要，Netlify 也应进入候选名单。

下表中的起步价对应的资源并不相同。小型虚拟机、积分额度与构建分钟数，不能视为等价的生产环境。所有价格均为美元；用量、额外服务及适用税费都可能增加最终账单。

先确定运行方式，再选托管平台

先弄清托管环境需要完成什么工作，再比较同类平台。 静态网站直接发送已经构建好的文件。服务端渲染（SSR）在请求到达时生成响应。常驻服务持续运行应用代码，后台 worker 则处理不必在访客请求内完成的任务。

对同时经营官网和 AI 产品的创业者而言，这些可能是不同的负载：营销页面可以静态化；聊天接口需要流式返回响应；文档导入可能需要独立的 worker，即使客户关闭浏览器，任务仍能继续。

**决定选型的关键：**如果需要解决文件分发，优先看 Cloudflare；如果希望保留托管式 Next.js 部署，优先看 Netlify；如果要掌控常驻进程和后台任务，优先看 Render 或 Railway。需要控制部署位置与基础设施时，值得考虑 Fly.io；重视 AWS 集成、且应用符合兼容性清单时，才值得考虑 Amplify。

这只是初步筛选，并不意味着边缘平台无法运行后台工作流。对于现有应用，应比较两种方案的改造量：接入平台独立的任务系统，或把现有 worker 作为服务运行。

Cloudflare Workers 和 Pages：静态网站与边缘应用的优先选择

Cloudflare Workers 可以在 Cloudflare 网络中运行处理请求的代码。对于依赖项兼容其运行环境的轻量应用，它是很值得优先考虑的方案，尤其适合主要负责分发资源、验证身份和调用外部 API 的应用。但迁移现有 Next.js 应用时，必须先选好兼容方案，不能只把部署目标换掉。

Cloudflare 目前推荐 vinext：它基于 JavaScript 构建工具 Vite 实现 Next.js API，目前处于 beta 阶段。其支持清单包括 App Router、Server Actions、流式 SSR，以及增量静态再生（ISR）。ISR 可以刷新缓存页面，而不必重新构建整个网站。部分导入方式和图像处理行为仍需核查兼容性。即使功能清单看起来齐全，迁移生产环境时也必须把 beta 状态纳入决策。参见 Cloudflare Next.js 指南。

另一条相关路径是 OpenNext，它通过适配器调整 Next.js 构建产物，使其能够运行在其他平台上。Cloudflare 为现有 OpenNext 应用提供了文档；该方案支持流式响应与 ISR，但兼容性矩阵仍不支持 Node.js 中间件。中间件是在请求到达页面之前执行的代码。如果应用的中间件依赖 Node.js 运行时，应先解决不兼容问题，再动 DNS。参见 Cloudflare OpenNext 支持说明。

Cloudflare Pages 适合更简单的情况：Next.js 应用能够导出为静态文件。文档中的预设会把文件构建到 out 目录，并支持通过 Git 触发重新构建和预览。静态导出无法保留请求时执行的 Server Actions 或 ISR；需要动态运行的后端必须另行托管。参见 Pages 静态 Next.js 部署指南、Next.js 静态导出限制。

**如何计费：**Workers 按请求和 CPU 使用量计费，接入的其他服务另行计量。等待网络响应不会消耗 Worker CPU 时间。对于等待模型返回结果的 AI 接口，这个区别可能很重要，但不意味着模型调用或其余技术栈免费。直接分发静态资源，与流量经过 Worker 或 Workers Caching，计费方式也不同。参见 Workers 定价、运行限制。

**适合谁：**静态网站、轻量 API 前置服务，以及兼容边缘运行环境的 Next.js 应用。
**突出特点：**静态资源分发与服务端代码可以放在同一平台生态中。
**价格：**Workers Free 为 $0；Workers Paid 从 $5/月起，超出套餐额度的用量另计。参见官方定价。
**免费试用：**提供长期 Free 套餐，而非只有临时试用。

选型结论：确认兼容，而且负载确实能受益于 Cloudflare 的分发模式时，再选择它。 不要只为醒目的入门价，就接受一次框架迁移。

1. 1

   检查生产分支的兼容性

   在迁移分支中，按照 Cloudflare 文档运行 npx vinext check，逐项查看检查结果。用实际的中间件、图像处理方式和服务端依赖，核对所选方案的支持范围。

2. 2

   验证支撑业务的关键功能

   部署预览环境，检查登录、需要身份验证的页面、Server Action、AI 流式响应和内容重新验证。构建成功只是验收的起点。

3. 3

   选择改动更少的迁移方案

   真正能够静态导出的应用用 Pages；需要在请求时执行代码的应用，选兼容的 Workers 方案。如果适配器带来的改动超过收益，切换生产流量前，应比较常规 Node 部署方案。

Render：适合常驻应用和后台 worker

Render 是托管 Web 服务、worker 和数据库的平台。当 AI 应用需要常规服务器时，它是我通常最先考虑的方案。例如，文档分析产品可以把 Next.js Web 服务与处理上传文件的 worker 分开运行。这样，请求只需确认任务已接收，访客不必一直等到任务全部完成。

**能保留哪些 Next.js 能力：**按照 Render 的文档，可以把完整的 Next.js 应用作为 Node.js Web 服务运行，也可以把静态导出作为静态网站部署。选择 Node 方案就能保留框架的服务端代码，但运行时缓存、部署行为和额外进程如何协同，需要自行安排。参见 Render Next.js 部署指南。

扩容时，这个区别就会变得明显。ISR 让页面可以刷新并复用，但多个独立服务器实例不会自动共享刷新后的结果。部署多个副本时，需要制定缓存策略并协调缓存失效，也就是通知每个实例：已存储的内容过期了。Next.js 自托管文档明确说明了这些责任。参见 Next.js 自托管指南。

**如何计费：**工作区套餐与各服务的计算资源分别收费。Web 服务器、worker 和数据库是独立资源；带宽和构建用量也有各自额度，超出后可能另计。付费 Web 服务的起步价，并不包含 Web 应用、worker 和生产数据库的总费用。参见 Render 定价。

免费服务适合搭建迁移预览，但连续 15 分钟没有入站流量后就会休眠。面向客户的 AI 应用，不应因为一段时间无人访问，就让下一位客户意外等候服务唤醒。如果需要随时就绪，应为付费计算资源留出预算。参见 Render Free 限制。

构建环节还有一个实际问题：Render 不会自动持久保存 Next.js 的 .next/cache 目录。其指南说明了如何通过 Render 的持久化构建缓存位置复用缓存。构建缓存与为页面提供服务的运行时缓存是两回事，配好其中一个，并不会顺带解决另一个。

**适合谁：**需要常驻服务、后台任务或独立部署后端的 Next.js 应用。
**突出特点：**Web 服务与后台 worker 是明确区分的部署类型。
**价格：**提供免费计算资源；付费 Web 计算资源从 $7/月起，内存为 512 MB，另计适用的工作区及其他资源费用。参见官方定价。
**免费试用：**Free 套餐中的 Web 服务会休眠，不能等同于随时就绪的生产环境。

选型结论：如果离开 Vercel 是为了获得常驻后端，可以选择 Render。 第一次迁移应控制范围：先把现有应用部署为 Web 服务，验证通过，再单独迁移任务进程。同时重写应用和更换数据库，会让故障更难定位。

Railway：适合快速组合小型全栈应用

Railway 把服务及其连接关系组织在项目中，适合需要搭建应用、数据库和 worker 的小团队。如果开发者希望直观看到各部分如何连接，并一起迭代，Railway 尤其方便。主要取舍在于资源用量会变化，因此快速部署之后，还要认真检查持续运行产生的账单。

**能保留哪些 Next.js 能力：**Railway 的指南支持从 GitHub、CLI 或 Dockerfile 部署。其 Next.js 流程介绍了 standalone 输出，也就是包含服务器运行所需文件的构建产物，并演示了如何通过引用 DATABASE_URL 连接 PostgreSQL。它还支持在部署前执行数据库迁移命令。参见 Railway Next.js 指南。

对于开发 AI 调研应用的创业者，这种分工很实用：Web 服务处理界面和请求，另一个服务负责导入，PostgreSQL 持久保存应用数据。服务引用可以帮助连接这些组件，但导入重试或部署改变数据库结构时如何处理，仍需自行设计。

**如何计费：**订阅金额是最低消费，包含等额资源用量，并非在每一笔计算资源费用之外再收一份订阅费。超出所含额度后，账单取决于资源消耗。内存、CPU、存储卷和服务出站流量分别计量。参见 Railway 计费说明、资源定价页面。

关键在于：应用闲置时，资源也可能仍在运行。占用内存的 Web 进程、数据库和 worker，其资源消耗并不直接等于访客数量。不能因为页面访问量低，就认为整个项目一定便宜。应核算所有计划持续运行的服务，包括预览环境。

**与 Vercel 相比有哪些变化：**这里采用 Node 或容器部署，而不再依赖 Vercel 封装框架的各项行为。增加副本时，要规划 Next.js 缓存协调；通过公网接口验证流式响应；确定上传文件如何在部署后保留。框架可以迁走，但生产环境原有的运行假设需要重新检查。

**适合谁：**需要共同搭建应用、数据库和后台服务的小团队。
**突出特点：**在项目内连接各项服务，并提供有文档说明的数据库迁移流程。
**价格：**Hobby 从 $5/月起，包含 $5 的资源用量，额外用量另计。参见官方定价。
**免费试用：**提供 $5 试用额度，30 天后到期。参见定价页面中的试用条款。

选型结论：希望快速搭建和调整小型全栈项目，可以选择 Railway。 如果最后只剩这两家偏向容器部署的平台，Railway 与 Render 对比会进一步展开这道选择题。

Netlify：保留熟悉的 Next.js 托管工作流

Netlify 是托管式 Web 部署平台。在本文的平台中，它最适合希望保留预览环境和托管式 Next.js 发布流程的团队。选择它的充分理由，是运营内容丰富、带登录后页面的 SaaS 网站，而不是想运行任意类型的常驻 worker。它对 Next.js 的支持很广，但共享计费额度和实际执行位置需要仔细核查。

**能保留哪些 Next.js 能力：**Netlify 的 OpenNext 适配器支持 App Router、SSR、ISR、React Server Components、Server Actions、流式响应、图像优化和 Cache Components。这些能力有实际意义：迁移并不意味着必须放弃服务端渲染，或无法流式输出 AI 回答。参见 Netlify Next.js 支持说明。

**哪些行为会改变：**配置为边缘运行时的 Next.js SSR 页面，实际会在 Netlify 的函数区域使用 Node.js 运行。不能认为保留了 edge 配置，执行位置就不会变。Netlify 文档还列出了中间件执行顺序上的差异，其 Node.js 中间件不支持文件系统访问和 C++ 扩展。如果身份验证或请求路由依赖这些行为，就更需要注意。

如果发布新版本时仍有客户在使用应用，可以考虑版本偏差保护（skew protection）：让浏览器会话继续匹配它启动时所用的服务端部署版本。Netlify 提供此功能，但需要主动启用。文档也说明，普通客户端 fetch 调用不会自动携带部署标识，因此自定义 API 调用需要额外检查。这个功能有帮助，但不能替代对自身请求路径的验证。参见兼容性与版本偏差保护说明。

**如何计费：**生产部署、计算、带宽和请求都会消耗积分，其他平台服务也可能使用同一额度。频繁部署、分发大文件的内容网站，与访问量不大但需要服务端计算的应用，消耗额度的方式不同。因此，选择 Netlify 需要按负载测算，并不意味着自动降本。参见 Netlify 定价。

Netlify 免费托管：积分上限也关系到服务能否持续运行

免费套餐最需要弄清的边界，是积分耗尽后会发生什么。Netlify 定价页的常见问题说明，项目会暂停，而且某个项目超出限额，可能导致账户内所有项目暂停。付费套餐可以自动充值，但默认关闭。需要明确选择：优先避免额外支出，还是确保流量突增时服务不中断。

对创业者而言，这个问题很具体：如果官网一次发布意外引来大量流量，是否可以接受同一账户下的应用也因此中断？整合负载之前，先检查账户组织方式和积分策略。

**适合谁：**希望保留托管式 Next.js 部署与审核流程的团队。
**突出特点：**通过 OpenNext 适配器提供广泛的框架支持，并配有部署预览。
**价格：**Free 套餐为 $0/月，含 300 积分；付费套餐及额外用量按当前积分规则计费。参见官方定价。
**免费试用：**长期提供 Free 套餐，每月有固定额度。

选型结论：如果最想保留的是部署工作流，可以把 Netlify 列入候选。 最终二选一时可参考 Vercel 和 Netlify 对比，估算能省多少钱之前，先确认账户当前使用的套餐。

Fly.io：适合需要控制部署区域的容器应用

Fly.io 在名为 Machines 的虚拟机中运行应用，适合希望自行控制容器应用运行位置的开发者。相比于尽量少参与运维，它更适合有明确部署位置要求的应用。关键还在于：应用数据能否配合相同的区域部署策略。

**能保留哪些 Next.js 能力：**Fly.io 的 Next.js 部署文档使用 fly launch、自动生成的 Dockerfile 和 fly.toml 配置，并建议采用 standalone 输出打包运行所需内容。这是一种常规服务器部署方式，也让开发者更直接地控制运行环境。参见 Fly.io Next.js 指南。

使用常规运行环境，并不代表迁移细节都已解决。Next.js 的公开环境变量在构建时就已固定，因此更改生产配置可能需要重新构建。多台 Machines 也需要保持框架缓存和部署状态一致。这些工程问题可以处理，但都应计入迁移成本。

假设客户离数据库很远。即使把 Web 进程移到客户附近，每个页面仍可能需要等待远端数据库查询。选择区域时应考虑完整的请求路径。部署地图上的应用位置更多，本身并不能证明客户访问会更快。

**如何计费：**Machine 的计算资源在运行期间计费，费率受规格和区域影响。存储卷、网络出站流量及其他资源另计。官网所列最小规格的月费估算，只是小型计算资源的价格下限，并不代表该内存规格适合你的 Next.js 应用。进程停止后，保留的存储资源仍可能继续产生费用。参见 Fly.io 定价。

有状态应用最需要注意的是：存储卷不会自动复制。存储卷是挂载到某台 Machine 的本地存储，并非全球同步的数据库。使用本地状态时，必须在应用或数据库设计中处理复制与恢复。参见 Fly.io 存储卷文档。

**适合谁：**需要掌控部署区域与容器的开发者。
**突出特点：**提供有文档说明的 Next.js 容器部署方案，基础设施配置清晰可见。
**价格：**官网所列最小的 256 MB Machine 折合 $2.19/月起；区域费率、更大规格、存储和流量都会影响总费用。参见官方定价。
**免费试用：**虚拟机累计运行达到 2 小时或试用满 7 天即结束，以先到者为准。参见 Fly.io 试用说明。

选型结论：需要它提供的控制能力，才选择 Fly.io。 如果希望少操心基础设施，这些控制能力也意味着工作量，交给其他平台可能更合适。

AWS Amplify：适合已使用 AWS、且功能兼容的应用

AWS Amplify 是 Amazon Web Services 提供的应用托管与开发服务，适合已经使用 AWS、且 Next.js 功能需求处于其支持范围内的企业。如果身份验证、数据和存储已在这套技术栈中，选择它在组织协作上可能更顺畅。但对于需要流式响应的 AI 应用，必须先确认兼容性，再考虑生态整合的便利。

**能保留哪些 Next.js 能力：**Amplify Hosting 当前文档列出的计算型托管支持范围是 Next.js 12 至 15 版本，功能包括 SSR、静态页面、API 路由、ISR 和图像优化。应把它理解为文档明确列出的范围，不能据此认定应用当前所用的任意版本都受支持。参见 Amplify Next.js 支持说明。

**哪些能力无法保留：**同一份文档将 Next.js 流式响应、按需 ISR 和 Edge API 路由列为不支持。按需 ISR 指的是响应某个事件，让缓存内容失效，例如发布修改后的商品描述。支持定时或常规 ISR，不代表这种事件驱动的行为也能工作。

对聊天产品而言，流式响应让文字逐步出现，而不是等生成完成后一次性展示。如果现有 Next.js 路由依赖这种行为，Amplify Hosting 就不是可以等价替换的目标。另行托管流式后端是一种架构方案，但改动显然比导入前端仓库更大。

**如何计费：**Amplify 分别计量构建分钟数、托管存储、数据传输、SSR 请求及 SSR 执行时长。后端 AWS 服务是额外资源，有各自的账单。定价页列出了用于身份验证的 Amazon Cognito、用于文件存储的 Amazon S3 等集成。复用这些服务可能合理，但不会因此把它们的费用合并进一份托管订阅。参见 Amplify 定价。

对于团队已经在运维 AWS 的创业者，熟悉的访问控制、账单归属和后端服务，可能比账单分散更重要。对于只想降低 Vercel 支出的独立开发者，这种组织层面的优势未必存在。应比较实际需要的架构，而不是 AWS 产品目录有多丰富。

**适合谁：**以 AWS 为核心、且 Next.js 应用兼容的企业。
**突出特点：**应用托管可以融入现有 AWS 后端和账户体系。
**价格：**标准构建从 $0.01/分钟起，托管、SSR 和后端资源分别计量。参见官方定价。
**免费试用：**AWS Free Tier 的资格和额度取决于账户及注册条件。

选型结论：只有兼容性清单满足应用需求，才选择 Amplify。 已经在 AWS 上花钱，是评估它的理由，不是忽略生产所需功能缺失的理由。

什么情况下，继续用 Vercel 更合适？

如果应用运行良好，问题只是没看懂账单或没控制好用量，那么正在考虑离开的 Vercel 仍可能是更好的选择。更换平台会带来工程投入、功能回归风险和新的运维责任。这些成本应当换来明确的改善。

先查清 Vercel 账单，再决定是否迁移

查看实际账单和当前的 Vercel 定价详解。Vercel 现行定价已在 Pro 套餐中提供 Flat Rate CDN 选项，所以只按每 GB 分发费用计算的旧对比，可能已不适用于你的账单。比较替代平台前，先确定高额费用来自资源分发、计算、构建、席位，还是独立服务。参见 Vercel 当前定价。

Spend Management 支持通知、Webhook，并可选择暂停团队内所有生产部署。仅设置告警，不会阻止继续产生用量。 暂停部署也会让客户无法访问这些应用，而且支出检查可能在超过阈值数分钟后才生效。这是一种需要权衡可用性的成本控制机制，并非精确、即时的费用硬上限。参见 Vercel Spend Management。

如果不迁移前端，也能删除高成本任务、增加缓存或将其移到独立服务，就可以留下。只有常驻进程需求、运行时限制，或明确的可迁移性要求，足以抵偿迁移工作时，才值得离开。

Vercel 免费替代方案：免费额度究竟能做什么？

免费额度适合验证方案，却不能当作生产架构。 Netlify 积分耗尽会导致项目暂停；Render 的 Free Web 服务会休眠；Railway 和 Fly.io 的试用有时长或额度边界；AWS 资格取决于账户条件；Cloudflare 即使静态分发额度宽裕，免费运行时仍有执行限制。

用免费方案确认应用是否能正确构建、完成身份验证、输出流式响应并从故障中恢复。随后，按生产环境真正需要的资源，估算持续运行的负载成本。

Vercel 免费套餐与免费试用，用途并不相同

Vercel 的 Hobby 套餐面向个人非商业用途。Pro 试用用于评估符合试用条件的付费套餐功能，并不赋予长期生产使用资格。创业者不能拿商业部署，去对比一个不允许该用途的免费套餐。参见 Vercel 套餐说明。

从 Vercel 迁移，怎样避免影响现有应用？

先迁移成本高或不兼容的负载；只有能解决更大的问题，才迁移整个应用。 AI 应用可以保留现有前端，由独立 API 接收任务、队列保存待处理任务，再交给 worker 执行。需要持久保存的数据，不应放在随时可能被替换的应用部署中。

队列相当于一份等待处理的任务列表，worker 可以独立于浏览器请求消费它。例如，上传完成后先返回任务标识；worker 提取文本并存储结果；应用随后查询处理状态。这不要求同时迁移所有营销页面或登录界面。

代码仓库能迁移，只代表系统的一部分具备可迁移性。应盘点平台专属的存储调用、环境变量、定时任务、身份验证回调和部署 URL，确定哪些服务保留、哪些替换、哪些需要导出数据。更换前端托管平台，不会自动迁走这些部分。

1. 1

   选一条有代表性的业务流程

   选择真正影响业务的路径：登录、上传文档、开始处理、接收流式回答，再次打开已保存的结果。更换托管环境前，先写清每一步的预期行为。

2. 2

   区分构建时配置与运行时密钥

   在目标环境重新配置服务端密钥，核对哪些公开配置会在构建时写入产物。除非已明确授权预览环境使用生产凭据，否则不要把它们带入迁移预览。

3. 3

   测试流式响应与缓存失效

   通过公网 URL 检查响应片段是否逐步到达。修改内容后，验证预期页面是否刷新。如果增加了副本，要确认每个实例都能看到更新后的状态。Next.js 文档将代理缓冲和缓存协调列为自托管时需要处理的问题。

4. 4

   切换流量前，测试故障与回滚

   在任务执行中重启 worker，重试请求，并在浏览器会话保持打开时部署。确认重试不会让客户可见的工作重复执行。还要确定如何回滚应用，避免以不安全的方式撤销数据库迁移。

5. 5

   按同一负载比较成本，逐步切换

   每份估算都应包含应用、worker、数据库、文件存储、流量、构建和监控。验收通过后再调整流量，保留回滚路径；新环境稳定后，清理不再使用的资源。

这些检查涉及的框架细节，可见 Next.js 自托管指南。这份清单是一套验收计划，并不表示本文比较期间实际部署测试了这些应用。

这些平台是如何选出来的？

筛选重点，是能否为生产中的 Next.js 或 AI 应用提供可信的迁移路径。 评估标准包括运行方式是否匹配、文档明确的框架兼容性、计费单位、部署工作流，以及迁移后需要自行承担的运维工作。

本文于 2026年11月3日依据这六家平台各自的定价与技术页面进行评估，再把这些事实对应到具体负载：静态分发、托管式请求处理、常驻服务，或继续使用原平台。没有经过实际负载测量，就不编造性能评分，也不声称能节省多少费用。

自主管理的虚拟服务器不在此次候选名单中，因为它采用的是另一种运维模式。有能力的开发者可以选择这条路，但更新、备份、恢复及服务器对公网开放的管理，都必须有人负责。名单再加几个名字，也不会消除这些责任。

哪些选法应该避开？

应该避开的是平台与负载不匹配，而不是一概排斥某个品牌。

• 把不做改动的流式 Next.js AI 应用迁到 AWS Amplify Hosting。 文档明确不支持流式响应，这是实质性的阻碍。
• 应用需要请求时执行的 Server Actions 或 ISR，却选择 Cloudflare Pages 静态导出。 应选择兼容的服务端运行环境，或把后端拆出去。
• 应用必须随时立即响应，却使用 Render Free。 其休眠机制与这一要求冲突。
• 把 Netlify 当作高负载应用的固定总价替代方案。 应先测算共享积分消耗，以及额度耗尽后的影响。
• 为了避开基础设施决策而选择 Fly.io。 数据部署区域、存储卷和恢复，都需要明确设计并落实责任。

同样，不要仅凭订阅最低消费，就选择 Railway 或任何按资源计量的平台。入门价再诱人，也没有包含那些尚未部署的服务费用。

常见问题

Vercel 是托管平台吗？

是的。Vercel 提供 Web 应用托管与部署。本文的替代平台分别覆盖其中的不同工作，从分发静态文件，到运行常驻应用服务器。

Vercel 和 GoDaddy 有什么区别？

注册域名与部署应用是两件事。GoDaddy 提供域名注册，Vercel 提供应用托管。域名继续注册在 GoDaddy，并不意味着应用也必须托管在那里。

哪些平台比 Vercel 更合适？

对于常驻全栈服务，Render 或 Railway 可能更合适。对于静态网站与兼容的边缘负载，Cloudflare 值得优先考虑。Netlify 适合托管式 Next.js 发布流程。没有明确运行方式和负载，就不存在通用的最佳选择。

Netlify 底层用的是 Vercel 吗？

Netlify 有自己的部署平台，通过自身的 OpenNext 适配器运行 Next.js。这是一套独立部署，并不是把应用托管在 Vercel 上。

Vercel 和 Netlify 哪个更好？

如果框架行为和积分模式符合应用需求，Netlify 是值得考虑的替代方案。如果迁移成本高于预期改善，留在 Vercel 可能更好。应比较当前账单与必需功能，尤其是中间件、执行位置和部署行为。

Netlify 有哪些不足？

多种用量共享同一个积分池，额度耗尽可能让账户内其他项目暂停。Next.js 边缘运行时 SSR 的执行位置，以及部分中间件行为，与独立部署不同。启用版本偏差保护时，自定义客户端请求也需要额外检查。

有没有比 Netlify 更合适的平台？

静态资源分发和兼容的边缘代码，值得评估 Cloudflare。如果需要常驻服务或常规后台 worker，优先从 Render 或 Railway 看起。若核心需求是托管式 Web 发布，Netlify 仍是很有竞争力的选择。

Netlify 可以永久免费吗？

Netlify 目前长期提供 Free 套餐，每月包含一定积分额度。这不代表用量无限，也不保证条款永远不变。额度用完后，网站可能暂停。

GitHub 和 Netlify，托管网站选哪个？

GitHub Pages 从代码仓库文件提供静态网站服务；Netlify 还可通过适配器支持 Next.js 服务端功能。应根据网站是否需要服务端运行环境来选择。源码托管在 GitHub，不妨碍把应用部署到其他平台。参见 GitHub Pages 文档。

下周开始迁移前，先用 AI 业务工作流审查清单梳理前端、任务、数据和支出上限，找出最值得优先迁移的那一项负载。