zfc/bindbox-game
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
194 Commits 3 Branches 0 Tags
Commit Graph

194 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Zuncle
25d32831ea fix(livestream): 放宽待处理订单状态筛选 
直播间 pending-orders 接口改为同时展示状态 2 和状态 3 且未发满奖励的订单，避免因为抖店同步把订单刷成已发货后页面看不到待处理订单。
 2026-04-03 16:36:18 +08:00
Zuncle
38edc9f324 fix(user): align profile inventory stats with held assets 
Count only status=1 inventory in the admin user profile so the profile inventory metrics match the held-assets inventory list semantics.
 2026-04-02 23:35:18 +08:00
Zuncle
dd1034dda8 fix(finance): correct activity profit-loss cost aggregation 
Use handler-specific activity profit/loss rules for the dashboard endpoints, counting cash, coupons, and game pass value against product cost_price. Fix missing extra reward cost aggregation and align activity logs with the same profit calculation semantics.
 2026-04-02 22:27:45 +08:00
Zuncle
4353b0f053 fix(shipping): 反转运费规则为不满5件收运费，满5件包邮 
- 运费预下单接口：< 5 件允许创建运费订单，>= 5 件拒绝
- 批量发货接口：< 5 件时强制校验已支付运费订单
- 单件发货接口：同样强制校验已支付运费订单
- 运费订单 remark 存入 inventory_ids JSON 用于关联
 2026-03-31 21:08:33 +08:00
Zuncle
53e5d81fa8 fix(auth): 商品详情接口移至公开路由，修复未登录浏览触发登录弹窗 
问题背景：
- 平台审核失败，原因：小程序页面未完整浏览即要求授权登录，属于登录规范不合规
- GET /api/app/products/:id 位于认证路由组，未登录用户访问返回 401，
  触发前端全局拦截器弹出"账号登录已过期"弹窗

修改内容：
1. router.go: 将 GET /products/:id 从 appAuthApiRouter（认证组）
   移至 appPublicApiRouter（公开组），允许未登录用户浏览商品详情
2. product.go: 针对公开端点增加安全加固
   - 增加商品 ID 参数校验（ParseInt 错误和 id<=0）
   - 将兜底错误信息从 validation.Error(err) 改为通用提示
     "商品信息获取失败"，防止原始 DB 错误泄露给未认证请求

影响范围：
- 仅影响 GET /api/app/products/:id 端点
- GET /api/app/products（商品列表）仍保留在认证组
- 该 handler 不依赖 JWT session 上下文，移至公开组后功能无变化
- 返回数据仅包含商品元信息（名称、图片、价格、库存），不含用户敏感数据
 2026-03-26 14:35:25 +08:00
Zuncle
58fd926b46 fix(finance): 统一收益统计口径，修复多处数据计算错误 
1. Revenue 口径统一为 actual_amount（真实现金到账）
   - 优惠券(discount_amount)和积分(points_amount)是平台免费发放的营销补贴，
     不算收入，改为展示字段
   - 涉及: profit_metrics.go, dashboard_spending.go, users_profit_loss.go,
     dashboard_user_spending.go, activity_rankings_admin.go

2. Cost 口径统一为奖品库存价值
   - 删除 finance service 中的积分成本扫描(Step 3)和优惠券成本扫描(Step 4)
   - 之前优惠券同时算在收入和成本两侧，导致利润被人为压低
   - 涉及: query_user.go, query_activity.go

3. 统一 value_cents fallback chain
   - finance service 改为与排行榜一致的三级回退:
     COALESCE(NULLIF(value_cents,0), price_snapshot_cents, products.price, 0)
   - 涉及: query_user.go, query_activity.go

4. 活动盈亏收入统一到 finance service
   - 删除 dashboard_activity.go 自有的 revenue SQL（含比例分摊逻辑）
   - 收入和成本统一由 finance.Service.QueryActivityProfitLoss() 提供
   - 修复日志明细 profit：道具卡倍率改用 ComputePrizeCostWithMultiplier

5. finance service 新增展示字段
   - ProfitLossDetail 增加 CouponDiscount, PointsDiscount, GamePassValue
   - 不参与 Revenue/Cost/Profit 计算，仅供前端展示营销补贴明细

