fnvtk/soul-yongping

Fork 0

Files

乘风 7b2123dfe5 打好基版

2026-02-09 15:09:29 +08:00

7.6 KiB

Raw Blame History

提现按钮逻辑修正

问题描述

错误理解：

错误地直接使用后端返回的 availableEarnings 进行判断

正确逻辑：

✅ 可提现金额 = 累计佣金 - 待审核金额
✅ 按钮启用条件：可提现金额 >= 最低提现金额

具体案例

当前数据：

累计佣金：¥8.10
待审核金额：¥0.00
计算：可提现金额 = 8.10 - 0 = 8.10元
最低提现金额：¥5.00
判断：8.10 >= 5.00 = true → 按钮应该启用（绿色）

修复方案

1. 前端计算可提现金额

在 miniprogram/pages/referral/referral.js 的 initData() 方法中：

// ✅ 修正：可提现金额 = 累计佣金 - 待审核金额
const totalCommissionNum = realData?.totalCommission || 0
const pendingWithdrawNum = realData?.pendingWithdrawAmount || 0
const availableEarningsNum = totalCommissionNum - pendingWithdrawNum
const minWithdrawAmount = realData?.minWithdrawAmount || 10

console.log('=== [Referral] 收益计算（修正后）===')
console.log('累计佣金:', totalCommissionNum)
console.log('待审核金额:', pendingWithdrawNum)
console.log('可提现金额 = 累计佣金 - 待审核金额 =', totalCommissionNum, '-', pendingWithdrawNum, '=', availableEarningsNum)
console.log('最低提现金额:', minWithdrawAmount)
console.log('按钮判断:', availableEarningsNum, '>=', minWithdrawAmount, '=', availableEarningsNum >= minWithdrawAmount)
console.log('✅ 按钮应该:', availableEarningsNum >= minWithdrawAmount ? '🟢 启用(绿色)' : '⚫ 禁用(灰色)')

2. 设置数据

this.setData({
  // 收益数据 - 格式化为两位小数
  totalCommission: formatMoney(totalCommissionNum),
  availableEarnings: formatMoney(availableEarningsNum),  // ✅ 使用计算后的可提现金额
  availableEarningsNum: availableEarningsNum,  // ✅ 数字格式用于按钮判断
  pendingWithdrawAmount: formatMoney(pendingWithdrawNum),
  minWithdrawAmount: minWithdrawAmount,
  // ...
})

3. 按钮判断逻辑（WXML）

<view class="withdraw-btn {{availableEarningsNum < minWithdrawAmount ? 'btn-disabled' : ''}}" bindtap="handleWithdraw">
  {{availableEarningsNum < minWithdrawAmount ? '满' + minWithdrawAmount + '元可提现' : '申请提现 ¥' + availableEarnings}}
</view>

注意：

类名判断：availableEarningsNum < minWithdrawAmount（数字比较）
文本显示：使用格式化后的 availableEarnings 字符串

4. 提现函数中的验证

async handleWithdraw() {
  // 使用数字版本直接进行判断
  const availableEarnings = this.data.availableEarningsNum || 0
  const minWithdrawAmount = this.data.minWithdrawAmount || 10
  
  console.log('[Withdraw] 提现检查:', {
    availableEarnings,
    minWithdrawAmount,
    shouldEnable: availableEarnings >= minWithdrawAmount
  })
  
  if (availableEarnings <= 0) {
    wx.showToast({ title: '暂无可提现收益', icon: 'none' })
    return
  }
  
  if (availableEarnings < minWithdrawAmount) {
    wx.showToast({ 
      title: `满${minWithdrawAmount}元可提现`, 
      icon: 'none' 
    })
    return
  }
  
  // ... 继续提现逻辑
}

测试步骤

1. 完全清除缓存

在微信开发者工具中：

1. 关闭微信开发者工具
2. 重新打开项目
3. 工具 → 清除缓存 → 清除全部缓存数据
4. 点击"编译"按钮

2. 查看控制台日志

应该看到类似这样的输出：

