积分“凭空消失”？一次 AI 生成系统的惊魂排查实录

用户的钱袋子就是产品的命根子，哪怕是 1 积分的“假扣费”，通过放大镜看也是严重的信任危机。

🎯 写在前面

“大熊，完了！我刚才生成图片失败了一次，但是积分扣了没退给我！”

昨天深夜，我突然收到用户的紧急反馈。说实话，看到这句话我心里咯噔一下。做付费产品，最怕的就是涉及“钱”和“积分”的 Bug。这不仅仅是修个代码的问题，而是关乎用户对平台的信任。

我立马丢下手中的咖啡，冲到电脑前。如果真的是系统吞了用户的积分，那可是大事故。

图：深夜紧急排查代码的场景

💡 问题背景

我们做 AI 图片生成的都知道，因为 GPU 资源昂贵，通常都会有一套“生成前预扣费，失败后自动退款”的机制。

我们的 NanoBanana 生成器也是这么设计的：

用户点击生成 -> 扣除 20 积分
AI 努力画图中…
如果画好了 -> 交易完成
如果画失败了 -> 系统自动退还 20 积分

逻辑看似天衣无缝，怎么会“积分消失”呢？

我自己试了几次，网络好的时候都正常。直到我模拟了一次“弱网超时”的环境… 果然！

图：生成报错后，余额确实少了

虽然我知道后端数据库里可能已经退了，但界面上这个数字就是不涨回来！这就好比你转账失败了，银行卡余额却少了，虽然银行说“过会儿退你”，但这一刻你的心绝对是悬着的。

🚀 解决方案

经过前后端一通地毯式排查，我发现这其实是个“混合双打”的问题：

前端的“视觉欺诈”：为了让 APP 点击反应快，我用了一种叫“乐观更新”的技术。就是还没等服务器说扣钱，前端先由自己把数字减掉。结果报错的时候，前端忘了去问服务器要最新的余额，导致一直显示“扣费后”的假余额。
后端的“隐形杀手”：当网络极差导致超时（比如超过100秒）时，后端的代码可能因为连接断开而被强行中断，导致原本准备好的“退款代码”没机会执行。

找到病灶，手术开始。

📋 实战操作

第一步：拆穿前端的“谎言”

这是最直接的修复点。我们不能光顾着“乐观”，出错的时候必须“现实”一点。

我在前端的错误处理逻辑里，加了一个强制同步的动作。不管发生什么错误（超时、断网、报错），只要流程结束，必须从服务器拉取一次最新的余额。

// ui.js 的关键修复

try {
    // ... 执行生成任务 ...
} catch (error) {
    console.error('生成出错了:', error);
    
    // 🚨 关键一步：通过后端获取真实余额
    // 之前就是少了这一步，导致界面一直显示假数据
    console.log('🔄 正在同步最新积分...');
    refreshUserProfile().catch(e => console.warn('同步失败:', e));
    
    showToast('生成失败，积分已自动退回', 'info');
}

图：加上这行代码，心里踏实多了

第二步：给后端穿上“防弹衣”

后端的问题更棘手。如果 Request 断了，代码就不跑了吗？

不管是 Node.js 还是其他语言，确保“原子性”是关键。我引入了一个 generationCompleted 的标志位，并且把退款逻辑包在了更坚固的异常捕获里。

只有当我不确定图片是否真的生成完时，我才会去退款；而且就算天塌下来（报错），退款这个动作也要尽最大努力执行。

// generation.js

let deducted = false; // 是否扣过钱
let generationCompleted = false; // 是否真的做完了

try {
    await spendCredits(); // 1. 扣钱
    deducted = true;
    
    await generateImage(); // 2. 画图
    generationCompleted = true; // 3. 标记完成
    
} catch (error) {
    // 🛡️ 智能退款保护
    // 只有当扣了钱，且还没生成完的时候，才执行退款
    if (deducted && !generationCompleted) {
        console.log('检测到失败，正在执行退款...');
        await creditService.addCredits(...); 
    }
}

这样一来，哪怕是超时导致的连接中断，只要逻辑走到 catch，钱就能退回去。

⚠️ 踩坑记录

坑1：乐观更新的代价

现象：用户体验是快了，点击按钮余额秒变。但一旦流程异常中断，数据一致性就崩了。
原因：过度信任前端状态，忽略了异常时的状态回滚。
解决：在所有“非成功”路径（catch, finally）中加入强制状态同步。

坑2：Cloudflare 的 100秒超时

现象：即使我后端设置了 3 分钟超时，前端还是 100秒就断了。
原因：我们用了 Cloudflare 的免费版 CDN，它有个强制的 100s 超时限制。
解决：后端不能指望前端一直连着。需要做“断连监听”或者把耗时任务改成异步轮询（Pending List）。这次先修了退款，下次得把异步任务加上。

✨ 最终效果

修复部署后，我立马去测试了一波“断网大法”。

当我拔掉网线模拟超时，界面弹出“生成失败”，但右上角的余额数字，在那一瞬间自动跳回了原来的数值！

图：报错的同时，积分完好无损地回来了

看到那个数字跳回来的一刻，我知道，信任危机解除了。

💭 使用心得

这次排查让我再次深刻体会到：“墨菲定律”在支付系统里永远生效。

永远不要信任前端展示：前端的钱只是数字，后端的数据库才是钱。
错误处理比成功逻辑更重要：写代码时，要把 80% 的精力花在考虑“如果失败了怎么办”上。
给用户确定性：用户不怕失败，怕的是不明不白的失败，尤其是涉及到利益的时候。

🙋 写在最后

你的项目中遇到过这种“前端说扣了，后端说没扣”的幽灵 Bug 吗？欢迎在评论区聊聊你的填坑经历！

我是大熊，一个 ALL IN AI 的超级个体。如果这篇文章对你有帮助，欢迎点赞、收藏、转发。