PHP二手交易系统：订单状态机与RBAC权限实战

简介：这是一套基于PHP开发的二手商品交易平台仿站源码，面向Web全栈初学者与中小型项目开发者，提供从首页展示、商品发布到后台管理的完整电商功能闭环，可快速搭建类58转转、闲鱼风格的本地化二手交易网站。资源包共2000个文件，47.71MB，涵盖144个核心PHP业务逻辑文件、448个JS交互脚本、372个GIF动效与542个PNG图标素材，辅以194个JPG商品图示、130个CSS样式表及72个HTML页面模板，支撑起响应式前端与独立后台双端架构。已有2708人学习下载，说明其在实战教学与快速原型开发中具备较高参考价值。读者可直接部署运行，获得含商品CRUD、用户权限分级、订单流程模拟及基础SEO优化的可运行系统；预览可见H-ui系列UI框架与ueditor富文本组件集成，体现前后端协同设计思路，适合边学边练PHP+MySQL+前端三件套开发模式。

1. 这不是又一个“仿闲鱼”套壳站：它是一套可落地的二手交易最小闭环PHP系统，专治「想快速验证C端交易流程却卡在后台权限和订单状态机」的硬伤

你有没有试过：花三天搭好前端页面，结果卡在「用户发布商品后怎么进审核池」「买家付款后库存怎么锁」「退款申请触发哪些状态变更」上？市面上大量所谓“仿闲鱼源码”，实际是静态HTML+假后台，连数据库表结构都缺字段。而这份最新整理的PHP源码包，核心价值在于——它跑通了从商品发布、在线支付（模拟）、订单履约、售后工单到后台多角色审批的完整链路，且所有状态流转逻辑全部写死在Model层而非JS里。它不追求UI炫酷，但每个order_status字段都有明确的0:待付款 / 1:已付款 / 2:已发货 / 3:已完成 / -1:已取消 / -2:售后中枚举约束；每个后台操作按钮背后都绑定了真实权限校验（非前端隐藏）。适合两类人：一是需要交付型项目的PHP工程师，拿来改改就能嵌入现有系统；二是想吃透电商类Web应用状态管理逻辑的中级开发者。它不是教学Demo，是某公司内部用过的生产级脚手架压缩包。

---

2. 源码结构解剖：看清它到底“仿”了什么，又“没仿”什么——重点在业务模型而非UI皮囊

2.1 目录树与核心模块职责映射（基于实际解压后结构）

解压后主目录共12个一级文件夹，剔除/uploads（空）、/static（纯CSS/JS资源）后，真正承载业务逻辑的是以下5个：

├── app/ # MVC核心：Controllers + Models + Views（模板） │ ├── controllers/ # 共23个控制器，含AdminOrderController.php等 │ ├── models/ # 关键！17个Model，含GoodsModel.php、OrderModel.php、RefundModel.php │ └── views/ # Twig模板，无PHP混写，变量全用{{ }}包裹 ├── core/ # 框架内核：Router.php（路由分发）、Database.php（PDO封装）、Auth.php（RBAC权限基类） ├── public/ # Web根目录：index.php入口，.htaccess重写规则 ├── config/ # 四个PHP配置文件：database.php（DB连接）、auth.php（角色权限映射）、pay.php（支付网关开关）、upload.php（上传限制） └── admin/ # 独立后台入口：admin/index.php，与前台完全隔离路由

提示：这不是Laravel或ThinkPHP，而是自研轻量MVC。core/Router.php仅86行，靠$_SERVER['REQUEST_URI']正则匹配路由，不支持RESTful风格，但胜在调试时能直接var_dump($route)看到当前控制器方法——对排查404极友好。

2.2 数据库设计：为什么说它的order_status比90%的“仿品”更接近真实场景？

打开/sql/initial.sql（唯一SQL文件），重点看三张表：

表名	关键字段	设计亮点
goods	status TINYINT DEFAULT 1（1=上架, 0=下架, -1=审核中） audit_time DATETIME NULL	商品审核状态与时间分离，避免用is_audit布尔值导致无法追溯审核历史
orders	status TINYINT NOT NULL DEFAULT 0 pay_time DATETIME NULL ship_time DATETIME NULL finish_time DATETIME NULL	每个状态变更对应独立时间戳字段，而非只存update_time——这是做售后时效分析的基础
refund_requests	status ENUM('pending','approved','rejected','refunded') handler_id INT UNSIGNED handle_time DATETIME NULL	售后单有明确处理人ID和处理时间，且状态为字符串枚举（非数字），便于后期加日志审计