=== [Referral] 收益计算（修正后）===
累计佣金: 8.1
待审核金额: 0
可提现金额 = 累计佣金 - 待审核金额 = 8.1 - 0 = 8.1
最低提现金额: 5
按钮判断: 8.1 >= 5 = true
✅ 按钮应该: 🟢 启用(绿色)

=== [Referral] 按钮状态验证 ===
累计佣金 (totalCommission): 8.10
待审核金额 (pendingWithdrawAmount): 0.00
可提现金额 (availableEarnings 显示): 8.10
可提现金额 (availableEarningsNum 判断): 8.1 number
最低提现金额 (minWithdrawAmount): 5 number
按钮启用条件: 8.1 >= 5 = true
✅ 最终结果: 按钮应该 🟢 启用

3. 验证界面

✅ 按钮文本：申请提现 ¥8.10
✅ 按钮样式：渐变青色背景（不是灰色）
✅ 可以点击

逻辑公式总结

核心计算

可提现金额 = 累计佣金 - 待审核金额

按钮状态

if (可提现金额 >= 最低提现金额) {
  // ✅ 启用按钮（绿色）
  显示文本: "申请提现 ¥{可提现金额}"
} else {
  // ❌ 禁用按钮（灰色）
  显示文本: "满{最低提现金额}元可提现"
}

数据关系

totalCommission (累计佣金)
  ├─ 所有已完成订单的佣金总和
  └─ 显示在顶部"累计佣金"位置

pendingWithdrawAmount (待审核金额)
  ├─ 已申请提现但未审核通过的金额总和
  └─ 显示在"待审核"位置

availableEarnings (可提现金额)
  ├─ = totalCommission - pendingWithdrawAmount
  ├─ 用户实际可以申请提现的金额
  └─ 显示在提现按钮上

minWithdrawAmount (最低提现金额)
  ├─ 从管理后台配置获取
  ├─ 默认值：10元
  └─ 用于判断是否允许提现

为什么要在前端计算？

优势

实时准确：
- 每次进入页面都基于最新的累计佣金和待审核金额计算
- 避免后端缓存导致的数据延迟
逻辑清晰：
- 公式简单明了：累计佣金 - 待审核金额
- 便于调试和验证
减轻后端负担：
- 简单的减法运算在前端完成
- 后端只需返回原始数据

数据流

后端API返回:
{
  totalCommission: 8.1,        // 累计佣金
  pendingWithdrawAmount: 0,    // 待审核金额
  minWithdrawAmount: 5         // 最低提现金额
}

前端计算:
availableEarningsNum = 8.1 - 0 = 8.1  // 可提现金额

前端判断:
8.1 >= 5 ? 启用按钮 : 禁用按钮

常见问题

Q1: 为什么要保存两个字段？

availableEarnings (字符串)：用于界面显示，格式化为 "8.10"
availableEarningsNum (数字)：用于条件判断，精确比较 8.1 >= 5

Q2: 后端的 availableEarnings 还有用吗？

A: 如果后端返回了 availableEarnings，现在会被前端计算的值覆盖。建议：

方案1：后端不再返回 availableEarnings，只返回 totalCommission 和 pendingWithdrawAmount
方案2：保留后端计算，但前端不使用（当前方案）

Q3: 如果待审核金额大于累计佣金怎么办？

A: 理论上不应该出现这种情况，但可以添加保护：

const availableEarningsNum = Math.max(0, totalCommissionNum - pendingWithdrawNum)

验证清单

修改前端计算逻辑：可提现金额 = 累计佣金 - 待审核金额
添加详细调试日志
确保使用数字类型进行比较
清除小程序缓存
重新编译
查看控制台日志验证计算
确认按钮显示正确文本和样式
测试点击提现功能

总结

这次修正的核心是理解业务逻辑：

累计佣金 = 所有获得的佣金（历史总和）
待审核金额 = 已申请但未到账的金额
可提现金额 = 累计佣金 - 待审核金额 = 当前可以申请提现的金额
按钮启用 = 可提现金额 >= 最低提现金额

之前的错误是直接使用后端返回的值，没有理解这个减法关系。现在在前端明确计算，确保逻辑正确。

7.6 KiB Raw Blame History Unescape Escape