AI SaaS积分预检机制实战：防白嫖的正确姿势

在构建 AI SaaS 产品时，很多开发者把精力集中在核心功能上，却忽略了一个关键环节——积分预检机制。没有在任务提交前验证用户积分，就可能导致 AI 算力被白嫖、服务被滥用。这篇文章手把手教你为 AI SaaS 产品加上这道"积分预检"防盗门。

为什么 AI SaaS 必须做积分预检

在典型的 AI SaaS 架构中，用户提交任务后，后端调用 AI 模型处理，处理完成后通过 webhook 回调通知结果。Webhook 是一种「事件驱动」的异步通信模式——由于模型推理往往耗时较长（从数秒到数分钟不等），同步等待会造成连接超时和资源浪费。因此主流做法是：客户端提交任务后立即获得一个任务 ID，后端异步处理；处理完成后，平台主动向预先注册的 URL 发送 HTTP POST 请求（即 Webhook 回调），通知任务结果。这种模式被 Replicate、Stability AI 等主流 AI 平台广泛采用。正是这种异步解耦的架构，使得「任务提交」和「结果返回」之间存在时间差，也因此催生了积分预检的必要性。

不少开发者会选择在 webhook 回调阶段才扣除积分——也就是任务完成后再扣费。

这种做法看似合理，但存在一个严重漏洞：如果用户积分不足，任务已经跑完了，AI 算力已经消耗了，积分却扣不了。 相当于你的 AI 服务在免费给用户打工。

所以，我们需要在任务提交之前增加一道"预检"环节：先检查用户积分是否充足，充足则放行，不足则拦截并引导充值。

积分预检的完整实现方案

后端：提交前校验积分余额

核心逻辑非常清晰：在用户提交任务的 API 接口中，先查询用户当前积分余额，与本次任务所需消耗的积分进行比较。

具体流程如下：

1. 用户发起任务请求 → 后端接收到请求
2. 查询用户积分余额 → 从数据库获取当前积分
3. 判断积分是否充足 → 与任务所需积分进行比较
4. 积分充足 → 放行，进入任务处理流程
5. 积分不足 → 返回 HTTP 402 状态码，提示用户充值

这里有一个关键细节：使用 HTTP 402 状态码。402（Payment Required）是 HTTP/1.1 规范中最早定义的状态码之一，长期处于「保留」状态，但随着互联网商业化深入，越来越多的 API 开发者将其用于表达「需要付费才能继续」的语义，逐渐形成事实标准——Stripe、GitHub API、Google Cloud 等主流平台在配额耗尽或余额不足时均会返回 402。相比返回 400（Bad Request）或自定义错误码，使用 402 的优势在于语义标准化，前端框架和监控工具可以统一识别，也便于团队协作时的接口文档理解，无需额外约定。前端可以根据这个状态码做出相应的 UI 响应。

前端：优雅处理积分不足场景

前端需要对 402 状态码进行专门处理。当检测到后端返回 402 时，应该：

• 显示"积分不足"的提示信息
• 引导用户跳转到定价页面进行充值
• 阻止任务的重复提交

这种处理方式既保护了服务端资源，又给用户提供了清晰的操作指引，体验上不会显得突兀。

积分预检与积分扣除的分工

需要特别强调的是，积分预检和积分扣除是两个独立的环节，各司其职：

环节	触发时机	核心作用
积分预检	任务提交前	拦截积分不足的请求，防止算力浪费
积分扣除	Webhook 回调时	任务完成后实际扣除积分，确保扣费准确

把积分扣除放在 webhook 回调中是合理的，因为只有任务真正完成了才应该扣费。但预检环节不可或缺，它是防止白嫖的第一道防线。

进阶：防并发与防刷策略

仅有积分预检还不够，生产环境中还需要考虑以下几个问题：

并发请求的竞态问题

如果用户只剩 1 个积分，同时发起了 2 个请求，两个请求都通过了预检怎么办？解决方案是在预检时使用乐观锁或分布式锁，确保积分检查和扣减的原子性。

两种方案适用场景有所不同：乐观锁基于「冲突概率低」的假设，通过在数据库记录中维护版本号（version）字段实现——更新时检查版本号是否与读取时一致，不一致则回滚重试，无需额外锁资源，适合并发量适中的场景。分布式锁则通过 Redis 的 SETNX 命令或 Redlock 算法，在多个服务实例之间建立互斥访问，适合高并发或跨服务的场景。对于 AI SaaS 的积分系统，乐观锁通常已足够，但若同一用户可能从多个设备同时发起请求，分布式锁能提供更强的一致性保障。

请求频率限制

即使有积分预检，恶意用户也可能通过高频请求消耗服务器资源。建议配合 Rate Limiting（限流）策略，对单用户的请求频率进行限制。常见算法包括令牌桶（Token Bucket，允许一定程度的突发流量）和漏桶（Leaky Bucket，严格匀速输出），其中令牌桶在 AI SaaS 场景中最为常用，因为它既能限制平均速率，又允许用户在短时间内有合理的突发请求。实现层面可借助 Redis 原子操作或 Kong、Nginx 等网关中间件落地。建议按用户 ID 而非 IP 进行限流，以避免 NAT 环境下误伤正常用户。

积分预冻结机制

更严谨的做法是在预检通过后，先将所需积分"冻结