积分商城源码解析：独立代理后台与积分交易架构设计

简介：一套积分商城与代理分销一体化系统源码，面向需要快速搭建积分兑换、会员成长体系和代理推广返利场景的PHP开发者、产品运营及中小团队。系统包含商城前台、用户积分管理、订单处理、独立代理后台等模块，覆盖商品展示、积分抵扣、订单流转、代理佣金结算的完整链路，可有效缩短从需求到上线的时间成本。压缩包共2000个文件，以html页面模板、php业务逻辑、css样式、js交互脚本、dat数据文件为主体，并附带sql安装脚本、pem/cer证书及各类配置文件，整体大小约291MB。其中html模板便于直接调整商城页面，php文件承载核心业务，js和css负责交互与样式，dat与sql配合完成数据存储与初始化。配套说明明确部署环境为Linux+Centos7以上+宝塔面板、Nginx1.18、PHP7.0、Mysql5.6，同时提示在/Application/Common/Conf中修改数据库信息、伪静态选择thinkphp，方便在此基础上做二次开发。目前已有87人学习，适合作为积分商城或代理分销系统的源码参考与沿用。

1. 积分商城系统为什么必须拆出独立代理后台

做积分商城的项目，最常见的翻车不是商品图不好看，而是代理和会员共用一套后台。代理拿着同一个管理端入口，既能看会员余额，又能改订单状态，运营上线第一个月就在对账上吵起来。奇偶商城系统源码的价值恰恰是把这件事分开：一套给会员用的商城前台，另一套是独立代理后台，代理的登录、菜单、权限、分账都走单独的会话和路由。所谓“完美版”，我的理解不是页面多华丽，而是把积分获取、兑换、退分、代理结算这几条链路在数据层闭环。这篇文章不列功能清单，只讲这套源码里最值得抄的表结构、交易顺序和代理分账逻辑，适合准备用积分商城源码建站，或者想给现有商城加代理分销体系的开发者。

2. 先做对积分模型，再做商城页面：积分账户、流水与任务表

很多商城源码把积分直接挂在用户表上，一个points字段走天下，这是最坑的设计。积分是资产，资产不能只有余额，还得有流水。奇偶商城系统源码里积分被拆成账户表和流水表，余额只是流水的汇总，任何积分变动都要落流水。这样对账、退分、代理分佣才有依据。界面可以后期改，表结构错了，后面所有统计都是错的。

2.1 积分账户表：可用积分和冻结积分必须分开

会员账户表的第一版建表语句如下，照抄到 MySQL 5.7 以上即可用。

CREATE TABLE `member_account` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `member_id` int(11) NOT NULL DEFAULT '0' COMMENT '会员ID', `points` int(11) NOT NULL DEFAULT '0' COMMENT '当前可用积分', `frozen_points` int(11) NOT NULL DEFAULT '0' COMMENT '冻结积分，下单后先冻结', `total_earned` int(11) NOT NULL DEFAULT '0' COMMENT '累计获得积分', `total_spent` int(11) NOT NULL DEFAULT '0' COMMENT '累计消耗积分', `version` int(11) NOT NULL DEFAULT '0' COMMENT '乐观锁版本号', `updated_at` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_member_id` (`member_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='会员积分账户';

这里最关键的是points和frozen_points两个字段。用户下单时先把积分从points挪到frozen_points，支付成功再转正；订单取消再从frozen_points退回points。如果不分冻结字段，就会出现用户下单后积分被其他订单花掉，支付时不够扣的情况。

total_earned和total_spent是冗余统计字段，代理后台要展示“名下会员累计消费了多少积分”时直接读这一行，不需要SUM全表流水。version字段给积分调整等低频写操作用乐观锁，后面章节会讲具体用法。

2.2 积分流水表：一个订单号串起积分的一生

积分流水表要记录每一次积分的来去，包括获取、兑换、过期、退分、人工调整五类，业务上最忌讳直接改余额不留记录。建表语句如下。

CREATE TABLE `points_transaction` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `member_id` int(11) NOT NULL DEFAULT '0', `order_no` varchar(32) NOT NULL DEFAULT '', `type` tinyint(4) NOT NULL DEFAULT '0' COMMENT '1获取 2兑换扣减 3过期 4退分 5手动调整', `change_points` int(11) NOT NULL DEFAULT '0' COMMENT '变动值，收入为正，支出为负', `before_points` int(11) NOT NULL DEFAULT '0', `after_points` int(11) NOT NULL DEFAULT '0', `remark` varchar(255) NOT NULL DEFAULT '', `created_at` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_member_type` (`member_id`, `type`), KEY `idx_order_no` (`order_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='积分流水表';

