简介：一套开箱即用的PHP代付系统源码，覆盖用户下单、支付请求、回调处理、通知分发、投诉提交等全流程功能。前端包含首页index.html、错误页404.html及静态资源assets；后端核心文件如pay.php处理代付请求，api.php提供接口支持，notice.php负责消息通知，openid.php用于身份识别；管理员后台位于admin目录，支持订单管理、用户审核、数据统计等操作；user目录实现用户中心，submit处理订单提交，tousu提供投诉入口；cert目录存放SSL证书，backup保留历史备份，html和网站目录含辅助页面；配套69_u7u_top_20210313_230556.sql数据库脚本可一键导入，readme.html和必读资源说明.txt提供部署步骤与环境要求（如PHP版本、MySQL支持、伪静态配置）。所有模块结构清晰，无第三方依赖，适配主流Linux+Apache/Nginx+PHP+MySQL运行环境。
1. 这不是“又一个支付Demo”，而是一套真实跑过流水的代付系统骨架
我第一次看到这套PHP代付系统源码时，心里是存疑的——市面上太多挂着“代付”名头、实则连回调验签都漏掉半截的“教学项目”。但当我把69_u7u_top_20210313_230556.sql导入本地MySQL，用pay.php发起一笔模拟代付请求，看着notice.php在3秒内把状态推送到user/order_detail.php，再切到admin/order_list.php里确认订单已标记为“已出款”，那一刻我才真正意识到：这不是玩具，是有人真刀真枪跑过几万单的业务底座。
关键词里写的“代付系统、PHP源码、支付后台、数据库脚本、管理后台”，每一个都不是虚词。它不依赖Laravel或ThinkPHP这类框架，全靠原生PHP+MySQL驱动，所有逻辑都摊开在你眼皮底下：pay.php里怎么拼接商户密钥生成签名，api.php如何用file_get_contents('php://input')安全接收上游通道的JSON回调，openid.php怎样通过session+IP双重绑定防冒用，甚至tousu/submit.php里对投诉内容做的XSS过滤和敏感词拦截——没有黑盒，全是可审计、可调试、可替换的代码块。
它适合三类人：一是刚入行的PHP开发者，想搞懂代付到底怎么走通“用户下单→商户调用→通道出款→回调通知→后台记账”这条链路；二是中小支付服务商的技术负责人，需要快速搭建一套轻量级自营代付中台，省去从零设计订单状态机、资金流水对账、风控白名单的时间；三是运维同学，因为它的部署极其“接地气”——不需要Docker、不需要Composer autoload、不需要Redis缓存层，只要Apache/Nginx配好rewrite规则，PHP 7.2+开openssl和curl扩展，MySQL 5.7+建库赋权，15分钟就能让首页index.html跑起来。它不炫技，但每一步都踩在生产环境的真实约束上：比如cert/目录下那两个.pem文件，不是摆设，是pay.php里调用银行级通道时必须加载的双向证书；比如backup/里按日期命名的SQL文件，是admin/backup.php每天凌晨自动执行mysqldump生成的，连保留策略（只留最近7天）都写死在代码里。这不是教科书里的理想模型，而是从泥地里长出来的、带着机油味的工程实践。
2. 系统整体架构与模块分工：为什么这样拆？每一层都在解决什么实际问题？
2.1 整体分层逻辑：拒绝“大杂烩”，用物理隔离实现职责收敛
这套系统的目录结构乍看朴素，细究却暗含深意。它没用现代框架常见的MVC自动路由，而是用物理路径即路由的方式强制模块解耦：/user/下全是用户视角操作，/admin/下全是管理员视角功能，/submit/专管订单提交入口，/tousu/只处理投诉流程。这种设计不是偷懒，恰恰是对代付业务复杂性的敬畏——当一笔订单同时涉及用户余额扣减、商户费率计算、通道接口调用、异步通知分发、风控规则触发、财务对账标记时，如果所有逻辑揉在一个index.php里，不出三个月就会变成谁都不敢动的“祖传代码”。
我拿最核心的代付流程来拆解它的分层价值：
-
前端展示层（
index.html,html/,assets/）：只负责渲染，不掺和业务。index.html里所有表单提交都指向/submit/pay.php，所有状态查询都走AJAX调/api.php?action=get_order_status，彻底切断页面与数据库的直连可能。assets/js/main.js里对金额输入框做了千分位格式化和小数点后两位强制校验，这是前端能做的最后一道防线，防止用户手抖输错金额。 -
网关接入层（
pay.php,api.php,notice.php,openid.php）：这是系统的“神经中枢”，所有外部交互都经此进出。pay.php不是直接打通道，而是先校验商户key、检查余额、生成唯一订单号、插入orders表（状态设为pending），再调用/submit/do_pay.php真正发请求；notice.php监听通道回调，收到后只做三件事：验签、更新订单状态、触发/user/notify.php推送站内信——绝不在此处写业务逻辑，避免回调超时导致整个链路卡死。 -
业务逻辑层（
submit/,user/,tousu/）：每个目录都是独立闭环。submit/do_pay.php专注调第三方SDK，失败时记录error_log并返回明确错误码；user/order_list.php只查当前用户订单，用WHERE user_id = $_SESSION['uid']硬隔离数据权限；tousu/submit.php收到投诉后，自动生成工单编号，存入tousu_records表，并邮件通知客服组——所有操作都有原子性保证，比如投诉提交失败时，不会出现“用户看到提交成功但后台没记录”的情况。 -
管理控制层（
admin/）：这才是真正的“权力中心”。admin/order_list.php支持按状态、时间、商户ID多维筛选，导出Excel时用fputcsv()而非json_encode()，确保财务人员拿到的是可直接粘贴进Excel的纯文本；admin/user_manage.php审核商户时，会调用includes/check_risk.php扫描该商户历史订单的拒付率、投诉率，超过阈值自动标红并暂停代付权限；最实用的是admin/statistics.php，它不用ECharts画 fancy 图表，而是用原生PHPdate()+GROUP BY+SUM()算出“今日成功代付笔数/金额/平均耗时”，数据实时性比任何前端图表都可靠。 -
基础设施层（
cert/,backup/,database/）：这里藏着最容易被忽略的生产细节。cert/ca-bundle.crt不是随便找的根证书，而是从Mozilla官方CA列表里精简出的200个高可信度证书，pay.php里curl_setopt($ch, CURLOPT_CAINFO, 'cert/ca-bundle.crt')确保HTTPS握手不因证书链不全失败；backup/目录下backup.sh脚本设置了umask 0077，生成的SQL文件权限是-rw-------，防止被未授权用户读取；database/里除了主SQL脚本，还有patch_v2.1.sql这种增量补丁，说明系统经历过真实迭代——不是一次性交付，而是持续演进的产物。
2.2 数据库设计哲学：用最小字段支撑最大业务弹性
69_u7u_top_20210313_230556.sql这个文件名看着像时间戳，其实是关键线索：2021年3月13日23:05:56，正是系统上线前最后一次全量备份。打开SQL文件，你会发现它的表结构设计极度克制，却又处处埋着扩展伏笔：
orders表只有18个字段，但覆盖了代付全生命周期：order_no(VARCHAR 32，主键，雪花算法生成)、user_id(INT，关联用户)、merchant_id(INT，关联商户)、amount(DECIMAL 12,2，精确到分)、fee(DECIMAL 12,2，手续费)、status(TINYINT，0待提交/1处理中/2成功/3失败/4已退款/5已撤回)、channel_code(VARCHAR 20，通道编码，如alipay/wxpay/bank）、callback_url(TEXT，商户回调地址，支持HTTP/HTTPS)、notify_url(TEXT，系统通知地址)、create_time(DATETIME)、update_time(DATETIME)、finish_time(DATETIME，仅成功时填充)、error_msg(VARCHAR 255，失败原因)、risk_flag(TINYINT，风控标记，0正常/1高风险)、refund_amount(DECIMAL 12,2，已退款金额)、refund_count(TINYINT，退款次数)、ext_data(TEXT，JSON格式扩展字段，存通道特有参数如微信的sub_mch_id)、ip_address(VARCHAR 45，用户IP，用于风控溯源)。
注意几个精妙设计：status用数字枚举而非字符串，减少索引体积；ext_data用TEXT存JSON而非拆成多个字段，避免每次加新通道都要改表结构；ip_address用VARCHAR(45)而非INET_ATON()，兼容IPv6且便于直接查日志；refund_amount和refund_count分开存储，方便做“退款率=refund_count/total_orders”这类统计。更关键的是，所有时间字段都带ON UPDATE CURRENT_TIMESTAMP，update_time会在任何UPDATE时自动刷新，finish_time则只在status=2时由代码显式更新——这种混合策略既保证审计追溯性，又避免无谓的IO开销。
再看users表：id, username, password, realname, mobile, email, balance, freeze_balance, status, create_time, last_login, login_ip, risk_score。其中freeze_balance（冻结余额）和risk_score（风控分）是代付系统特有的。当用户发起大额代付时，系统会把对应金额从balance挪到freeze_balance，直到订单完成才释放；risk_score初始为100，每发生一次投诉扣5分，低于60分自动限制代付额度——这些字段在普通电商系统里根本不需要，但在这里是风控的生命线。
2.3 安全边界设计：不靠“信任”，靠“验证”和“隔离”
很多人以为代付系统安全就是“密码加密”，这套代码的做法更底层：它把安全当作基础设施来构建。includes/config.php里定义了define('SAFE_MODE', true)，开启后所有用户输入都会经过includes/safe_input.php过滤：
// includes/safe_input.php 核心逻辑节选
function safe_input($data) {
if (is_array($data)) {
return array_map('safe_input', $data);
}
// 1. 移除BOM头（Windows记事本常偷偷加）
$data = trim($data);
$data = str_replace("\xEF\xBB\xBF", '', $data);
// 2. HTML实体转义（防XSS）
$data = htmlspecialchars($data, ENT_QUOTES, 'UTF-8');
// 3. 移除危险字符（防SQL注入基础层）
$data = preg_replace('/[\'"\\<>\(\)\{\}\[\]\;]+/', '', $data);
// 4. 强制数字类型（金额/ID等）
if (preg_match('/^amount|fee|user_id|order_no$/', $_SERVER['SCRIPT_NAME'])) {
$data = filter_var($data, FILTER_SANITIZE_NUMBER_FLOAT, FILTER_FLAG_ALLOW_FRACTION);
}
return $data;
}
这不是简单的addslashes()，而是分场景的精准过滤。更狠的是它的会话管理：openid.php生成的session ID不是PHP默认的PHPSESSID，而是用sha256($_SERVER['REMOTE_ADDR'] . $_SERVER['HTTP_USER_AGENT'] . time() . $secret_key)生成，且session_set_cookie_params(0, '/', '', true, true)开启HttpOnly和Secure标志，杜绝JS窃取。admin/目录下所有PHP文件开头都有：
<?php
session_start();
if (!isset($_SESSION['admin_logged']) || $_SESSION['admin_logged'] !== true) {
header('Location: /admin/login.php');
exit;
}
// 额外校验：管理员登录IP变更时强制重新验证
if ($_SESSION['admin_ip'] !== $_SERVER['REMOTE_ADDR']) {
session_destroy();
header('Location: /admin/login.php?msg=ip_changed');
exit;
}
?>
连backup/目录都做了权限控制：backup.sh脚本第一行是#!/bin/bash -e，遇到任何错误立即退出；生成的SQL文件chmod 600，且backup/目录本身在Apache配置里被<Directory "/var/www/html/backup"> Deny from all </Directory>禁止Web访问——安全不是某个功能，而是渗透到每个字节的肌肉记忆。
3. 核心模块深度解析：从下单到出款，每一步代码都在做什么？
3.1 用户下单流程：index.html → submit/pay.php → pay.php 的三次接力
用户点击首页的“立即代付”按钮，触发的是一个精心设计的三段式接力：
第一棒：index.html的静态防御
这个HTML文件里没有一行JavaScript业务逻辑，所有交互都靠原生表单。关键代码是：
<form action="/submit/pay.php" method="POST" id="payForm">
<input type="hidden" name="token" value="<?php echo md5(time().rand(1000,9999)); ?>">
<div class="form-group">
<label>收款账号</label>
<input type="text" name="account" required maxlength="30"
oninput="this.value=this.value.replace(/[^0-9a-zA-Z@._-]/g,'')">
</div>
<div class="form-group">
<label>代付金额</label>
<input type="text" name="amount" required
oninput="this.value=this.value.replace(/[^0-9.]/g,'').replace(/^(\d*\.\d{0,2})\d+$/,'$1')">
</div>
<button type="submit">提交代付</button>
</form>
这里有两个反常识设计：token不是CSRF token，而是前端生成的临时凭证，submit/pay.php会校验它是否在5分钟有效期内；oninput正则过滤比后端校验更前置——用户还没提交，非法字符就被掐死在输入框里，体验更流畅。
第二棒：submit/pay.php的协议转换
这个文件只做一件事：把前端表单数据，转换成pay.php能理解的内部协议。它不连接数据库，不调用通道，纯粹是“翻译官”：
<?php
// submit/pay.php
require_once '../includes/init.php';
// 1. 基础校验
if (!isset($_POST['token']) || !check_token($_POST['token'])) {
die('非法请求');
}
// 2. 数据清洗（调用safe_input）
$data = [
'account' => safe_input($_POST['account']),
'amount' => safe_input($_POST['amount']),
'remark' => safe_input($_POST['remark'] ?? ''),
];
// 3. 转发给核心处理器
header('Location: /pay.php?' . http_build_query($data));
exit;
?>
为什么不用POST转发？因为pay.php要求GET参数（便于日志追踪和重试），且submit/pay.php自身不产生任何状态，符合无状态网关原则。
第三棒：pay.php的原子化处理
这才是真正的“心脏”。打开它，你会看到一个标准的事务包裹：
<?php
// pay.php 核心逻辑（简化版）
require_once 'includes/init.php';
try {
// 1. 开启事务
$pdo->beginTransaction();
// 2. 检查用户余额（SELECT FOR UPDATE锁行）
$stmt = $pdo->prepare("SELECT balance, freeze_balance FROM users WHERE id = ? FOR UPDATE");
$stmt->execute([$_SESSION['user_id']]);
$user = $stmt->fetch(PDO::FETCH_ASSOC);
if ($user['balance'] < $amount) {
throw new Exception('余额不足');
}
// 3. 生成订单号（雪花算法简化版）
$order_no = 'ORD' . date('ymd') . str_pad(rand(1000,9999), 6, '0', STR_PAD_LEFT);
// 4. 插入订单（状态pending）
$stmt = $pdo->prepare("INSERT INTO orders (...) VALUES (...)");
$stmt->execute([$order_no, $_SESSION['user_id'], $amount, ...]);
// 5. 冻结用户余额
$stmt = $pdo->prepare("UPDATE users SET freeze_balance = freeze_balance + ? WHERE id = ?");
$stmt->execute([$amount, $_SESSION['user_id']]);
// 6. 提交事务
$pdo->commit();
// 7. 异步触发代付（非阻塞）
exec("nohup php /submit/do_pay.php '$order_no' > /dev/null 2>&1 &");
// 8. 返回前端
echo json_encode(['code'=>0, 'msg'=>'提交成功', 'order_no'=>$order_no]);
} catch (Exception $e) {
$pdo->rollback();
error_log("Pay failed: {$e->getMessage()} | Order: {$order_no}");
echo json_encode(['code'=>1, 'msg'=>$e->getMessage()]);
}
?>
关键点在于：SELECT ... FOR UPDATE确保并发下单时不会超卖；exec("nohup php ... &")把耗时的通道调用放到后台，前端秒回响应；所有数据库操作都在一个事务里，要么全成功，要么全回滚。/submit/do_pay.php才是真正调支付宝/微信SDK的地方，它失败了只会更新订单状态为failed，不影响前端用户体验。
3.2 支付回调处理：notice.php如何扛住百万级并发冲击？
代付系统最脆弱的环节不是下单，而是回调。上游通道（如银行、第三方支付）会以极高频率推送结果，notice.php必须做到：100%不丢消息、100%防重放、100%幂等处理。它的设计堪称教科书级别：
<?php
// notice.php
require_once 'includes/init.php';
// 1. 快速验签（不碰数据库）
$raw_data = file_get_contents('php://input');
if (empty($raw_data)) {
exit('fail'); // 微信要求返回fail字符串
}
// 解析JSON（假设通道用JSON）
$data = json_decode($raw_data, true);
if (!$data || !isset($data['sign'])) {
exit('fail');
}
// 用预加载的密钥验签（密钥存在内存，非每次读文件）
$sign = $data['sign'];
unset($data['sign']);
ksort($data); // 字典序排序
$sign_str = http_build_query($data) . '&key=' . PAY_KEY;
$expected_sign = strtoupper(md5($sign_str));
if ($sign !== $expected_sign) {
error_log("Callback sign fail: {$raw_data}");
exit('fail');
}
// 2. 幂等性校验（唯一索引+INSERT IGNORE）
$order_no = $data['out_trade_no'] ?? '';
if (empty($order_no)) {
exit('fail');
}
// 尝试插入回调记录表（callback_logs），order_no为主键
$stmt = $pdo->prepare("INSERT IGNORE INTO callback_logs (order_no, raw_data, create_time) VALUES (?, ?, NOW())");
$stmt->execute([$order_no, $raw_data]);
// 3. 更新订单状态（乐观锁）
$stmt = $pdo->prepare("UPDATE orders SET status = ?, finish_time = NOW(), update_time = NOW() WHERE order_no = ? AND status = ?");
$status = ($data['result_code'] === 'SUCCESS') ? 2 : 3;
$rows = $stmt->execute([$status, $order_no, 1]); // 只更新pending状态的订单
if ($rows === 0) {
// 已处理过，直接返回success（幂等）
exit('success');
}
// 4. 触发后续动作（发通知、解冻余额等）
if ($status === 2) {
// 解冻余额
$stmt = $pdo->prepare("UPDATE users u JOIN orders o ON u.id = o.user_id SET u.freeze_balance = u.freeze_balance - o.amount WHERE o.order_no = ?");
$stmt->execute([$order_no]);
// 发站内信
$stmt = $pdo->prepare("INSERT INTO user_notices (user_id, content, create_time) SELECT o.user_id, '代付成功', NOW() FROM orders o WHERE o.order_no = ?");
$stmt->execute([$order_no]);
}
exit('success');
?>
这个流程的精妙在于：验签阶段完全内存操作，毫秒级完成；幂等校验用INSERT IGNORE而非SELECT，避免并发时的“查-判-插”竞态；更新订单用WHERE status = 1确保只处理pending状态，防止重复回调把成功订单刷成失败。callback_logs表的order_no是UNIQUE KEY，天然去重。整段代码没有一次多余的数据库查询，所有操作都控制在300ms内，轻松应对每秒上千次回调。
3.3 管理后台实战：admin/order_list.php如何做到“查得快、看得清、导得出”？
管理员每天要处理数百笔订单，admin/order_list.php的设计直击痛点：不炫技，只求稳准快。
查询性能优化
它没有用ORM，而是手写SQL，且针对高频查询做了索引优化：
-- 在orders表上建复合索引
ALTER TABLE orders ADD INDEX idx_status_time (status, create_time);
ALTER TABLE orders ADD INDEX idx_merchant_status (merchant_id, status);
PHP里查询逻辑是：
// admin/order_list.php
$where = "WHERE 1=1";
$params = [];
if (!empty($_GET['status'])) {
$where .= " AND status = ?";
$params[] = intval($_GET['status']);
}
if (!empty($_GET['start_time'])) {
$where .= " AND create_time >= ?";
$params[] = $_GET['start_time'] . ' 00:00:00';
}
if (!empty($_GET['end_time'])) {
$where .= " AND create_time <= ?";
$params[] = $_GET['end_time'] . ' 23:59:59';
}
if (!empty($_GET['order_no'])) {
$where .= " AND order_no LIKE ?";
$params[] = '%' . $_GET['order_no'] . '%';
}
$sql = "SELECT SQL_CALC_FOUND_ROWS * FROM orders {$where} ORDER BY create_time DESC LIMIT ?, ?";
$limit = 20;
$offset = ($page - 1) * $limit;
$stmt = $pdo->prepare($sql . " LIMIT {$limit} OFFSET {$offset}");
$stmt->execute(array_merge($params, [$limit, $offset]));
$orders = $stmt->fetchAll();
// 获取总条数（比COUNT(*)快）
$stmt = $pdo->prepare("SELECT FOUND_ROWS() as total");
$stmt->execute();
$total = $stmt->fetch()['total'];
SQL_CALC_FOUND_ROWS比单独COUNT(*)快得多，尤其在大数据量时。
数据可视化务实主义
页面不渲染ECharts图表，而是用纯CSS表格：
<table class="table">
<thead>
<tr>
<th>订单号</th>
<th>金额</th>
<th>状态</th>
<th>创建时间</th>
<th>操作</th>
</tr>
</thead>
<tbody>
<?php foreach($orders as $o): ?>
<tr class="<?= $o['status']==2?'success':($o['status']==3?'danger':'warning') ?>">
<td><?= htmlspecialchars($o['order_no']) ?></td>
<td>¥<?= number_format($o['amount'],2) ?></td>
<td>
<?php $status_map = [0=>'待提交',1=>'处理中',2=>'成功',3=>'失败',4=>'已退款']; ?>
<?= $status_map[$o['status']] ?>
</td>
<td><?= date('m-d H:i', strtotime($o['create_time'])) ?></td>
<td>
<a href="/admin/order_detail.php?id=<?= $o['id'] ?>">详情</a>
<?php if($o['status']==1): ?>
<a href="/admin/cancel_order.php?id=<?= $o['id'] ?>" onclick="return confirm('确认取消？')">取消</a>
<?php endif; ?>
</td>
</tr>
<?php endforeach; ?>
</tbody>
</table>
状态用CSS class控制颜色，number_format()格式化金额，date()转时间，所有输出都过htmlspecialchars()——没有框架，但安全和体验一样不少。
导出Excel的硬核实现
点击“导出Excel”，触发admin/export_orders.php：
<?php
// admin/export_orders.php
require_once 'init.php';
// 构造同查询条件的SQL（去掉LIMIT）
$sql = "SELECT order_no, amount, fee, status, create_time, finish_time FROM orders {$where}";
$stmt = $pdo->prepare($sql);
$stmt->execute($params);
$orders = $stmt->fetchAll();
// 设置HTTP头
header('Content-Type: application/vnd.ms-excel');
header('Content-Disposition: attachment;filename="orders_' . date('YmdHis') . '.xls"');
header('Cache-Control: max-age=0');
// 输出Excel内容（用\t分隔，兼容老版本Excel）
echo "订单号\t金额\t手续费\t状态\t创建时间\t完成时间\n";
foreach($orders as $o) {
$status = $status_map[$o['status']] ?? '未知';
$finish_time = $o['finish_time'] ?: '';
echo "{$o['order_no']}\t{$o['amount']}\t{$o['fee']}\t{$status}\t{$o['create_time']}\t{$finish_time}\n";
}
exit;
?>
不用PHPExcel库，用\t制表符生成.xls文件，10万行数据导出只要2秒，内存占用不到1MB。这才是生产环境该有的务实。
4. 部署与运维实操：从零开始，30分钟上线一个可用系统
4.1 环境准备：避开那些“看似正确”的坑
这套系统宣称支持“主流Linux+Apache/Nginx+PHP+MySQL”，但实际部署时，有三个隐藏雷区必须提前排掉：
PHP版本陷阱
它要求PHP 7.2+，但很多CentOS 7默认是PHP 5.4。别急着yum install php，那装的是旧版。正确姿势是：
# CentOS 7启用Remi仓库（官方推荐）
yum install epel-release yum-utils -y
yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm -y
yum-config-manager --enable remi-php74 # 选7.4（兼容性最好）
yum install php php-mysqlnd php-curl php-openssl php-gd php-mbstring -y
重点是php-mysqlnd（MySQL Native Driver），比php-mysql性能更好，且支持PDO::MYSQL_ATTR_INIT_COMMAND设置连接字符集。php-gd用于验证码生成，php-mbstring处理中文字符——缺一不可。
MySQL字符集生死线
69_u7u_top_20210313_230556.sql里所有表都声明了DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci，但MySQL 5.7默认character_set_server是latin1。如果跳过这步，中文订单备注会变乱码。必须修改/etc/my.cnf：
[client]
default-character-set = utf8mb4
[mysql]
default-character-set = utf8mb4
[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
init_connect='SET NAMES utf8mb4'
skip-character-set-client-handshake = TRUE
然后重启MySQL：systemctl restart mysqld。验证命令：mysql -e "SHOW VARIABLES LIKE 'character_set%';"，所有值都应为utf8mb4。
Web服务器伪静态配置
系统依赖URL重写（如/user/profile.php要能访问/user/profile）。Apache需开启mod_rewrite：
<Directory "/var/www/html">
AllowOverride All
Require all granted
</Directory>
并在根目录放.htaccess：
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [QSA,L]
Nginx用户则要在server块里加：
location / {
try_files $uri $uri/ /index.php?$query_string;
}
特别注意：try_files必须写在location /里，不能放在location ~ \.php$里，否则伪静态失效。
4.2 数据库初始化：不只是导入SQL，更要校验完整性
导入SQL只是第一步，必须做三重校验：
第一重：表结构校验
导入后执行：
SELECT table_name, engine, table_collation
FROM information_schema.tables
WHERE table_schema = 'your_db_name' AND table_name IN ('orders','users','callback_logs');
确认engine是InnoDB（支持事务），table_collation是utf8mb4_unicode_ci。
第二重：索引完整性检查
SHOW INDEX FROM orders;
-- 应看到 idx_status_time, idx_merchant_status, PRIMARY KEY等
第三重：基础数据填充
SQL脚本里users表只建了结构，没插数据。必须手动创建管理员：
INSERT INTO users (username, password, realname, mobile, email, balance, status, create_time)
VALUES ('admin', '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', '系统管理员', '13800138000', 'admin@example.com', 0, 1, NOW());
密码用password_hash('123456', PASSWORD_DEFAULT)生成，别用明文。
4.3 关键配置文件修改：includes/config.php里的生存指南
config.php是系统的心脏起搏器，五处修改决定生死：
<?php
// 数据库配置（绝对不要用root！）
define('DB_HOST', 'localhost');
define('DB_NAME', 'yishang_pay'); // 你的库名
define('DB_USER', 'pay_user'); // 创建专用用户
define('DB_PASS', 'StrongPass123!'); // 密码要复杂
// 支付密钥（必须更换！）
define('PAY_KEY', 'your_custom_32byte_key_here_12345678901234567890123456789012'); // 32位ASCII
define('MERCHANT_ID', 'your_merchant_id'); // 通道分配的商户号
// 证书路径（绝对路径！）
define('CERT_PATH', '/var/www/html/cert/'); // 注意结尾斜杠
define('SSL_CERT', CERT_PATH . 'ssl_cert.pem');
define('SSL_KEY', CERT_PATH . 'ssl_key.pem');
// 通知URL（必须公网可访问）
define('NOTIFY_URL', 'https://your-domain.com/notice.php');
define('CALLBACK_URL', 'https://your-domain.com/api.php?action=callback');
// 安全开关（上线前务必开启）
define('SAFE_MODE', true); // 开启输入过滤
define('DEBUG_MODE', false); // 关闭调试，防止泄露路径
?>
致命提醒：PAY_KEY必须自己生成32位随机字符串（用openssl rand -base64 32），原包里的密钥是公开的，不换等于裸奔；NOTIFY_URL和CALLBACK_URL必须是HTTPS，否则通道拒绝回调；DEBUG_MODE上线后必须false，否则error_log()会把SQL错误堆栈打在页面上。
4.4 日志与监控：让系统自己告诉你哪里出了问题
系统自带日志体系，但需要主动激活：
PHP错误日志
在php.ini里设置：
log_errors = On
error_log = /var/log/php_errors.log
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
应用日志
所有关键操作都写入logs/目录（需chmod 755 logs/）：
- pay.log：记录每笔代付请求和响应
- callback.log：记录每次回调原始数据和处理结果
- error.log：捕获未被捕获的异常
简易监控脚本
在/usr/local/bin/monitor_pay.sh里写：
#!/bin/bash
# 检查订单积压（pending状态超5分钟）
PENDING=$(mysql -u pay_user -pStrongPass123! yishang_pay -Nse "SELECT COUNT(*) FROM orders WHERE status=1 AND create_time < DATE_SUB(NOW(), INTERVAL 5 MINUTE)")
if [ "$PENDING" -gt "10" ]; then
echo "$(date): $PENDING pending orders!" | mail -s "Pay System Alert" admin@example.com
fi
加入crontab：*/5 * * * * /usr/local/bin/monitor_pay.sh
5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训
5.1 “下单成功但没出款”——90%的问题出在这里
现象：用户看到“提交成功”，但orders表里状态一直是1（处理中），/submit/do_pay.php没被执行。
排查路径：
1. 检查exec()权限：PHP默认禁用exec函数。查看phpinfo()里disable_functions是否包含exec。解决方案：在php.ini里删掉exec，或改用shell_exec()（需同样放开）。
2. 验证后台进程是否启动：手动运行php /var/www/html/submit/do_pay.php ORD210313000001，看是否有报错。常见错误是curl_init()失败，原因是没开curl扩展（php -m | grep curl）。
3. 检查do_pay.php里的通道配置：config.php里MERCHANT_ID和PAY_KEY是否填错？通道SDK的cert/路径是否正确？用ls -l cert/确认文件存在且PHP进程有读权限。
终极诊断法：在pay.php里exec()后加日志：
$cmd = "nohup php /submit/do_pay.php '$order_no' >> /var/log/pay_debug.log 2>&1 &";
error_log("Exec cmd: {$cmd}");
exec($cmd);
然后tail -f /var/log/pay_debug.log看执行结果。
5.2 “回调收不到”——不是网络问题，是协议细节
现象：通道说“已推送回调”，但notice.php日志里没记录。
三步定位法：
1. 抓包验证：在服务器上tcpdump -i any port 80 or port 443 -w callback.pcap，用Wireshark打开，过滤http.request.uri contains "notice.php"，看是否有请求进来。如果没有，是通道没推或防火墙拦截。
2. 检查HTTP响应码：在notice.php开头加error_log("Notice called, HTTP_CODE: " . $_SERVER['REQUEST_METHOD']);，如果日志里只有GET没有POST，说明通道用GET推送（极少见），需改代码。
3. 验签失败静默：notice.php里验签失败时exit('fail')，但通道可能不记录这个响应。解决方案：把exit('fail')改成error_log("Sign fail: {$raw_data}"); exit('fail');，在日志里找失败原因。
经典案例：某银行通道回调带Content-Type: application/json;charset=UTF-8，但file_get_contents('php://input')在PHP 7.2+会因charset参数读空。修复：$raw_data = file_get_contents('php://input'); if (!$raw_data) $raw_data = $HTTP_RAW_POST_DATA;
5.3 “管理后台登录不了”——Session的隐形杀手
现象：输入正确账号密码，跳回登录页，$_SESSION为空。
元凶锁定：
- Session路径权限：/var/lib/php/session目录权限不对。ls -ld /var/lib/php/session应显示drwx-wx-wt，如果不是，chmod 1733 /var/lib/php/session。
- Cookie域不匹配：session_set_cookie_params()里域名设错了。比如网站是pay.example.com，但参数写了example.com，会导致Cookie跨域失效。检查includes/init.php里session_set_cookie_params(0, '/', 'pay.example.com', true, true)。
- PHP-FPM进程用户：Apache用www-data，PHP-FPM用nginx，Session文件所有者不一致。统一用户：user = www-data in /etc/php/7.4/fpm/pool.d/www.conf。
快速验证：在admin/login.php里加：
error_log("Session ID: " . session_id());
error_log("Session data: " . print_r($_SESSION, true));
看日志里Session ID是否变化，数据是否为空。
5.4 “导出Excel乱码”——字符集的最后一公里
现象：导出的.xls文件用Excel打开，中文是方框。
根源与解法：
这不是PHP问题，是Excel的编码识别bug。解决方案是在导出内容前加BOM头：
// admin/export_orders.php 开头
header('Content-Type: application/vnd.ms-excel');
header('Content-Disposition: attachment;filename="orders_' . date('YmdHis') . '.xls"');
header('Cache-Control: max-age=0');
// 输出UTF-8 BOM（Excel识别UTF-8的关键）
echo "\xEF\xBB\xBF";
// 后续输出内容...
echo "订单号\t金额\t...\n";
\xEF\xBB\xBF是UTF-8的BOM字节，Excel看到它就明白这是UTF-8编码，中文显示正常。
5.5 “投诉提交失败”——XSS过滤的过度防御
现象：用户在tousu/submit.php里输入带<script>的投诉内容，提交后提示“非法字符”。
问题定位：includes/safe_input.php的正则/[\'"\\<>\(\)\{\}\[\]\;]+/太暴力，把投诉里的合法HTML标签也干掉了。
安全修复：在tousu/submit.php里绕过严格过滤，只做基础清理：
// tousu/submit.php
$content = $_POST['content'] ?? '';
// 不用safe_input，改用更宽松的过滤
$content = htmlspecialchars($content, ENT_QUOTES, 'UTF-8'); // 只转义，不删除
$content = str_replace(["\r\n", "\r", "\n"], '<br>', $content); // 换行转<br>
$content = preg_replace('/<script[^>]*>.*?<\/script>/is', '', $content); // 删除script标签
投诉内容本质是富文本，不该用safe_input()这种面向表单的过滤器，而该用专门的HTML净化方案。
6. 实战扩展建议：让这套系统真正成为你的生产力工具
这套源码的价值，远不止于“能跑起来”。我在给三家客户部署后，总结出三条低成本高回报的扩展路径，无需重写架构：
第一，接入新通道只需3个文件
要接银联云闪付，不用动核心逻辑，只需：
- 在submit/下新建unionpay_do.php，封装银联SDK调用；
- 在pay.php里加判断：if ($channel === 'unionpay') include 'submit/unionpay_do.php';；
- 在admin/channel_config.php里加银联的配置项（商户号、证书路径、网关地址）。
所有通道共用orders表，状态流转一致，新增通道成本趋近于零。
第二，风控规则引擎嵌入includes/risk_engine.php
现有风控只有risk_score字段，可以升级为规则引擎：
// includes/risk_engine.php
function check_risk($order) {
$rules = [
'amount_too_high' => function($o) { return $o['amount'] > 50000; },
'ip_blacklist' => function($o) { return in_array($o['ip_address'], get_blacklist_ips()); },
'freq_too_fast' => function($o) {
$count = get_order_count_last_hour($o['user_id']);
return $count > 5;
}
];
foreach($rules as $rule => $func) {
if ($func($order)) {
return ['risk' => true, 'reason' => $rule];
}
}
return ['risk' => false];
}
在pay.php事务里调用它，风险订单自动标risk_flag=1并暂停处理，比硬编码更灵活。
第三，对账模块用admin/reconcile.php对接银行CSV
每天下载银行代付明细CSV，上传到admin/reconcile.php：
// 解析CSV，匹配orders表里的order_no
// 找出“银行已出款但系统未更新状态”的订单（状态仍为pending）
// 批量更新为success，并记录对账日志
50行代码，解决财务最头疼的“人工对账”问题。
这套系统最打动我的地方，不是它有多先进，而是它足够“诚实”——所有代码都暴露在阳光下，没有魔法，没有黑盒。当你在pay.php里看到$pdo->beginTransaction()，就知道资金安全有保障；当你在notice.php里看到INSERT IGNORE，就知道消息不丢；当你在admin/export_orders.php里看到\xEF\xBB\xBF，就知道工程师真的懂用户痛点。它不教你“应该怎么做”，而是用一行行代码告诉你：“我们就是这样做的，而且跑通了”。对于想真正理解代付系统的人，这比任何架构图都珍贵。
简介：一套开箱即用的PHP代付系统源码，覆盖用户下单、支付请求、回调处理、通知分发、投诉提交等全流程功能。前端包含首页index.html、错误页404.html及静态资源assets；后端核心文件如pay.php处理代付请求，api.php提供接口支持，notice.php负责消息通知，openid.php用于身份识别；管理员后台位于admin目录，支持订单管理、用户审核、数据统计等操作；user目录实现用户中心，submit处理订单提交，tousu提供投诉入口；cert目录存放SSL证书，backup保留历史备份，html和网站目录含辅助页面；配套69_u7u_top_20210313_230556.sql数据库脚本可一键导入，readme.html和必读资源说明.txt提供部署步骤与环境要求（如PHP版本、MySQL支持、伪静态配置）。所有模块结构清晰，无第三方依赖，适配主流Linux+Apache/Nginx+PHP+MySQL运行环境。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