6. 修复对对碰次卡订单 discount_amount 数据污染
   - matching_game_app.go 次卡下单时 DiscountAmount 错误设为活动全价
   - 改为 0（次卡支付不涉及优惠券）
   - 附带历史数据修复 migration SQL

7. 排除已分解奖品的成本重复计算
   - 用户可以把奖品分解成积分再兑换新商品，导致同一份价值被计算两次
   - 所有库存查询增加排除条件: status=3 且 remark 含 redeemed_points 或 batch_redeemed
   - 涉及 6 个文件的库存成本/资产查询

8. 排行榜详情抽屉限定活动范围
   - prize 查询增加 activity_id > 0 过滤，排除积分兑换/转入/合成等非活动产出
   - 使排行榜与其详情抽屉口径一致

修改文件(12个):
- internal/service/finance/profit_metrics.go
- internal/service/finance/query_user.go
- internal/service/finance/query_activity.go
- internal/service/finance/types.go
- internal/api/admin/dashboard_activity.go
- internal/api/admin/dashboard_spending.go
- internal/api/admin/dashboard_user_spending.go
- internal/api/admin/users_profit_loss.go
- internal/api/admin/users_profile.go
- internal/api/admin/activity_rankings_admin.go
- internal/api/activity/matching_game_app.go
- migrations/20260325_fix_matching_gamepass_discount.sql
 2026-03-26 00:01:17 +08:00
Zuncle
be245c1476 feat(rewards): API 返回奖品参考价字段 price_snapshot_cents 
rewards 接口的 rewardItem 新增 price_snapshot_cents 字段，
将数据库中的商品价格快照（分）暴露给前端用于展示参考价。
 2026-03-25 22:01:28 +08:00
Zuncle
89be01f8e3 fix: 将商城和分类接口移至公开路由，支持未登录浏览 
将 /store/items 和 /product_categories 从 appAuthApiRouter
移至 appPublicApiRouter，配合小程序端解决微信审核问题。
 2026-03-24 17:11:05 +08:00
Zuncle
46b9555823 feat(fragment): 商品成本价 + 活动奖品单次产出数量 
- products 表新增 cost_price 字段（成本价/分）
- activity_reward_settings 新增 drop_quantity（单次产出数量，默认1）
  和 cost_snapshot_cents（成本价快照）
- 奖品创建/修改时自动快照成本价，drop_quantity 限制 1-100
- 抽奖发放逻辑按 drop_quantity 循环创建多个库存项
- 抽奖结果接口按 drop_quantity 返回多条 item，前端自动合并显示
- 抽奖记录接口返回 drop_quantity 字段
- 商品管理 API 全链路支持 cost_price
 2026-03-23 22:26:06 +08:00
win
1f8f3f7fad x 2026-03-21 19:00:28 +08:00
win
2a7b731484 feat(finance): implement Phase 1 core P&L service + wire into dashboard 
- Add internal/service/finance/types.go: AssetType enum, param/result structs
- Add internal/service/finance/service.go: Service interface, read-only ctor
- Add internal/service/finance/query_user.go: QueryUserProfitLoss (4 fan-out scans)
- Add internal/service/finance/query_activity.go: QueryActivityProfitLoss (4 fan-out scans)
- Add internal/service/finance/service_test.go: 22 integration tests (all pass)
- Wire finance.Service into admin handler (admin.go)
- Replace dashboard_activity cost scan with finance.Service call (D-09: value_cents single source of truth)
- Revenue/gamepass/draw-count scans unchanged; response schema fully compatible

Co-Authored-By: claude-flow <ruv@ruv.net>
 2026-03-21 18:38:33 +08:00
win
b99bcbd06f docs(01-core-pnl-functions): create phase 1 plans 
4 plans across 3 waves:
- 01-01 (wave 1): package scaffold — types.go, service.go, service_test.go
- 01-02 (wave 2): QueryUserProfitLoss — query_user.go + user integration tests
- 01-03 (wave 2, parallel): QueryActivityProfitLoss — query_activity.go + activity tests
- 01-04 (wave 3): phase verification — static checks + full test suite gate

