一位开发者通过将客户端轮询间隔从 30 秒延长到 15 分钟，降低了 Neon 无服务器数据库的计算费用。更长的停顿让数据库有足够的时间处于空闲状态并缩减至零（scale to zero），从而消除了原本因每 30 秒一次的持续轮询而消耗的计算额度。
Neon 按其计算引擎运行的每一秒进行计费。在典型的无服务器设置中，任何请求——无论多么微小——都会让引擎保持唤醒状态。作者的电视仪表板每半分钟查询一次数据库，尽管显示的数据仅在用户手动同步或新广播开始时才会更改。这种模式导致 Neon 的计算池无法进入停止计费的零状态，使得 Vercel 成本仪表板上出现了规律性的费用峰值。
为什么原始轮询方式很重要
- 仪表板是一个纯客户端 React 组件，因此每个浏览器实例都会直接请求 Neon。
- Neon 的定价将成本与活跃计算时间挂钩，而非请求次数，因此每 30 秒一次的请求会维持一个基础费用。
- 作者的 Vercel 监控显示流量与 Neon 计算使用量之间存在相关性，证实了轮询让数据库一直保持唤醒状态。
失败的权宜之计
简单的防抖（debounce）处理——即在最后一次用户交互后延迟请求——并没有起到作用，因为定时器仍然每 30 秒触发一次。我也尝试过使用 Vercel Edge Functions，但这增加了太多的复杂性。
简单的修复方法
唯一需要的代码更改就是替换定义刷新间隔的常量：
- 从 30 秒 → 5 分钟
- 然后是 5 分钟 → 15 分钟
在 15 分钟的间隔下，Neon 有充足的时间识别到不活动状态并停止运行其计算资源。仪表板依然可以正常工作：用户在手动刷新时仍能看到最新数据，而偶尔的自动轮询可以在没有持续通信的情况下捕捉到新的广播。
为什么要保持客户端轮询？
- 简单 – 无需额外的无服务器函数或构建步骤。
- 用户预期 – 仪表板的行为已经像一个客户端应用；手动点击仍能实现即时更新。
- 成本模型一致性 – Neon 按计算秒数计费，而非按请求次数计费，因此降低频率可以直接减少账单。
给无服务器开发者的启示
- 将轮询频率与数据的实际更新节奏相匹配。如果数据集每小时仅更改几次，那么 15 分钟的间隔通常就足够了。
- 在无服务器环境中，频繁的轮询是一个隐藏的成本驱动因素；每分钟多出一次请求就可能导致数据库永远无法缩减规模。
- 微小的配置调整即可在无需进行架构重构的情况下产生巨大的成本节省。
核心结论是：仅通过更改一个常量，就将一个始终处于唤醒状态的数据库转变为一个真正的无服务器组件，在保持仪表板实用性的同时削减了计算支出。对于任何运行 Neon 或类似按秒计费计算服务的团队来说，重新审视轮询间隔是一个值得立即尝试的快速优化方案。