Tigshop开源商城 分销中心:源码只留了 salesman 表,C 端接口我给补全(附代码

简介: tigshop开源版虽预留分销数据模型(Salesman等),但C端接口缺失。本文基于现有model快速补全一级返佣与“我的分销中心”功能:新增Service聚合数据、Controller提供API、路由注册及支付回调自动记佣,前端Uniapp对接展示,零建表、轻量落地。(239字)

在 tigshop 单商户版里翻分销功能,会看到一个挺微妙的状态。php/app/model/salesman/SalesmanSalesmanOrderSalesmanCustomerSalesmanProduct 这些模型都在,表结构也齐;但 php/app/api/controller/ 里没有 salesman 目录,php/app/service/admin/ 下也没有 salesman 这一层。

也就是说,分销中心是 Pro 功能,开源版只给你留了数据层,C 端一个接口没有。官网功能清单里"多级分销、分销中心、推广海报"后面确实都标着 (Pro)。

这次客户只要个最简单的一级返佣加"我的分销中心",没必要为这个上 Pro。我照着 model 已有的字段,把 C 端接口补了出来。

先认字段

建表的功夫省了,salesman_order 表该有的都定义好了。翻一下实际列名,别想当然:

-- salesman_order 实际字段(数据库里已有)
salesman_order_id  int          -- 主键
order_id           int          -- 订单ID
salesman_id        int          -- 分销员ID
amount             decimal(10,2)-- 收益总额(注意是 amount,不是 commission_amount)
order_amount       decimal(10,2)-- 订单商品金额
status             tinyint      -- 0待结算 1已结算
salesman_settlement_data text   -- 结算配置快照(json)

我一开始按习惯写了 commission_amount,跑起来报字段不存在,翻表才发现佣金列叫 amountSalesmanCustomer 记录"谁是谁拉来的",salesman_iduser_id,绑定关系一有,返佣就有依据。

补 C 端 Service

tigshop 前台 Service 放 php/app/service/front/,新建 salesman/SalesmanCenterService.php,把"我的分销数据"聚合出来:

<?php
namespace app\service\front\salesman;

use app\model\salesman\Salesman;
use app\model\salesman\SalesmanOrder;
use app\model\salesman\SalesmanCustomer;

class SalesmanCenterService
{
   
    // 分销中心首页数据
    public function overview(int $userId): array
    {
   
        $salesman = Salesman::where('user_id', $userId)->find();
        if (!$salesman) {
   
            return ['is_salesman' => 0];
        }
        $sid = $salesman->salesman_id;

        return [
            'is_salesman'     => 1,
            'salesman_id'     => $sid,
            'customer_count'  => SalesmanCustomer::where('salesman_id', $sid)->count(),
            'total_commission'=> SalesmanOrder::where('salesman_id', $sid)
                                    ->where('status', 1)->sum('amount'),
            'wait_commission' => SalesmanOrder::where('salesman_id', $sid)
                                    ->where('status', 0)->sum('amount'),
        ];
    }

    // 我的返佣订单
    public function orderList(int $userId, int $page, int $size): array
    {
   
        $salesman = Salesman::where('user_id', $userId)->find();
        if (!$salesman) return ['records' => [], 'total' => 0];

        $query = SalesmanOrder::where('salesman_id', $salesman->salesman_id)
            ->with(['orderUserInfo'])
            ->order('salesman_order_id', 'desc');

        return [
            'records' => $query->page($page, $size)->select(),
            'total'   => $query->count(),
        ];
    }
}

orderUserInfoSalesmanOrder 模型里现成的关联,能带出订单号、金额这些,不用自己 join。

补 C 端 Controller

照 tigshop 现有 controller 的写法:继承 IndexBaseController、构造注入 Service、返回 $this->success()。用户 id 直接从 request()->userId 取,跟 Address 那些控制器一致:

<?php
namespace app\api\controller\user;

use app\api\IndexBaseController;
use app\service\front\salesman\SalesmanCenterService;
use think\App;
use think\Response;

class Salesman extends IndexBaseController
{
   
    protected SalesmanCenterService $service;

    public function __construct(App $app, SalesmanCenterService $service)
    {
   
        parent::__construct($app);
        $this->service = $service;
    }

    public function center(): Response
    {
   
        $this->checkLogin();
        return $this->success($this->service->overview(request()->userId));
    }

    public function orderList(): Response
    {
   
        $this->checkLogin();
        $page = $this->request->all('page/d', 1);
        $size = $this->request->all('size/d', 15);
        return $this->success($this->service->orderList(request()->userId, $page, $size));
    }
}

挂路由

跟着 php/app/api/route/user.php 里 address / aftersales 那几组的写法加一段:

Route::group('salesman', function () {
   
    Route::get('center', 'user.salesman/center');
    Route::get('orderList', 'user.salesman/orderList');
})->middleware([\app\api\middleware\CheckLogin::class]);

返佣在哪触发

绑定关系有了,得在订单支付成功后记一笔返佣。tigshop 的支付回调在 php/app/api/controller/order/Pay.phpnotify,成功后我加了个钩子写 salesman_order

// 支付成功后:给上级分销员记一笔待结算
$customer = SalesmanCustomer::where('user_id', $order['user_id'])->find();
if ($customer) {
   
    SalesmanOrder::create([
        'salesman_id' => $customer->salesman_id,
        'order_id'    => $order['order_id'],
        'amount'      => bcmul($order['total_amount'], '0.10', 2), // 一级 10%
        'status'      => 0, // 待结算,确认收货后再转 1
    ]);
}

字段用 amount,别再写成 commission_amount。确认收货或者售后期过了,再跑个定时任务把 status 从 0 改成 1,宝塔计划任务加个 php think 命令定时扫一遍就行。

前端 Uniapp 分销中心页

Uniapp 的 api 定义统一放 view/Tigshop-Uniapp/src/api,我加了个 salesman.ts

// src/api/salesman.ts
import request from '@/utils/request'

export const getSalesmanCenter = () => request.get('/api/user/salesman/center')
export const getSalesmanOrders = (page = 1) =>
  request.get('/api/user/salesman/orderList', {
    page })

页面 src/pages/salesman/center.vue 拉数据展示:

<script setup lang="ts">
import { ref, onMounted } from 'vue'
import { getSalesmanCenter } from '@/api/salesman'

const info = ref<any>({})
onMounted(async () => { info.value = (await getSalesmanCenter()).data })
</script>

<template>
  <view v-if="info.is_salesman" class="center">
    <view>累计佣金:{
  { info.total_commission }}</view>
    <view>待结算:{
  { info.wait_commission }}</view>
    <view>我的客户:{
  { info.customer_count }} 人</view>
  </view>
  <view v-else>你还不是分销员</view>
</template>

这只补了一级返佣加分销中心,多级、团队、推广素材那些还是 Pro 的完整功能。但客户只想给老客户开个返佣的话,这几处改完就能跑。model 层留得全,补 C 端不用建表;真要做多级,可以顺着 SalesmanOrdersalesman_settlement_data 这个 json 字段往里塞层级快照。

相关文章
|
1天前
|
前端开发 机器人 API
用户反馈想升级成工单,Tigshop开源商城轻量改法
该方案针对商城反馈“石沉大海”问题,发现标品已具备状态管理与站内通知能力,仅缺运营触达与用户进度可见性。通过异步推送消息至企微/钉钉群、前端透出反馈状态,低成本解决专业感缺失问题,避免过早引入复杂工单系统。(239字)
|
22天前
|
运维 安全 Java
为什么不建议从零开发商城?集体放弃自研,转向开源二开的核心原因
电商技术选型核心在于规避隐性成本:自研商城看似自由,实则长期维护、迭代、安全投入巨大;成熟开源系统可省60%无效开发。本文对比VortMall(高并发多业态)、TigShop(全开源Java/低二开成本)、Jinor(PHP轻量快启)等5大主流方案,聚焦架构弹性、源码透明、生态持续与场景匹配,助企业精准降本增效。
119 0
为什么不建议从零开发商城?集体放弃自研,转向开源二开的核心原因
|
23天前
|
SQL 安全 Java
MyBatis Plus 封神玩法:这12个操作让开发效率直接起飞!
本文以外婆羊肉汤为喻,生动诠释MyBatis-Plus的12个核心优化技巧:避免isNull、精准select、批量操作、善用exists、安全排序、Lambda类型安全、between替代ge/le、索引友好排序、规范分页、空值条件优雅处理,并涵盖性能追踪、枚举映射等高级实践,助你写出高效、安全、可维护的ORM代码。
251 0
|
2天前
|
云安全 人工智能 运维
阿里云联动百位企业安全专家,共识Agent防御最佳实践
当Agent成为新员工,你的安全边界在哪里?
1723 1
阿里云联动百位企业安全专家,共识Agent防御最佳实践
|
10天前
|
人工智能 JSON 安全
Fastjson远程代码执行漏洞,阿里云AI安全为您保驾护航
阿里云AI安全产品联动防御Fastjson攻击
2431 12
Fastjson远程代码执行漏洞,阿里云AI安全为您保驾护航
|
10天前
|
人工智能 自然语言处理 数据挖掘
Qwen3.8-Max-Preview深度全解析:2.4万亿参数旗舰MoE模型+Token Plan限时优惠完整落地指南
2026年7月,全新旗舰级混合专家大模型Qwen3.8-Max-Preview正式开放抢先体验,作为通义千问Qwen3系列规格最高、综合推理能力顶尖的新一代模型,该模型总参数量达到2.4万亿(2.4T),是当前线上可调用的原生多模态旗舰模型,综合推理水准对标海外顶级Fable 5模型,在复杂工程开发、长文档深度分析、多步骤智能体自治、跨境多语言创作、海量数据挖掘五大高难度业务场景实现跨越式性能提升。
1140 2
|
12天前
|
人工智能
Qwen3.8抢先体验!正式版即将发布并开源!
千问Qwen3.8即将开源,参数达2.4T,进化速度以“天”计,实力媲美Fable 5。预览版Qwen3.8-Max已上线阿里Token Plan等平台,限时优惠:日间Credits低至1折,夜间更优,个人/团队版月付仅35元起!
1115 47
|
9天前
|
自然语言处理 测试技术 API
通义千问Qwen3.8-Max-Preview全功能解析:2.4万亿参数旗舰模型深度使用指南
在大模型技术持续迭代的当下,通义千问推出的Qwen3.8-Max-Preview作为新一代旗舰预览版模型,凭借2.4万亿参数的超大规模、多模态融合能力与全场景适配特性,成为开发者与企业用户探索AI应用的核心工具。该模型采用稀疏混合专家(MoE)架构,是通义千问首个突破万亿参数的多模态模型,可同时处理文本、图像、视频与文档等多种数据形态,在全栈代码开发、复杂逻辑推理、长文档分析与多智能体协作等场景实现跨越式升级。本文将全面拆解Qwen3.8-Max-Preview的核心功能,详解API调用流程与配置方法,覆盖多场景实战技巧,帮助用户快速掌握这款旗舰模型的使用方法,充分释放其性能潜力。
578 1