Covers all 20 Phase 1 requirements: PNL-01..08, DIM-01..04, RET-01/03,
AST-01, QUA-01..05.
 2026-03-21 17:27:58 +08:00
win
e78bbaaf76 docs(phase-1): add research and validation strategy 2026-03-21 17:17:56 +08:00
win
e0097f50c8 docs: gather phase 1 context 2026-03-21 17:09:14 +08:00
win
e3b0ab7cca docs: create roadmap (2 phases) 2026-03-21 16:37:24 +08:00
win
4f3b9b8fa7 docs: define v1 requirements 2026-03-21 16:31:35 +08:00
win
9e3d893938 docs: complete project research 2026-03-21 16:28:48 +08:00
win
fd2c9e242e chore: add project config 2026-03-21 16:19:29 +08:00
win
485798d551 docs: initialize project 2026-03-21 16:17:37 +08:00
win
5ede909be4 docs: map existing codebase 2026-03-21 16:01:32 +08:00
Zuncle
5b34972ee3 fix(dashboard): 盈亏分析CAST修复+视角改为平台视角(A-B) 
1. CAST修复：
   MySQL的 / 运算符返回DECIMAL类型，GORM无法将DECIMAL扫描进int64，
   导致商品产出静默返回0。添加 CAST(... AS SIGNED) 与排行榜对齐。

2. 视角统一：
   盈亏分析原为用户视角(B-A)，排行榜为平台视角(A-B)，同一用户
   一个显示+¥12,130(用户赚了)，一个显示-¥12,127(平台亏了)，
   造成管理员困惑。

   修改：
   - 净盈亏: Value-Cost → Cost-Value (A-B，平台盈利为正)
   - 盈亏比: Value/Cost → Cost/Value (A/B，>1表示平台盈利)
   - 趋势图每个数据点同步调整
 2026-03-20 21:18:02 +08:00
Zuncle
fe3141e2b5 fix(dashboard): 盈亏分析商品产出对齐排行榜计算口径 
问题：
  盈亏分析(GetUserProfitLossTrend)和用户画像(GetUserProfile)中的
  "商品产出"与玩家消费排行榜(DashboardPlayerSpendingLeaderboard)
  计算口径不一致，导致同一用户的商品产出差异巨大。

  排行榜显示用户9110商品产出¥16,913.40，盈亏分析显示¥0.00。

差异点：
  1. status条件: 盈亏用 status=1(仅待发货)，排行榜用 status IN (1,3)
  2. 价格回退链: 盈亏缺少 price_snapshot_cents 回退层级
  3. 道具卡倍率: 盈亏未计算 reward_multiplier_x1000
  4. void排除: 盈亏未排除 remark 含 void 的作废项

修复：
  - users_profit_loss.go: 商品产出查询完全对齐排行榜公式
  - users_profile.go: 库存价值查询同步对齐
  - 公式: COALESCE(value_cents, snapshot_cents, price, 0)
          * GREATEST(COALESCE(multiplier, 1000), 1000) / 1000
  - 条件: status IN (1,3) AND remark NOT LIKE '%void%'
 2026-03-20 21:02:21 +08:00
Zuncle
ddd66bf4e9 fix(dashboard): 修复盈亏分析商品产出只统计待发货库存的bug 
问题：
  盈亏分析(GetUserProfitLossTrend)和用户画像(GetUserProfile)中的
  "商品产出"查询条件为 `ui.status = 1`，只统计了待发货/库存中的商品，
  已发货/已兑换(status=3)的商品被完全排除。

  示例：用户9110实际累计获得874件商品(价值¥16,279.40)，但因为大部分
  已发货(status=3)，盈亏分析只显示商品产出¥12.50，全资产产出严重偏低。

  而 dashboard_user_spending.go 中的同类查询正确使用了
  `status IN (1, 3)`，说明此处是遗漏。

修复：
  - users_profit_loss.go: 当前资产快照查询改为 `status IN (1, 3)`
  - users_profile.go: 库存统计查询改为 `status IN (1, 3)`
  - 与 dashboard_user_spending.go 的计算口径对齐
 2026-03-20 20:39:50 +08:00
