Cloudflare Pages 和 Vercel 的比较，最容易被写成价格表。但对低成本个人站来说，更关键的是运行时边界、框架适配和你愿意承担多少维护复杂度。
低成本不只是账单数字
如果项目是静态内容站，选择会相对简单；如果项目用了 Next.js 动态路由、API、认证、支付或边缘运行时，平台选择就不只是上传文件，而是运行时契约的问题。
先确认站点是不是纯静态
先把页面分成纯静态内容、服务端渲染页面和动态 API。只有当大部分路径都能完全静态化时，价格和 CDN 缓存才是第一判断；否则运行时支持会先于价格表。
价格表看不出运行时代价
只看价格会忽略一个事实：便宜的平台如果让你每次发布都要处理适配差异、构建产物和运行时限制，维护成本可能很快超过节省的费用。
静态、动态、生态、速度
- 静态优先：如果页面可完全静态生成，优先选择发布链路最简单、缓存最稳定的方案。
- Next.js 深度特性优先：如果依赖框架运行时，先看平台对这些能力的原生支持程度。
- Cloudflare 生态优先：如果需要 Workers、KV、R2、边缘网络或 OpenNext 适配，Cloudflare 更值得认真评估。
- 团队速度优先：如果想少处理平台差异，选择最贴合框架默认路径的方案。
内容站加 API 后选择会变
一个 MDX 内容站可以用静态导出或轻量 SSR；但如果同一个站点还有 OAuth、payment webhook、workspace API，部署选择就要把这些动态路径一起纳入，而不是只看首页能不能打开。
先列三类路径
列出你站点的三类页面：静态内容、动态 API、第三方回调。每类都写出部署后谁负责运行。如果答案不清楚，说明还不能只按低价做决定。
它省掉的是低价误判
它要帮读者把低成本理解成总维护成本。平台价格只是表层，运行时适配、构建差异和发布信心才是长期成本。
先跑真实构建再判断
- 先列出项目是否需要动态 API、认证、支付和回调。
- 再确认框架特性在目标平台上的支持边界。
- 用一次真实 build 和预览部署验证，而不是只读介绍页。
- 把迁移成本也算进低成本判断里。
不要写成价格对比表
这篇如果写成价格对比表，会忽略个人站真正花时间的地方：适配、构建、调试、回调、预览和发布信心。低成本不是账单最小，而是长期维护时不反复被平台差异打断。
质量门：有没有算维护成本
质量门是：文章是否把静态内容、动态 API、第三方回调和目标平台构建都纳入判断。如果只比较价格或品牌，它就不适合作为决策文。