order_no这个字段很重要，必须跟业务单号关联，一个订单从冻结、扣减到退分的所有流水都靠它串起来。before_points和after_points存的是变动前和变动后的余额快照，后面做“积分从哪里来、到哪里去”的用户流水页时，不需要再回查账户表。这里存的是快照，代价是流水表会变大，所以查询永远走member_id + type或order_no索引，不要写不带条件的全表查询。

2.3 商品表和订单表：库存也要拆分锁定库存

积分商品和普通电商商品不一样，它没有真实货币结算，所以库存和订单状态必须自己管清楚。积分商品表建议加一个locked_stock，下单锁定库存，超时未支付自动释放。

CREATE TABLE `points_goods` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `title` varchar(100) NOT NULL, `points_price` int(11) NOT NULL COMMENT '积分价格', `stock` int(11) NOT NULL DEFAULT '0' COMMENT '总库存', `locked_stock` int(11) NOT NULL DEFAULT '0' COMMENT '待支付锁定库存', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '1上架 0下架', `created_at` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='积分商品表';

订单表里要预留代理归属字段agent_id，会员通过代理分享的链接注册或下单时，这个字段就会被写入。返佣按订单归属来算，而不是按会员归属，这样代理之间抢人时也有据可查。订单表建表语句如下。

CREATE TABLE `points_order` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL, `member_id` int(11) NOT NULL, `goods_id` int(11) NOT NULL, `points` int(11) NOT NULL COMMENT '实际扣减积分', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0待支付 1已兑换 2已发货 3已完成 4已取消 5已退分', `agent_id` int(11) NOT NULL DEFAULT '0' COMMENT '归属代理ID', `created_at` datetime NOT NULL, `paid_at` datetime DEFAULT NULL COMMENT '支付完成时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_member_status` (`member_id`, `status`), KEY `idx_agent_id` (`agent_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='积分兑换订单表';

订单表里冗余agent_id，是给独立代理后台分账用的。不要在结算时再通过“会员表 -> 代理关系表”反查归属，代理改绑后历史订单结算会乱。下单时定格归属，后面谁来了都改不动这笔单子的分佣对象。

3. 积分交易主链路：兑换、抵扣、退分的正确顺序

积分交易和真实支付最大的不同在于：积分本身就是钱，且没有第三方支付回调。所以冻结、扣减、退分全要靠代码自己保证。我看到很多二次开发把顺序写反，先扣库存，再检查积分，结果库存扣了积分不足，用户卡在中间状态。正确的顺序是：先锁库存，再冻结积分，再创建订单，支付（或确认收货）后转正。

3.1 库存预占：用一条 UPDATE 防止超卖

先看最前面的两个动作，预占库存和冻结积分。这里不能用“先 SELECT 再 UPDATE”的写法，并发下会超卖。

// 1. 预占库存，stock - locked_stock 是剩余可卖数 $locked = $pdo->prepare( "UPDATE points_goods SET locked_stock = locked_stock + 1 WHERE id = :goods_id AND stock - locked_stock > 0" ); $locked->execute([':goods_id' => $goodsId]); if ($locked->rowCount() === 0) { throw new \RuntimeException('商品库存不足'); } // 2. 冻结积分，把可用积分挪到冻结字段 $freeze = $pdo->prepare( "UPDATE member_account SET points = points - :need_points, frozen_points = frozen_points + :need_points WHERE member_id = :member_id AND points >= :need_points" ); $freeze->execute([ ':need_points' => $needPoints, ':member_id' => $memberId, ]); if ($freeze->rowCount() === 0) { throw new \RuntimeException('积分不足'); }

第一步的WHERE stock - locked_stock > 0是库存防超卖的关键，数据库行锁保证同一时刻只有一个请求能把最后一件商品锁走。第二步的写法避免了先查余额再改余额的中间态，points >= :need_points直接放进 UPDATE 的 WHERE 条件里，InnoDB 会锁住这行账户记录，判断和扣减是原子的。