Zuncle
535106f158 fix(coupon): 修复订单超时取消时金额券未退还的bug 
问题：
  commit b9a40df 修复了 CancelOrder()（用户/管理员主动取消）的券退回逻辑，
  去掉了 `AND status = 4` 条件，但遗漏了 order_timeout.go 中超时取消的
  同一逻辑，导致次数卡包(game_pass_package)订单超时取消时金额券余额丢失。

根因：
  game_pass_package 下单时，金额券(type=1)通过 applyCouponToGamePassOrder()
  直接扣减 balance_amount 并保持 status=1（有余额）或 status=2（用完），
  不会设置 status=4（预扣中）。而 cancelExpiredOrder() 的 UPDATE 语句带有
  `WHERE id = ? AND status = 4` 条件，导致匹配不到行，退券静默失败。

  生产已确认影响：用户9110的券1690（订单28229）和券1532（订单26743）
  因此bug各丢失10元余额。

修复：
  - 去掉 `AND status = 4` 条件，改为 `WHERE id = ?`，兼容所有券状态
  - 新增幂等校验：先查 timeout_refund 流水是否已存在，防止重复退还
  - 新增兜底逻辑：order_coupons 无记录时，从 user_coupon_ledger 流水
    回推预扣金额，与 CancelOrder() 的修复方案完全对齐
 2026-03-20 20:32:30 +08:00
Zuncle
9cb4aaa511 fix(admin): 修复订单列表source_type=4/5显示未知的问题 
- source_type=4: 区分购买次卡/次卡抽奖/一番赏
- source_type=5: 区分运费订单/直播间抽奖
 2026-03-20 17:45:19 +08:00
win
a671fc14c6 运费 2026-03-20 00:57:17 +08:00
win
eaf4af4ba4 Merge remote-tracking branch 'origin/zuncle' 2026-03-19 22:37:56 +08:00
Zuncle
47c36b43cd feat(fragment): add synthesis flow and fragment restrictions with tests 2026-03-19 16:26:36 +08:00
Zuncle
4ffd8e8326 fix: 修复过期优惠券仍可兑换/使用的漏洞 
- store.go: 积分商城优惠券列表加 valid_end > now 过滤
- coupons_list.go: 修复 NULL valid_end 被错误排除，无截止日期券正确显示为有效
- activity_order_service.go: 过期/不可用券下单返回明确错误，不再静默跳过
- points_redeem_coupon_app.go: 积分兑换前校验模板 valid_end
- coupon_add.go: 发券前校验模板 valid_end，过期拒绝发放
 2026-03-18 21:58:25 +08:00
Zuncle
9f7a7d29fb fix(admin): 管理端取消订单改为调用 userSvc.CancelOrder，补充优惠券和积分退还逻辑 2026-03-18 21:12:46 +08:00
Zuncle
0722e515c4 feat(shipping): 新增管理端撤销发货功能 
- 新增 AdminCancelShipping handler，支持批量撤销待发货记录(status=1→5)
- 事务内同步恢复 user_inventory.status=1 并清空 shipping_no
- 在 remark 记录操作人 adminID，保证审计可追溯
- 注册路由 POST /api/admin/shipping/orders/cancel
 2026-03-18 20:11:37 +08:00
Zuncle
b9a40df5c5 fix(coupon): 修复订单取消时金额券未退还的bug 
订单取消退券逻辑依赖 used_order_id 匹配，但金额券在下单时
不设置 used_order_id（仅在支付确认后设置），导致未支付订单
取消时 WHERE 条件匹配不到行，退券静默失败。

修复：去掉 used_order_id 条件，按券 ID 直接退还，增加幂等
校验和错误处理，兜底从流水回推预扣金额。
 2026-03-17 21:15:33 +08:00
Zuncle
d1ee319f0e feat(dashboard): 平台有效资产增加优惠券和次卡价值统计 
- 新增优惠券总价值统计（关联system_coupons表）
- 新增次卡总价值统计（关联activities表price_draw）
- 使用Raw SQL执行复杂JOIN查询
 2026-03-17 19:17:56 +08:00