注意：orders.status未使用ENUM而用TINYINT，是因为代码中OrderModel::getStatusText()方法做了硬编码映射：

public static function getStatusText($status) { $map = [ 0 => '待付款', 1 => '已付款', 2 => '已发货', 3 => '已完成', -1 => '已取消', -2 => '售后中' ]; return $map[$status] ?? '未知'; }

这种写法牺牲了数据库层面约束，但换来PHP层灵活扩展（比如新增4=>'已评价'无需改表）。

2.3 后台权限体系：RBAC不是摆设，而是真正在admin/里跑起来的

/config/auth.php定义了4个角色：

return [ 'roles' => [ 'super_admin' => ['*'], // 通配符，拥有所有权限 'admin' => ['goods.view','goods.edit','orders.view','orders.ship'], 'auditor' => ['goods.audit','refund.view','refund.approve'], 'customer_service' => ['refund.view','refund.reply','orders.view'] ], 'permissions' => [ 'goods.view' => '查看商品列表', 'goods.edit' => '编辑商品信息', 'goods.audit' => '审核商品上架', 'orders.view' => '查看订单列表', 'orders.ship' => '标记订单发货', 'refund.view' => '查看售后申请', 'refund.approve'=> '批准退款', 'refund.reply' => '回复买家' ] ];

关键点在于：权限校验发生在Controller构造函数中，而非视图层判断。例如AdminOrderController.php第15行：

public function __construct() { parent::__construct(); $this->checkPermission('orders.view'); // ← 真实拦截，未授权直接跳转403页 }

血泪经验：很多“仿品”只在菜单栏用if($role=='admin')控制按钮显示，但URL仍可直击。而此源码的Auth::checkPermission()会读取当前登录用户的role字段，再查config/auth.php中的权限数组，最后调用$this->denyAccessIfNotGranted()抛出异常——这才是真RBAC。

---

3. 部署实操：从本地XAMPP到Nginx上线，三步走通关键路径

3.1 本地开发环境搭建（Windows/macOS通用）

前提：已安装PHP 7.4+、MySQL 5.7+、Apache/Nginx（推荐XAMPP或Docker）

1. 将源码解压至htdocs/secondhand/
2. 导入SQL：mysql -u root -p secondhand < htdocs/secondhand/sql/initial.sql
3. 修改数据库配置：编辑/config/database.php

return [ 'host' => 'localhost', 'dbname' => 'secondhand', // 必须与导入的库名一致 'username' => 'root', 'password' => '', // XAMPP默认为空 'charset' => 'utf8mb4' // 关键！必须设为utf8mb4，否则emoji商品标题会乱码 ];

4. 启动服务，访问http://localhost/secondhand/public/
   → 若见首页轮播图+商品列表，说明前台通
   → 访问http://localhost/secondhand/admin/，用默认账号admin/123456登录
   → 若进入后台仪表盘，说明权限与路由通
   
   
   

参数说明：/public/是Web根目录，.htaccess中RewriteBase /secondhand/public/确保子目录部署正常。若用Nginx，需在server块中添加：

location / { try_files $uri $uri/ /index.php?$query_string; }

3.2 支付流程模拟：为什么说它的“支付成功”不是alert弹窗？

该源码不对接真实支付网关，但实现了完整的支付状态机闭环：

1. 用户下单后，生成orders记录，status=0（待付款）
2. 点击“立即支付”，跳转至/pay/simulate?order_id=123
3. PayController::simulate()方法执行：
   • 校验订单是否存在且状态为0
   • 更新orders.status=1并写入pay_time=NOW()
   • 触发OrderService::afterPaid($order)（扣减库存、发通知等钩子）
4. 跳转回/order/detail/123，显示“已付款”状态

关键代码（app/controllers/PayController.php）：

public function simulate() { $orderId = (int)$_GET['order_id']; $order = OrderModel::find($orderId); if (!$order || $order['status'] != 0) { $this->redirect('/error?msg=订单状态异常'); // ← 严格校验，非简单跳转 } // 开启事务 Database::beginTransaction(); try { OrderModel::update($orderId, ['status' => 1, 'pay_time' => date('Y-m-d H:i:s')]); GoodsModel::decreaseStock($order['goods_id'], $order['quantity']); // 扣库存 Database::commit(); $this->redirect('/order/detail/' . $orderId); } catch (Exception $e) { Database::rollback(); $this->redirect('/error?msg=支付失败'); } }

逻辑说明：这里用了数据库事务（beginTransaction/commit/rollback），确保“更新订单状态”和“扣减库存”要么同时成功，要么同时失败。很多“仿品”直接UPDATE orders...; UPDATE goods...;，一旦第二条失败，订单已付款但库存未扣——这就是典型翻车现场。

3.3 后台多角色实测：用三个浏览器标签页验证权限隔离

按/config/auth.php定义的角色，创建测试账号：

角色	账号	可访问页面	不可访问操作
auditor	audit/123456	/admin/goods/audit（商品审核页）	点击“订单管理”菜单 → 403错误页
customer_service	cs/123456	/admin/refund/list（售后列表）	点击“商品管理”→ 403
admin	admin/123456	全部菜单	但无法点击“超级管理员”专属按钮（如清空日志）

验证技巧：在Chrome开三个隐身窗口，分别登录不同角色，然后尝试：

• auditor用户直接在地址栏输入http://localhost/secondhand/admin/orders/→ 返回403
• customer_service用户点击“商品管理”菜单 → 页面空白（因AdminGoodsController::__construct()中checkPermission('goods.view')拦截）
• super_admin用户可访问/admin/system/logs（日志页），其他角色无此权限项

---

4. 避坑指南：这5个坑我替你踩过了，省下至少两天debug时间

4.1 现象：前台商品图片上传后显示“上传失败”，但/uploads/goods/目录下有文件

原因：/config/upload.php中'max_size' => 2 * 1024 * 1024（2MB）与PHP.ini的upload_max_filesize不一致。若PHP.ini设为1M，则前端校验通过，但PHP底层拒绝接收。
解决：统一修改php.ini：

upload_max_filesize = 8M post_max_size = 10M

并重启Apache/Nginx。切记：upload.php中的max_size只是前端JS校验，真正起作用的是PHP.ini。

4.2 现象：后台登录后跳转到/admin/dashboard，但页面空白，控制台报Uncaught ReferenceError: Chart is not defined

原因：/admin/views/dashboard.twig中引用了<script src="/static/js/chart.min.js">，但源码包/static/js/目录下缺失该文件（原作者可能忘了打包）。
解决：下载 Chart.js v2.9.4 ，保存为/static/js/chart.min.js。注意必须用v2.x，因代码中new Chart(ctx, {...})语法不兼容v3。

4.3 现象：MySQL 8.0+环境下，登录后台报错SQLSTATE[HY000] [1045] Access denied for user 'root'@'localhost' (using password: YES)

原因：MySQL 8.0默认认证插件改为caching_sha2_password，而PHP 7.4的mysqlnd驱动不支持。
解决：在MySQL中执行：

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY ''; FLUSH PRIVILEGES;

注意：此操作降低安全性，仅限本地开发。生产环境应创建专用账号并指定插件。

4.4 现象：商品详情页显示“¥0.00”，但数据库中goods.price字段值为99.9

原因：app/models/GoodsModel.php中getPriceText()方法错误地将价格乘以100：

// 错误代码（原始包存在此bug） public function getPriceText() { return '¥' . number_format($this->price * 100, 2); // ← 多乘了100！ }

解决：改为

public function getPriceText() { return '¥' . number_format($this->price, 2); // 直接格式化 }

4.5 现象：Nginx部署后，访问/admin/返回404，但前台/public/正常

原因：Nginx未配置admin/子目录的独立location。/admin/index.php需要被当作入口文件处理。
解决：在Nginx server块中添加：

location ^~ /admin/ { alias /path/to/secondhand/admin/; index index.php; try_files $uri $uri/ /admin/index.php?$query_string; } location ~ ^/admin/.*\.php$ { alias /path/to/secondhand/admin/; fastcgi_pass 127.0.0.1:9000; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $request_filename; }

关键点：alias末尾必须有/，且SCRIPT_FILENAME必须用$request_filename而非$document_root$fastcgi_script_name，否则PHP找不到index.php。

---

5. 进阶改造：把“可运行”变成“可交付”——三个必改项与一个后悔药机制

5.1 必改项一：替换硬编码的支付网关为真实对接（以支付宝沙箱为例）

源码中支付逻辑集中在app/controllers/PayController.php的simulate()方法。要接入支付宝，需：

1. 下载 支付宝SDK for PHP ，放入/vendor/目录
2. 创建/config/alipay.php：

return [ 'app_id' => '2021000123456789', 'merchant_private_key' => '-----BEGIN RSA PRIVATE KEY-----...', 'alipay_public_key' => '-----BEGIN ALIPAY PUBLIC KEY-----...', 'notify_url' => 'http://yoursite.com/pay/notify', 'return_url' => 'http://yoursite.com/pay/return' ];

3. 改写PayController::createOrder()（原simulate的前置方法）：

public function createOrder() { $order = OrderModel::create($_POST); // 原逻辑 // ↓ 新增：调用支付宝SDK生成支付链接 $aop = new AopClient(); $aop->gatewayUrl = 'https://openapi.alipaydev.com/gateway.do'; $aop->appId = config('alipay.app_id'); $aop->rsaPrivateKey = config('alipay.merchant_private_key'); $aop->alipayPublicKey = config('alipay.alipay_public_key'); $request = new AlipayTradePagePayRequest(); $request->setNotifyUrl(config('alipay.notify_url')); $request->setReturnUrl(config('alipay.return_url')); $request->setBizContent(json_encode([ 'out_trade_no' => $order['order_no'], 'product_code' => 'FAST_INSTANT_TRADE_PAY', 'total_amount' => $order['total_price'], 'subject' => '二手商品购买' ])); $result = $aop->pageExecute($request); echo $result; // 输出支付宝支付页 }

参数说明：out_trade_no必须全局唯一，建议用date('ymd').str_pad(mt_rand(1,99999),5,'0',STR_PAD_LEFT)生成；total_amount必须是字符串类型（SDK要求），不能传float。

5.2 必改项二：订单状态机增强——加入超时自动关单

当前源码无订单超时逻辑。生产环境必须添加，否则“待付款”订单永久堆积。方案：用MySQL事件（Event）：

-- 创建事件，每5分钟检查一次 CREATE EVENT auto_close_order ON SCHEDULE EVERY 5 MINUTE DO UPDATE orders SET status = -1, close_time = NOW() WHERE status = 0 AND create_time < DATE_SUB(NOW(), INTERVAL 30 MINUTE);

注意：需开启MySQL事件调度器：SET GLOBAL event_scheduler = ON;。并在/config/database.php中确保'persistent' => false，避免长连接干扰。

5.3 必改项三：后台日志审计——记录谁在何时操作了什么

/admin/目前无操作日志。补全步骤：

1. 新建表admin_logs：

CREATE TABLE `admin_logs` ( `id` int(11) NOT NULL AUTO_INCREMENT, `admin_id` int(11) NOT NULL, `action` varchar(100) NOT NULL COMMENT 'goods.edit, order.ship等', `target_id` int(11) DEFAULT NULL COMMENT '被操作的goods_id/order_id', `ip` varchar(45) NOT NULL, `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `admin_id` (`admin_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

2. 在core/Auth.php的login()方法末尾添加：

// 记录登录日志 Database::insert('admin_logs', [ 'admin_id' => $user['id'], 'action' => 'login', 'ip' => $_SERVER['REMOTE_ADDR'] ]);

3. 在所有Admin*Controller的修改方法中（如AdminGoodsController::update()），插入：

Database::insert('admin_logs', [ 'admin_id' => $_SESSION['admin_id'], 'action' => 'goods.edit', 'target_id' => $id, 'ip' => $_SERVER['REMOTE_ADDR'] ]);

5.4 后悔药机制：数据库误操作后的快速回滚方案

当运营人员在后台误删商品或错改订单状态，最怕的是没有备份。我在某项目中强制推行的“后悔药”流程：

1. 每日凌晨2点自动备份（Linux crontab）：

# 编辑 crontab -e 0 2 * * * /usr/bin/mysqldump -u root -p'yourpass' secondhand > /backup/secondhand_$(date +\%Y\%m\%d).sql

2. 关键操作前二次确认+快照：
   修改app/controllers/AdminGoodsController.php的delete()方法：

public function delete() { $id = (int)$_GET['id']; // ← 新增：创建删除前快照 $goods = GoodsModel::find($id); Database::insert('goods_snapshots', [ 'goods_id' => $id, 'snapshot_data' => json_encode($goods), 'operator_id' => $_SESSION['admin_id'], 'created_at' => date('Y-m-d H:i:s') ]); // 原删除逻辑... GoodsModel::delete($id); }

3. 后台增加“快照恢复”按钮：在/admin/goods/snapshots页列出所有快照，点击即可还原单条商品数据。

从那以后我每次上线新后台功能，都强制走一遍“模拟误操作→查快照表→点恢复”的全流程。不是信不过自己写的代码，而是信不过人类在凌晨三点改生产库时的手抖。希望帮到你。

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