代码里我先扣库存再冻结积分，是因为库存是稀缺资源，先占住库存，积分不足时再回滚释放。两步之间不用事务也行，因为第二步失败时执行ROLLBACK或反向 UPDATE 释放锁定的库存。更稳妥的做法是把两步放到一个事务里，下面讲退分时会看到同样的事务模式。

3.2 支付确认：冻结积分转正

用户点击“确认兑换”或后台审核通过后，执行转正操作。转正不是直接加积分，而是把frozen_points减掉，同时把订单状态推进到“已兑换”。

$pdo->beginTransaction(); try { // 1. 冻结积分转正，同时写流水 $pdo->prepare( "UPDATE member_account SET frozen_points = frozen_points - :points WHERE member_id = :member_id" )->execute([ ':points' => $order['points'], ':member_id' => $order['member_id'], ]); $pdo->prepare( "INSERT INTO points_transaction (member_id, order_no, type, change_points, before_points, after_points, remark) VALUES (:member_id, :order_no, 2, :points, 0, 0, '积分兑换商品')" )->execute([ ':member_id' => $order['member_id'], ':order_no' => $order['order_no'], ':points' => -$order['points'], ]); // 2. 订单状态置为已兑换 $pdo->prepare( "UPDATE points_order SET status = 1, paid_at = NOW() WHERE order_no = :order_no" )->execute([':order_no' => $order['order_no']]); $pdo->commit(); } catch (\Throwable $e) { $pdo->rollBack(); throw $e; }

流水表里的before_points和after_points字段在转正这一步不需要精确填，因为冻结积分是不可用状态，改的是frozen_points。但要保证type = 2的流水跟订单号一一对应，这样用户中心展示“兑换记录”时能直接 JOIN 订单表。

3.3 退分：先恢复积分，再恢复库存

积分订单超时未支付或者用户主动取消时，要退分。退分和扣减是镜像操作，但有一个常见错误：直接把刚冻结的积分加回points，却没有减frozen_points，导致账户同时拥有可用积分和冻结积分。

public function refund(PDO $pdo, string $orderNo): void { $order = $this->loadOrder($pdo, $orderNo); if (!in_array($order['status'], [0, 1], true)) { throw new \RuntimeException('订单状态不允许退分'); } $pdo->beginTransaction(); try { // 1. 冻结积分退回可用积分 $pdo->prepare( "UPDATE member_account SET frozen_points = frozen_points - :refund_points, points = points + :refund_points WHERE member_id = :member_id" )->execute([ ':refund_points' => $order['points'], ':member_id' => $order['member_id'], ]); // 2. 写退分流水 $pdo->prepare( "INSERT INTO points_transaction (member_id, order_no, type, change_points, before_points, after_points, remark) VALUES (:member_id, :order_no, 4, :refund_points, 0, 0, '订单取消退分')" )->execute([ ':member_id' => $order['member_id'], ':order_no' => $order['order_no'], ':refund_points' => $order['points'], ]); // 3. 解锁库存 $pdo->prepare( "UPDATE points_goods SET locked_stock = locked_stock - 1 WHERE id = :goods_id AND locked_stock > 0" )->execute([':goods_id' => $order['goods_id']]); // 4. 订单状态置为已退分 $pdo->prepare( "UPDATE points_order SET status = 5 WHERE order_no = :order_no" )->execute([':order_no' => $orderNo]); $pdo->commit(); } catch (\Throwable $e) { $pdo->rollBack(); throw $e; } }

参数说明：change_points在退分场景写正数，因为从用户视角是拿回积分。后面对账时，type = 4的流水加总，就能算出当天退了多少积分。库存的locked_stock - 1必须加locked_stock > 0条件，防止重复退分把库存锁成负数。

3.4 订单超时自动取消的定时任务

已经冻结积分但一直不确认的订单，需要定时任务清扫。常见的做法是每 5 分钟跑一次，把超过 30 分钟未支付的订单全部挑出来调refund()。

*/5 * * * * php /www/wwwroot/points/cli.php order auto-cancel --expire=1800

命令参数说明：expire=1800单位是秒，即创建 30 分钟未支付就取消。这个定时任务要在 CLI 模式下跑，不要用 Web 访问触发，否则 PHP 脚本超时时间不够，几万张订单会扫不完。任务执行时先查一批订单号，再逐条调refund()，每次最多处理 500 条，避免单次执行内存溢出。

自动退分脚本跑完一定要看日志，退分失败最常见的原因不是代码，而是订单状态已经被人工改成“已发货”，脚本检测到状态不满足in_array($status, [0, 1])就抛异常。这时不要改代码，去后台查人工操作记录，把冲突订单挑出来单独处理。

4. 独立代理后台：权限、会话隔离与分账结算

独立代理后台是这源码标题里最核心的卖点。很多二次开发图省事，给会员表加个is_agent字段，会员登录后跳到一个代理菜单，结果所有接口都在同一个会话里。这样做权限永远切不干净，代理能调用户接口、用户能调代理接口。独立代理后台的正确做法是四个独立：入口独立、会话独立、权限独立、数据独立。

4.1 独立入口与会话隔离：一行代码挡住串号

常规的路由结构是：前台index.php，会员中心user.php，管理后台admin.php，代理端agent.php。代理端入口第一行代码要设置独立的 session 名称，和用户端、管理端完全分开。

<?php // agent.php 入口 session_name('AGENTSESS'); session_start();

如果不在session_name上区分，用户端登录后浏览器里存的是PHPSESSID，代理端登录也是PHPSESSID，两个 cookie 同名互相覆盖，用户刷新一下变成代理身份，代理刷新变成用户身份。用独立的 session 名称后，用户端 cookie 是PHPSESSID，代理端 cookie 是AGENTSESS，互不干扰，可以同时在线。

4.2 代理账号独立建表：账号体系和会员体系分开

代理账号不应该挂在用户表里，要建独立的agent表和权限表。代理账号由平台运营在后台创建，不开放自助注册，避免代理互相发展下线导致分佣关系混乱。

CREATE TABLE `agent` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `username` varchar(32) NOT NULL, `password_hash` varchar(255) NOT NULL, `parent_id` int(11) NOT NULL DEFAULT '0' COMMENT '上级代理ID，0为顶级', `level` tinyint(4) NOT NULL DEFAULT '1' COMMENT '代理等级，对应不同分佣比', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '1正常 0禁用', `created_at` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='代理账号表';

代理端登录成功后，把agent_id存进独立 sessionAGENTSESS，之后所有代理端接口先取这个值。如果agent.status为 0，任何接口都要拦截。独立代理后台的登录逻辑写起来很长，但核心就两条：账号存在且状态正常，密码哈希校验通过。密码一定要用password_hash()，不要存 MD5 明文。

4.3 代理权限控制：菜单白名单加接口白名单

代理能看的页面和能调的接口要用白名单控制，不要用黑名单。黑名单是“除了这几个都允许”，新增接口时容易漏配，代理就能看到一个本不该看的页面。

常见做法是把代理菜单定义成一个路由表，每个路由对应一个控制器方法：

$agentMenus = [ 'dashboard' => ['label' => '数据概览', 'perm' => 'agent:dashboard'], 'member_list' => ['label' => '名下会员', 'perm' => 'agent:member:list'], 'order_list' => ['label' => '兑换订单', 'perm' => 'agent:order:list'], 'commission_list' => ['label' => '分佣明细', 'perm' => 'agent:commission:list'], 'goods_shelve' => ['label' => '上下架申请', 'perm' => 'agent:goods:shelve'], 'settlement' => ['label' => '结算提现', 'perm' => 'agent:settlement:apply'], ];

代理登录后把perm列表放进 session，在路由分发前做一次校验：

$currentPerm = $routeRule['perm'] ?? ''; if (!in_array($currentPerm, $_SESSION['agent_perms'], true)) { http_response_code(403); exit(json_encode(['code' => 403, 'msg' => '无权限访问'])); }

把权限校验做成一个统一的中间件函数，所有代理端控制器在方法第一行调用。不要把权限判断散落在各个方法内，否则漏改一处就是水平越权。权限表这里用了最简单的实现：代理等级写死菜单，顶级代理有全量权限，下级代理由平台在后台逐项勾选。如果代理数量上千，再考虑把perm列表抽到agent_permission表。

4.4 代理分佣：订单归属加幂等结算

独立代理后台的最终目的是分账。下单时订单表已经记录了agent_id，分佣要解决两个问题：按什么比例算，怎么保证不重复结算。

代理等级和分佣比例维护在agent_rate表，结算时按订单实际消耗的积分乘比例。注意商城没有真实金额流水，这里的分佣单位是积分。

CREATE TABLE `agent_rate` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `agent_id` int(11) NOT NULL, `level` tinyint(4) NOT NULL DEFAULT '1', `rate` decimal(5,4) NOT NULL DEFAULT '0.0000' COMMENT '分佣比例，如0.1000表示10%', PRIMARY KEY (`id`), UNIQUE KEY `uk_agent` (`agent_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='代理分佣比例表'; CREATE TABLE `agent_commission` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `agent_id` int(11) NOT NULL, `order_no` varchar(32) NOT NULL, `member_id` int(11) NOT NULL, `order_points` int(11) NOT NULL COMMENT '订单消耗积分', `commission_points` int(11) NOT NULL COMMENT '分佣积分', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0待结算 1已结算 2已驳回', `created_at` datetime DEFAULT NULL, `settled_at` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_agent_order` (`agent_id`, `order_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='代理分佣明细表';

分佣明细的生成放在每日结算脚本里，前一天已兑换的订单统一生成：

INSERT INTO agent_commission (agent_id, order_no, member_id, order_points, commission_points, status, created_at) SELECT o.agent_id, o.order_no, o.member_id, o.points, ROUND(o.points * r.rate), 0, NOW() FROM points_order o JOIN agent_rate r ON r.agent_id = o.agent_id WHERE o.status = 1 AND o.paid_at >= DATE_SUB(CURDATE(), INTERVAL 1 DAY) AND o.paid_at < CURDATE() AND NOT EXISTS ( SELECT 1 FROM agent_commission c WHERE c.order_no = o.order_no );

注意最后的NOT EXISTS子查询，这是幂等保证。结算脚本跑挂了，第二天重跑时不会重复插入同一条分佣。代理后台只显示agent_id等于当前登录代理的数据，在查询前用WHERE agent_id = :agent_id强过滤，不能只靠界面隐藏，不然代理改一下 URL 参数就能看别人的分佣明细。

分佣结算的下一个环节是代理提现，常见做法是只允许申请结算状态为“已结算”的积分，平台后台审核后把积分打款或充值到对应账号。提现申请一旦提交，明细状态改为“结算中”，避免重复提交。这块代码是独立的settlement模块，不在本文展开，但数据表一定要在第一天设计时留status字段，后面加提现审核流程不用改表。

5. 并发扣减、积分对账与上线巡检清单

最后一章讲三个上线前必须验证的点。积分系统的崩溃往往不是并发量多大，而是余额算错没人发现。给几个可以直接抄的对账方案。

5.1 三种并发扣减写法及适用场景

条件更新适合大多数积分商城源码建站的场景，简单可靠。如果做秒杀活动，先把积分预热到 Redis，用 Lua 脚本原子扣减，再把扣减消息丢进队列回写 MySQL。回写失败时以 Redis 扣减记录为准，第二天对账补平。

5.2 每日对账：账户余额与流水加总必须一致

对账脚本是积分系统最后一道防线。核心 SQL 是核对每个会员的当前余额等于历史流水之和：

SELECT a.member_id, a.points + a.frozen_points AS account_balance, COALESCE(SUM(t.change_points), 0) AS flow_balance FROM member_account a LEFT JOIN points_transaction t ON t.member_id = a.member_id GROUP BY a.member_id HAVING account_balance != flow_balance;

查询结果为空，说明所有会员的余额和流水一致；有结果，就把member_id打出来，走人工补偿。这个 SQL 放在每天凌晨 4 点跑，数据量上来后要加created_at分段扫描，不要一次全表 JOIN。

5.3 上线前黑盒巡检清单

最后给出上线前必须人工验证的 6 个场景，前 4 个是功能，后 2 个是数据安全。把每一项在测试库跑一遍再上线。

把第 6 项单独拿出来说，大部分所谓“源码成品”在这一点上都是裸奔的。检查方法很简单：浏览器登录代理后台，再开无痕窗口登录会员中心，然后回到代理后台操作，如果代理后台自动退出，说明 session 没隔离，要回第 4 章把session_name的改动补上。

巡检通过后再配置 Nginx 伪静态和 HTTPS，生产环境关闭 PHP 错误显示，把display_errors设为 Off，日志写到/var/log/php-fpm/error.log。积分商城源码到这一步，可以算是一个能运营的“完美版”了。

本文还有配套的精品资源，点击获取