win
8d8f660e34 Merge remote-tracking branch 'origin/zuncle' 2026-03-17 18:36:24 +08:00
Zuncle
c7cd3c21e5 feat(shipping): 发货订单超过48小时不允许撤销 
- 在cancel_shipping.go中添加48小时限制检查
- 在shipping_groups.go中返回created_at字段供前端判断
- 超过48小时的订单撤销时提示'需要撤销发货请联系客服'
 2026-03-17 18:11:00 +08:00
win
a450a92673 Merge origin/zuncle into main 2026-03-17 16:00:23 +08:00
win
c0267c7a33 feat(channel): GMV支付方式拆分（现金/优惠券/积分） 
后端：
- GMVBreakdown 结构体拆分 total/cash/coupon/points 四个维度
- calcGMVByTotalAmount 返回值改为 GMVBreakdown，SELECT 增加 actual_amount/discount_amount/points_amount
- StatsOverview/StatsDailyItem 新增 cash_cents/coupon_cents/points_cents 字段
- 测试数据增加优惠券场景，新增拆分断言

前端：
- API 接口类型同步增加 3 个拆分字段
- 概览区新增支付构成行：现金/优惠券/积分 各带金额和占比
 2026-03-16 23:33:48 +08:00
win
8d1eef2f7f fix(channel): 修复渠道统计GMV重复计数和商城直购误计入 
1. 排除商城直购(source_type=1)：GMV和成本过滤条件从IN(1,2,3,4)改为IN(2,3,4)
2. 排除次卡免费使用订单(actual_amount=0)：避免购买次卡和使用次卡双重计入GMV
   - source_type=4 一番赏使用次卡：1578单 44032元重复
   - source_type=3 对对碰使用次卡：422单 7042元重复
   - 合计去除51074元虚增GMV（29.1%）
3. 成本过滤条件同步修正：source_type IN(2,3,4)，total_amount>0

修正后：GMV从175600降至124527元，毛利率从37.4%回到真实的11.8%
 2026-03-16 21:41:39 +08:00
Zuncle
fac825245b fix: 修复赠送流程地址归属错误，强制登录后才能填写收货地址 
接收者未登录时提交地址会错误保存到赠送者名下，现改为：
- API层：登录态从可选改为必选，未登录返回401
- Service层：始终用提交者ID作为地址归属人
 2026-03-15 13:23:09 +08:00
win
98694b4e69 revert: 移除转赠资产禁止兑换积分的限制 
经数据核实，转赠后兑换积分属于合法行为（资产转赠后归接收方所有）。
并发漏洞虽然产生了重复转赠/发货记录，但实际经济损失为 0 元：
- 18 个重复发货资产中，没有任何一个真正被两方都发了货
- 没有任何资产被重复兑换积分

保留前两个并发修复（SELECT FOR UPDATE + RowsAffected 检查），
回退第三个业务限制（禁止转赠资产兑换积分）。
 2026-03-15 13:23:09 +08:00
win
9cf9f798bb fix(security): 修复赠送资产薅积分三大漏洞 
1. SELECT FOR UPDATE 锁定资产行，防止并发转赠竞态条件
2. 检查 RowsAffected 防止 GORM 静默失败导致空壳发货记录
3. 兑换积分时校验转赠来源，禁止转赠资产兑换积分
4. 转赠来源校验改用写库查询，避免主从延迟绕过
5. 转赠来源查询错误不再静默忽略，失败时返回错误

基于 zuncle 分支修复，额外修正了两个安全隐患：
- RedeemInventoryToPoints/RedeemInventoriesToPoints 中
  转赠记录查询从 readDB 改为 writeDB
- Count()/Find() 返回的 error 不再丢弃
 2026-03-15 13:23:09 +08:00
win
749464c03e revert: 移除转赠资产禁止兑换积分的限制 
经数据核实，转赠后兑换积分属于合法行为（资产转赠后归接收方所有）。
并发漏洞虽然产生了重复转赠/发货记录，但实际经济损失为 0 元：
- 18 个重复发货资产中，没有任何一个真正被两方都发了货
- 没有任何资产被重复兑换积分

保留前两个并发修复（SELECT FOR UPDATE + RowsAffected 检查），
回退第三个业务限制（禁止转赠资产兑换积分）。
 2026-03-11 16:51:27 +08:00
win
8229b41382 fix(security): 修复赠送资产薅积分三大漏洞 
1. SELECT FOR UPDATE 锁定资产行，防止并发转赠竞态条件
2. 检查 RowsAffected 防止 GORM 静默失败导致空壳发货记录
3. 兑换积分时校验转赠来源，禁止转赠资产兑换积分
4. 转赠来源校验改用写库查询，避免主从延迟绕过
5. 转赠来源查询错误不再静默忽略，失败时返回错误

基于 zuncle 分支修复，额外修正了两个安全隐患：
- RedeemInventoryToPoints/RedeemInventoriesToPoints 中
  转赠记录查询从 readDB 改为 writeDB
- Count()/Find() 返回的 error 不再丢弃
 2026-03-11 16:25:11 +08:00
Zuncle
bd91c0fad1 fix(transfer): 修复赠送资产并发漏洞及转赠积分薅取问题 
- SubmitAddressShare 事务内 SELECT FOR UPDATE 锁定资产行，防止并发重复提交
- 检查 UPDATE RowsAffected，静默失败时回滚事务
- 防重检查从 readDB 移入事务内写库，消除主从延迟竞态
- RedeemInventoryToPoints/RedeemInventoriesToPoints 添加转赠来源校验，
  禁止通过转赠获得的资产兑换积分
 2026-03-11 14:14:34 +08:00
win
91dd42ca1c feat(channel): 渠道统计新增盈亏计算并修复成本口径 
后端:
- StatsOverview/StatsDailyItem 新增 cost/profit 字段
- 新增 calcPaidByPriceDraw 三路收入分类(抽奖/对对碰/一番赏)
- 新增 calcCostByInventory 成本计算(含道具卡倍数)
- 修复成本统计未过滤 source_type 导致直播间免费发奖资产被错误计入
- remark.go 新增 PkgID 解析支持一番赏订单

前端:
- 渠道统计弹窗新增"总成本"和"盈亏"卡片
- 趋势图新增"盈亏分析"Tab

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 2026-03-11 02:29:19 +08:00
Zuncle
d45096d13f fix(refund): 修复退款后翻牌游戏资格未回收的问题 
问题描述:
用户退单后，翻牌游戏资格会重新出现（被重置），但用户已经抽过奖了。
这导致用户可以通过退款获得额外的翻牌机会。

根本原因:
退款处理逻辑 reclaimLivestreamAssets 只回收了 user_inventory 中的实物奖品，
但没有回收 user_game_tickets 中的翻牌游戏资格。

解决方案:
在 reclaimLivestreamAssets 函数后添加 reclaimFlipCardTicket 函数，
用于检测并回收翻牌游戏资格：

1. 通过 shop_order_id 查询抖店订单获取商品ID
2. 查询 douyin_product_rewards 表检查商品是否配置了翻牌游戏奖励
   - 检查 reward_type = 'game_ticket'
   - 检查 payload.game_code = 'flip_card'
3. 如果配置了翻牌奖励，回收用户的翻牌次数
   - 扣减 user_game_tickets.available
   - 扣减 user_game_tickets.total_earned
4. 在 game_ticket_logs 表中记录回收日志

影响范围:
- 仅影响配置了翻牌游戏奖励的商品订单退款
- 退款时会同步回收翻牌游戏资格
- 已使用过的翻牌次数不会被回收（只回收 available > 0 的记录）

测试建议:
1. 购买配置了翻牌奖励的商品
2. 进行翻牌游戏
3. 申请退款
4. 验证翻牌资格是否被正确回收
 2026-03-08 16:01:39 +08:00
Zuncle
2aa7cdbd61 fix(shipping): 使用资产价值快照价格确保发货与分解价格一致 
修复改价后发货价格与分解价格不一致的问题：
- 发货时优先使用 user_inventory.value_cents 快照价格
- 后台发货列表使用 shipping_records.price 存储的快照价格
- 确保盈亏统计时价格数据准确一致
 2026-03-05 17:54:58 +08:00
win
a29669ccf6 chore: update web/admin revision 2026-03-05 12:53:29 +08:00
win
b3b63dcba2 admin 2026-03-05 12:50:06 +08:00
win
994a7ba0df 邀请关系 2026-02-27 17:51:38 +08:00