简介这套PHP票务管理系统源码覆盖用户注册登录、活动浏览、在线选座、支付下单、订单管理与后台统计等典型业务适合PHP开发者学习电商类业务逻辑也便于活动主办方做本地化二次开发。压缩包共2000个文件包含989个PHP核心脚本、173个JS交互文件、60个CSS样式另有464个PNG、118个JPG等图片素材用于界面展示整体约25.59MB。资源目前已有400人下载学习。源码目录结构清晰前端页面与后端逻辑分层明确可帮助读者理解MVC模式下的数据流与订单状态流转代码中涉及验证码校验、邮箱验证、SQL注入防护、XSS过滤以及密码加密存储等常见安全处理同时采用响应式设计以适配移动端购票场景。在角色权限、报表统计等模块上留有扩展空间可作为票务类项目的起步模板支撑从购票到订单处理的全链路二次开发。1. PHP票务管理系统源码一份能直接改着用的项目骨架拿到一份 PHP 票务管理系统源码多数人第一反应是赶紧传到服务器上看能不能跑但我建议你先冷静三分钟。这套源码不是只能亮个页面出来的演示品它覆盖了用户注册登录、活动场次管理、选座下单、支付回调、退款、后台报表这几条主线。对正在做演出预约平台前期搭原型的小团队或者需要一套能讲清楚完整业务流的课设项目的开发者来说都很值得花时间拆一遍。它把票务最核心的“库存、订单、场次”三件事用常见的 MVC 结构串起来了没有把票档、场次这些概念糊在一张表里。接下来我会按拆包、部署、改业务、避坑这个顺序把整个源码从里到外过一遍让你下载后能直接改出自己要的版本。2. 先读懂代码结构从入口文件到订单状态机拿到源码不要急着丢进 Web 目录先花十分钟把目录过一遍。这类项目大多采用传统 MVC 混合模式入口文件统一走 public 下的 index.php业务代码全部集中在 app 目录里数据库初始化脚本独立放在 sql 目录。看清这层划分后面改任何功能都不会迷路。ticket-system/ ├── public/ # Web 根目录站点根路径指向这里 │ ├── index.php # 单一入口分发所有请求 │ ├── .htaccess # Apache 伪静态规则 │ ├── static/ # css/js/图片等静态资源 │ └── uploads/ # 活动海报、用户头像等上传文件 ├── app/ │ ├── core/ # 数据库封装、路由、模板引擎 │ ├── controllers/ # 订单、场次、用户、支付回调控制器 │ ├── models/ # 与数据表对应的模型层 │ ├── views/ # 前端页面模板 │ ├── config/ # 数据库、邮箱、支付参数配置 │ └── helpers/ # 公共函数格式化、防注入 ├── sql/ │ └── ticket.sql # 完整初始化脚本含表结构和演示数据 ├── vendor/ # Composer 依赖包 ├── runtime/ # 运行时日志与缓存 └── composer.json # 依赖清单文件这段目录结构说明了几个关键设计决定。第一public 作为唯一入口意味着所有非静态请求都过 index.php伪静态规则只需要把不存在的文件请求转发给 index.php第二controllers 和 models 按业务拆分一个订单控制器对应一张或几张互相联动的表改逻辑时不用满项目找函数第三sql 脚本里带了演示数据省去手工造数据的麻烦也方便你完整体验从注册到出票的完整链路。2.1 入口分发与伪静态规则如果你用 Apachepublic/.htaccess 一般长这样IfModule mod_rewrite.c RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php [QSA,L] /IfModule这个规则的意图是如果请求的是一张真实存在的图片或文件例如 /static/logo.png就直接返回磁盘文件如果是不存在的虚拟路径例如 /order/detail/18就交给 index.php 处理。接着 index.php 里通常会有这么几行?php // 定义根目录常量后面所有 require 都用它拼接路径 define(BASE_PATH, __DIR__ . /../); // 加载 Composer 自动加载器让类名到文件路径自动映射 require BASE_PATH . vendor/autoload.php; // 把 $_SERVER[REQUEST_URI] 解析成控制器/方法/参数 $route Router::parse($_SERVER[REQUEST_URI]); App::run($route);这里最需要注意的参数是 index.php 后面是否带路径。如果你把站点根目录直接指向 publicURL 就是干净的 /order/list如果只是放在子目录里调试URL 会多出一层目录名部分源码的路由需要把 RewriteBase 改成 /子目录名/否则会报 404 或者提示找不到控制器。Nginx 下的写法也同理常见的配置是location / { try_files $uri $uri/ /index.php?$query_string; }2.2 核心数据表场次、票种、订单怎么联动在票务逻辑里最忌讳把活动信息、场次信息、价格信息全部塞进一张表。这套源码的做法是拆成分层关系活动表只存标题、海报、上架状态场次表存一场活动的具体日期和总库存票种表存不同票档的定价和单独库存。三层拆分之后每个活动可以有多个场次每个场次下又能有早鸟票、学生票和 VIP 票改某个票价不影响其他场次。CREATE TABLE activity ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, title VARCHAR(120) NOT NULL, cover VARCHAR(255) DEFAULT NULL, description TEXT, status TINYINT NOT NULL DEFAULT 1 COMMENT 0下架 1上架, created_at DATETIME NOT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE session ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, activity_id INT UNSIGNED NOT NULL COMMENT 关联活动, start_time DATETIME NOT NULL COMMENT 场次开始时间, end_time DATETIME NOT NULL, total_tickets INT NOT NULL DEFAULT 0 COMMENT 场次总票数, sold_tickets INT NOT NULL DEFAULT 0 COMMENT 已售预占数量, status TINYINT NOT NULL DEFAULT 1 COMMENT 1未开售 2售票中 3已售罄 4已结束, PRIMARY KEY (id), KEY idx_activity (activity_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE ticket_type ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, session_id INT UNSIGNED NOT NULL, name VARCHAR(50) NOT NULL COMMENT 早鸟票/学生票/VIP, price DECIMAL(10,2) NOT NULL COMMENT 单张售价, stock INT NOT NULL DEFAULT 0 COMMENT 该票档剩余库存, PRIMARY KEY (id), KEY idx_session (session_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意 ticket_type 里单独维护 stock 字段业务代码中会与场次表的 sold_tickets 一起更新。初学者最容易犯的错误是把票档库存写死不扣减或者只在内存里减刷新页面又恢复原样。订单明细里的 ticket_type_id 是核心关联字段想要统计“哪个票档卖得好”或者“哪个场次被取消最多”直接 join 这张表就能查出来。后续如果要加限购数量、早鸟截止时间也都是在这个票种表上扩展字段。订单部分再补一点真实项目的主表 orders 只保存订单号、用户、场次、总金额、状态这些汇总信息每个票档的单价和数量拆到 order_items 子表里。这套源码如果只有一张订单表说明它是精简版适合学习但不适合直接做真实售卖你做二次开发时优先把明细表拆出来不然后面退款、对账都会很痛苦。2.3 订单状态机何时预占库存何时释放字段物理结构上面已经给了这一段重点说流程。票务系统与普通商城最大的区别是“库存强时效、票档有限”所以下单动作必须和库存变动放在同一个数据库事务里。常见的伪代码是这样的// OrderController::create 简化实现 $db-beginTransaction(); try { // 尝试扣减票档库存条件带上剩余库存足够 $affected $db-execute( UPDATE ticket_type SET stock stock - :n WHERE id :id AND stock :n, [n $count, id $ticketTypeId] ); if ($affected ! 1) { throw new BizException(该票档库存不足); } // 写入订单主表 $orderNo generateOrderNo($userId); $orderId $db-insert(orders, [ order_no $orderNo, user_id $userId, session_id $sessionId, ticket_count $count, total_amount $price * $count, status 0, created_at date(Y-m-d H:i:s), ]); // 写入订单明细子表 foreach ($items as $item) { $db-insert(order_items, [ order_id $orderId, ticket_type_id $item[ticket_type_id], price $item[price], quantity $item[quantity], ]); } $db-commit(); } catch (Exception $e) { $db-rollback(); throw $e; }这里的关键是 UPDATE 语句的 where 条件中带上 stock :n而不是先 SELECT 查出库存再在 PHP 里 if 判断。因为 MySQL 默认隔离级别下先查再改会产生幻读两个请求同时读到有库存然后同时去扣最终卖出数超过可售数。先把票档库存预占掉即使后面用户不支付这个库存也会一直占用所以还需要一个超时释放机制。超时释放通常有两种实现一是定时脚本每分钟扫描一次待支付订单只要订单创建时间早于当前时间减 15 分钟就执行取消并把库存加回去二是用户主动刷新订单页面时检测到超过支付时限才释放。定时脚本更可靠不依赖用户回访。你改这套源码时要在 CronController 里把时间阈值调成和支付渠道允许的有效期一致否则会出现“支付渠道已扣款但系统订单已取消”的资损级 bug。动作原状态新状态库存变化触发位置创建订单无待支付预占票档库存OrderController::create支付成功待支付已支付预占转实销PayNotifyController::handle超时取消待支付已取消释放库存CronController::cancelExpired用户取消待支付已取消释放库存OrderController::cancel售后退款已支付已退款释放库存RefundController::apply这张状态表基本就是票务源码里的业务骨架。看它的时候顺带检查一下自己的改法如果创建订单时没有预占库存而是支付成功后才扣库存那么同时并发抢票时页面显示有票支付下单时才发现没了体验就是灾难级的。后面第四章我会单独展开并发扣库存的细节。3. 本地跑起来装环境、灌数据、走通首个购票闭环源码看懂了接下来就要让它跑起来。这一步很多人会卡在 PHP 版本、扩展安装、伪静态几个地方。我的建议是先用 PHP 内置服务器跑通再考虑放 Nginx/Apache这样排查范围小很多。3.1 环境准备PHP 版本与扩展检查先确认你机器上的 PHP 版本和已加载扩展。这套源码在 PHP 7.4 环境下最稳8.2 也能跑但部分老自定义函数会触发弃用警告表现为页面顶部出现黄条警告或者日志刷屏。执行下面命令看环境php -v php -m | grep -E pdo|pdo_mysql|mbstring|openssl|curl|fileinfo composer install --no-devgrep 那行如果缺少 pdo_mysql就需要在 php.ini 里打开扩展没有 mbstring 会导致字符串截断函数不可用登录注册界面直接白屏。Composer 安装依赖时如果网速不稳定可以换成国内镜像源composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/这段命令里的 no-dev 参数值得说明生产环境装依赖时不带测试工具减少暴露面本地调试时建议去掉 no-dev否则缺了开发辅助包路由调试工具栏不显示你很难定位 404 原因。3.2 初始化数据库与配置文件数据库初始化脚本在 sql/ticket.sql里面包含建库、建表和演示数据。我先建空库再导入避免脚本里的 CREATE DATABASE 与本地字符集冲突mysql -uroot -p -e CREATE DATABASE ticket_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; mysql -uroot -p ticket_db sql/ticket.sql导入后打开 app/config/database.php修改连接参数return [ driver mysql, host 127.0.0.1, port 3306, database ticket_db, username root, password 你的密码, charset utf8mb4, timezone 08:00, ];三个最容易错的地方。一是密码含特殊字符时PHP 字符串里要转义比如$要用单引号包裹二是 charset 必须 utf8mb4如果写成 utf8导入 emoji 表情或者特殊符号会报错或变问号三是 timezone 不设置某些场次比较逻辑会用 MySQL 的 NOW()与你本地时间差 8 小时导致“活动还没开售”或“已结束”的误判。3.3 启动内置服务器并验证首单流程配置没问题就能用 PHP 内置服务器快速启动不需要装完整 nginxcd ticket-system php -S 0.0.0.0:8080 -t public浏览器访问http://127.0.0.1:8080/activity/list能看到活动列表就说明入口和数据库正常了。然后你可以用 curl 模拟一次下单curl -X POST http://127.0.0.1:8080/order/create \ -H Content-Type: application/json \ -d {session_id:1,ticket_type_id:1,quantity:2}如果返回{code:0,order_no:20250...}就说明下单链路通。再去数据库看一眼预占库存SELECT id, name, stock, price FROM ticket_type WHERE id 1;stock 应该比初始值少了 2说明扣减生效。最后刷新订单列表页能查到刚下的订单整条链路就算闭环了。这里有一点要特别注意内置服务器是单线程的用来验证逻辑没问题并发压测或真实部署时一定要换 Nginx/FPM。注意PHP 内置服务器适合本地调试正式上线前把 document root 指向 public并且给 runtime 目录写权限否则日志和缓存写不进去页面会一直转圈。4. 二次开发动刀点支付回调、票种规则与库存扣减本地跑通只是起点大多数下载这套源码的人都是为了在上面对接自己的支付渠道、改票价规则或者想办法扛住抢票高峰。这一章我把最常改的三个位置拆开讲。4.1 支付回调处理逻辑验签、幂等、更新订单支付回调是票务系统里最容易出问题的环节。网上这个源码版本自带的回调往往是模拟开发环境真正上线需要替换成你的支付商户号。回调处理里的核心是验签和幂等我一般会在 PayNotifyController 中这样组织public function handle() { $payload file_get_contents(php://input); $data json_decode($payload, true); // 1. 验签防止伪造回调请求 $isValid PayService::verifySign( $data[order_no], $data[total_amount], $data[sign] ); if (!$isValid) { return fail; // 返回非success让渠道继续重试 } // 2. 幂等已支付的订单直接返回成功避免重复入账 $order $this-orderModel-findByOrderNo($data[order_no]); if (!$order || $order[status] 1) { return success; } // 3. 事务里更新订单状态记录支付流水 $db-beginTransaction(); try { $db-execute( UPDATE orders SET status1, paid_atNOW() WHERE order_no:no AND status0, [no $data[order_no]] ); $db-insert(payment_logs, [ order_no $data[order_no], trade_no $data[trade_no], amount $data[total_amount], raw_data $payload, created_at date(Y-m-d H:i:s), ]); $db-commit(); return success; } catch (Exception $e) { $db-rollback(); return fail; } }这里的三个参数 order_no、trade_no、total_amount 必须和下单时传回支付渠道的完全一致。回调验签失败一般有两个原因一是签名算法用http_build_query拼接时数组顺序与渠道要求不一致二是数据库里存的总金额是浮点型取出后变成 49.999999导致验签金额对不上。解决办法是下单时把金额转成分为单位的整数再参与验签数据库里存整数分值展示时再除以 100。4.2 票种规则与限购逻辑改造源码自带的基础票种只有名称、价格、库存。真实业务里常有“早鸟票每人限购 2 张”“学生票必须验证身份”这类需求。我一般先在 ticket_type 表上增加字段ALTER TABLE ticket_type ADD COLUMN limit_per_user INT NOT NULL DEFAULT 0 COMMENT 每人限购张数0不限, ADD COLUMN need_verify TINYINT NOT NULL DEFAULT 0 COMMENT 是否需核验身份;然后在下单控制器里加一段判断查用户在该场次已支付和待支付的订单if ($ticket[limit_per_user] 0) { $bought $this-orderModel-countUserPurchased( $userId, $sessionId, $ticketId, $ticket[limit_per_user] ); if ($bought $quantity $ticket[limit_per_user]) { throw new BizException(该票种每人限购 .$ticket[limit_per_user]. 张); } }countUserPurchased 的本质是一个 join 查询orders 表关联 order_items过滤掉 status 为已取消和已退款的订单只统计状态为 0、1、3 的订单。很多翻车现场就是把已取消的订单也算进去用户取消一单后限购数永远到不了只好重新注册账号买客服压力直接拉满。4.3 高并发下的库存扣减与超时释放抢票场景下直接用事务锁是可行的但要看锁的粒度。上面的 stock :n 原子更新已经解决超卖的主要问题但它会锁住这条票档记录同一秒内大量请求会排队。更常见的做法是给场次或票档加一个 Redis 计数器先预扣再写订单// 伪代码Redis 预扣DB 异步扣减 $redisKey ticket:stock: . $ticketTypeId; $current $redis-decrBy($redisKey, $quantity); if ($current 0) { $redis-incrBy($redisKey, $quantity); // 回补 throw new BizException(库存不足); }但要清楚Redis 预扣只解决瞬时并发数据库里 stock 字段仍然要在事务里扣减双方要保持最终一致。我在实际改这套源码时会保留单机 MySQL 原子 UPDATE 作为兜底Redis 只做前置熔断。另外超时释放脚本里有个常见错误直接把待支付订单全部扫一遍然后 UPDATE 库存加回来但没判断这个订单是不是已经被用户取消过。释放操作要带条件否则同一订单被取消脚本跑两遍库存就虚增了-- 超时取消前先确认订单状态仍是待支付 UPDATE orders SET status2, cancel_timeNOW() WHERE order_no:no AND status0 AND created_at :expire_time;如果影响行数为 1才再去执行库存回补。这就是为什么 cancelExpired 里必须先用影响的函数判断订单状态而不是先 SELECT 再 UPDATE。5. 常见问题与避坑安装和上线必踩的五个坑这套源码我在部署和二次开发中反复踩过不少坑挑五个最高频的按“现象、原因、解决”写清楚能帮你少走很多弯路。5.1 白屏加 Fatal error: Call to undefined function现象首页打开是全白打开 PHP 错误日志后看到Uncaught Error: Call to undefined function curl_init()或者create_function()。原因服务器 PHP 缺少 curl 扩展或者源码是从 PHP 5 升级来的用了已经被 7.x/8.x 移除的 create_function、mysql_xx 系列函数。解决先在 php.ini 中打开 extensioncurl、extensionmbstring、extensionpdo_mysql。然后全局搜索create_function把它替换成匿名函数写法很简单// 旧写法 $callback create_function($v, return $v[price] 100;); // 新写法 $callback function ($v) { return $v[price] 100; };搜索时不要只搜 create_function还要搜mysql_开头的函数常见的是 mysql_query、mysql_fetch_assoc这些都是 PHP 7 里删干净的老 API。5.2 导入 SQL 时中文乱码或半路失败现象ticket.sql 用 mysql 命令导入中途报错某张表建到一半失败强行导入成功后前端页面活动标题全部是问号。原因SQL 文件本身的字符集与数据库不一致或者里面用了utf8mb4_0900_ai_ci这种 MySQL 8.0 排序规则导入到 5.7 时直接不认识更常见的是 Windows 下用记事本打开 SQL 后另存为 UTF-8 with BOMBOM 头被 MySQL 解析成无意义特殊字符。解决把库、表全部统一成 utf8mb4_general_ci导入时显式声明字符集mysql -uroot -p --default-character-setutf8mb4 ticket_db sql/ticket.sql导入后再检查一边命令行里执行SHOW CREATE TABLE activity看 ENGINE 是不是 InnoDBCHARSET 是不是 utf8mb4。不是的话删掉重建别指望中途改排序规则能自动纠正已有数据。5.3 Nginx 下访问 /order/list 一直 404现象Nginx 部署后首页能打开但跳转到一个虚拟路径就 404页面上的静态资源却正常。原因Nginx 没配置 try_filesPHP 框架入口没有接管虚拟路径。Apache 的 .htaccess 对 Nginx 不生效。解决在 server 块里加上location / { try_files $uri $uri/ /index.php?$query_string; }注意这一行的顺序可以微调当你的路由需要带 query 参数时写/index.php?$query_string而不是/index.php否则控制器拿不到 GET 参数。另外如果源码跑在子目录/ticket/下try_files 里也要改成/index.php?$query_string否则请求总是落到根目录。5.4 并发下单后库存对不上现象抢票模拟 20 个并发最终 sold_tickets 比总库存多或者负库存。原因代码写成了“先 SELECT 库存再在 PHP 里判断库存是否大于 0然后 UPDATE”这个判断和更新之间没有原子性多个请求同时通过判断。还有一种原因是超时取消脚本与支付回调同时执行库存被回补两次。解决把库存扣减改成带条件的原子 UPDATE并检查影响行数$affected $db-execute( UPDATE ticket_type SET stock stock - :n WHERE id :id AND stock :n, [n $qty, id $ticketTypeId] ); if ($affected 0) { throw new BizException(库存不足); }每次下单只允许真正扣减成功的请求继续写订单表其他请求直接失败。再强调一次所有库存回补操作前都必须用 UPDATE 影响行数判断原订单状态不能只靠 SELECT 判断。5.5 订单已扣款但后台状态仍是“待支付”现象用户用微信扫码付了钱回到订单页一直显示待支付甚至过一会儿被超时脚本取消了。原因回调请求没能到达服务器。常见三处回调 URL 写成了 http但微信支付要求 https服务器防火墙拦了陌生 UA代码里回调入口被加了登录鉴权支付渠道没有 session 直接 302 跳转。解决把回调路由加进白名单关闭该路由的登录拦截改为验签。然后在回调入口临时加一行日志error_log(json_encode([ post $_POST, header getallheaders(), ])); file_put_contents(/tmp/pay_callback.log, $payload, FILE_APPEND);如果日志文件长期为空说明请求根本没进 PHP去查服务器访问日志确认渠道是否定访问到你的地址。回调处理成功后一定要用exit(success)输出纯文本才退出不要 echo JSON 或跳转否则渠道会认为回调失败并反复重试。6. 上线前最后一道工序功能验证与安全加固源码改到能跑业务之后别急着上线。我习惯在最后一步固定做三件事全流程回测、安全加固、数据库备份。功能回测别只测“下单→支付→查看订单”要测全状态流转创建订单后不支付等超时看库存是否回补支付回调重复推送两次看是否会重复改订单退款后再次下单看限额和库存释放。用一个简单脚本模拟并发下单能帮你提前看到超卖问题for i in {1..50}; do curl -X POST -s http://127.0.0.1:8080/order/create \ -d {session_id:1,ticket_type_id:1,quantity:1} done wait脚本跑完去 MySQL 查 ticket_type 表的 stock如果接近负数那就要回上一章把原子扣减补上。安全加固方面这套源码常见的薄弱点是后台路径没有限流、上传目录可执行 PHP、SQL 查询在个别功能里用了字符串拼接。我一般会做四件最小改动// 入口处统一过滤输入去掉 NULL 字符和多余的空白 $_GET array_map(trim, $_GET); $_POST array_map(trim, $_POST);上传目录在 Nginx 中禁止解析 PHP文件上传后强制重命名为带随机串的文件名。后台登录接口加验证码和 IP 频率限制。数据库备份脚本只保留最近 7 天每天凌晨执行一次mysqldump。这套源码对我最大的价值不是上的 tickets 表有多复杂而是把票务里“强库存、强时效、多渠道对账”这几个核心问题完整演示出来了。从那以后我每次拿到一套 PHP 票务源码都会先强制走一遍“环境检查、开事务、验签、状态机核对”四步确认能完整重现交易链路后再谈二次开发。这样做的结果是上线后出问题的概率低了很多希望你也能从这个源码里收获同样的手感。本文还有配套的精品资源点击获取 PHP票务管理系统源码实战：从结构拆解到高并发库存扣减
简介这套PHP票务管理系统源码覆盖用户注册登录、活动浏览、在线选座、支付下单、订单管理与后台统计等典型业务适合PHP开发者学习电商类业务逻辑也便于活动主办方做本地化二次开发。压缩包共2000个文件包含989个PHP核心脚本、173个JS交互文件、60个CSS样式另有464个PNG、118个JPG等图片素材用于界面展示整体约25.59MB。资源目前已有400人下载学习。源码目录结构清晰前端页面与后端逻辑分层明确可帮助读者理解MVC模式下的数据流与订单状态流转代码中涉及验证码校验、邮箱验证、SQL注入防护、XSS过滤以及密码加密存储等常见安全处理同时采用响应式设计以适配移动端购票场景。在角色权限、报表统计等模块上留有扩展空间可作为票务类项目的起步模板支撑从购票到订单处理的全链路二次开发。1. PHP票务管理系统源码一份能直接改着用的项目骨架拿到一份 PHP 票务管理系统源码多数人第一反应是赶紧传到服务器上看能不能跑但我建议你先冷静三分钟。这套源码不是只能亮个页面出来的演示品它覆盖了用户注册登录、活动场次管理、选座下单、支付回调、退款、后台报表这几条主线。对正在做演出预约平台前期搭原型的小团队或者需要一套能讲清楚完整业务流的课设项目的开发者来说都很值得花时间拆一遍。它把票务最核心的“库存、订单、场次”三件事用常见的 MVC 结构串起来了没有把票档、场次这些概念糊在一张表里。接下来我会按拆包、部署、改业务、避坑这个顺序把整个源码从里到外过一遍让你下载后能直接改出自己要的版本。2. 先读懂代码结构从入口文件到订单状态机拿到源码不要急着丢进 Web 目录先花十分钟把目录过一遍。这类项目大多采用传统 MVC 混合模式入口文件统一走 public 下的 index.php业务代码全部集中在 app 目录里数据库初始化脚本独立放在 sql 目录。看清这层划分后面改任何功能都不会迷路。ticket-system/ ├── public/ # Web 根目录站点根路径指向这里 │ ├── index.php # 单一入口分发所有请求 │ ├── .htaccess # Apache 伪静态规则 │ ├── static/ # css/js/图片等静态资源 │ └── uploads/ # 活动海报、用户头像等上传文件 ├── app/ │ ├── core/ # 数据库封装、路由、模板引擎 │ ├── controllers/ # 订单、场次、用户、支付回调控制器 │ ├── models/ # 与数据表对应的模型层 │ ├── views/ # 前端页面模板 │ ├── config/ # 数据库、邮箱、支付参数配置 │ └── helpers/ # 公共函数格式化、防注入 ├── sql/ │ └── ticket.sql # 完整初始化脚本含表结构和演示数据 ├── vendor/ # Composer 依赖包 ├── runtime/ # 运行时日志与缓存 └── composer.json # 依赖清单文件这段目录结构说明了几个关键设计决定。第一public 作为唯一入口意味着所有非静态请求都过 index.php伪静态规则只需要把不存在的文件请求转发给 index.php第二controllers 和 models 按业务拆分一个订单控制器对应一张或几张互相联动的表改逻辑时不用满项目找函数第三sql 脚本里带了演示数据省去手工造数据的麻烦也方便你完整体验从注册到出票的完整链路。2.1 入口分发与伪静态规则如果你用 Apachepublic/.htaccess 一般长这样IfModule mod_rewrite.c RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php [QSA,L] /IfModule这个规则的意图是如果请求的是一张真实存在的图片或文件例如 /static/logo.png就直接返回磁盘文件如果是不存在的虚拟路径例如 /order/detail/18就交给 index.php 处理。接着 index.php 里通常会有这么几行?php // 定义根目录常量后面所有 require 都用它拼接路径 define(BASE_PATH, __DIR__ . /../); // 加载 Composer 自动加载器让类名到文件路径自动映射 require BASE_PATH . vendor/autoload.php; // 把 $_SERVER[REQUEST_URI] 解析成控制器/方法/参数 $route Router::parse($_SERVER[REQUEST_URI]); App::run($route);这里最需要注意的参数是 index.php 后面是否带路径。如果你把站点根目录直接指向 publicURL 就是干净的 /order/list如果只是放在子目录里调试URL 会多出一层目录名部分源码的路由需要把 RewriteBase 改成 /子目录名/否则会报 404 或者提示找不到控制器。Nginx 下的写法也同理常见的配置是location / { try_files $uri $uri/ /index.php?$query_string; }2.2 核心数据表场次、票种、订单怎么联动在票务逻辑里最忌讳把活动信息、场次信息、价格信息全部塞进一张表。这套源码的做法是拆成分层关系活动表只存标题、海报、上架状态场次表存一场活动的具体日期和总库存票种表存不同票档的定价和单独库存。三层拆分之后每个活动可以有多个场次每个场次下又能有早鸟票、学生票和 VIP 票改某个票价不影响其他场次。CREATE TABLE activity ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, title VARCHAR(120) NOT NULL, cover VARCHAR(255) DEFAULT NULL, description TEXT, status TINYINT NOT NULL DEFAULT 1 COMMENT 0下架 1上架, created_at DATETIME NOT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE session ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, activity_id INT UNSIGNED NOT NULL COMMENT 关联活动, start_time DATETIME NOT NULL COMMENT 场次开始时间, end_time DATETIME NOT NULL, total_tickets INT NOT NULL DEFAULT 0 COMMENT 场次总票数, sold_tickets INT NOT NULL DEFAULT 0 COMMENT 已售预占数量, status TINYINT NOT NULL DEFAULT 1 COMMENT 1未开售 2售票中 3已售罄 4已结束, PRIMARY KEY (id), KEY idx_activity (activity_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE ticket_type ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, session_id INT UNSIGNED NOT NULL, name VARCHAR(50) NOT NULL COMMENT 早鸟票/学生票/VIP, price DECIMAL(10,2) NOT NULL COMMENT 单张售价, stock INT NOT NULL DEFAULT 0 COMMENT 该票档剩余库存, PRIMARY KEY (id), KEY idx_session (session_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意 ticket_type 里单独维护 stock 字段业务代码中会与场次表的 sold_tickets 一起更新。初学者最容易犯的错误是把票档库存写死不扣减或者只在内存里减刷新页面又恢复原样。订单明细里的 ticket_type_id 是核心关联字段想要统计“哪个票档卖得好”或者“哪个场次被取消最多”直接 join 这张表就能查出来。后续如果要加限购数量、早鸟截止时间也都是在这个票种表上扩展字段。订单部分再补一点真实项目的主表 orders 只保存订单号、用户、场次、总金额、状态这些汇总信息每个票档的单价和数量拆到 order_items 子表里。这套源码如果只有一张订单表说明它是精简版适合学习但不适合直接做真实售卖你做二次开发时优先把明细表拆出来不然后面退款、对账都会很痛苦。2.3 订单状态机何时预占库存何时释放字段物理结构上面已经给了这一段重点说流程。票务系统与普通商城最大的区别是“库存强时效、票档有限”所以下单动作必须和库存变动放在同一个数据库事务里。常见的伪代码是这样的// OrderController::create 简化实现 $db-beginTransaction(); try { // 尝试扣减票档库存条件带上剩余库存足够 $affected $db-execute( UPDATE ticket_type SET stock stock - :n WHERE id :id AND stock :n, [n $count, id $ticketTypeId] ); if ($affected ! 1) { throw new BizException(该票档库存不足); } // 写入订单主表 $orderNo generateOrderNo($userId); $orderId $db-insert(orders, [ order_no $orderNo, user_id $userId, session_id $sessionId, ticket_count $count, total_amount $price * $count, status 0, created_at date(Y-m-d H:i:s), ]); // 写入订单明细子表 foreach ($items as $item) { $db-insert(order_items, [ order_id $orderId, ticket_type_id $item[ticket_type_id], price $item[price], quantity $item[quantity], ]); } $db-commit(); } catch (Exception $e) { $db-rollback(); throw $e; }这里的关键是 UPDATE 语句的 where 条件中带上 stock :n而不是先 SELECT 查出库存再在 PHP 里 if 判断。因为 MySQL 默认隔离级别下先查再改会产生幻读两个请求同时读到有库存然后同时去扣最终卖出数超过可售数。先把票档库存预占掉即使后面用户不支付这个库存也会一直占用所以还需要一个超时释放机制。超时释放通常有两种实现一是定时脚本每分钟扫描一次待支付订单只要订单创建时间早于当前时间减 15 分钟就执行取消并把库存加回去二是用户主动刷新订单页面时检测到超过支付时限才释放。定时脚本更可靠不依赖用户回访。你改这套源码时要在 CronController 里把时间阈值调成和支付渠道允许的有效期一致否则会出现“支付渠道已扣款但系统订单已取消”的资损级 bug。动作原状态新状态库存变化触发位置创建订单无待支付预占票档库存OrderController::create支付成功待支付已支付预占转实销PayNotifyController::handle超时取消待支付已取消释放库存CronController::cancelExpired用户取消待支付已取消释放库存OrderController::cancel售后退款已支付已退款释放库存RefundController::apply这张状态表基本就是票务源码里的业务骨架。看它的时候顺带检查一下自己的改法如果创建订单时没有预占库存而是支付成功后才扣库存那么同时并发抢票时页面显示有票支付下单时才发现没了体验就是灾难级的。后面第四章我会单独展开并发扣库存的细节。3. 本地跑起来装环境、灌数据、走通首个购票闭环源码看懂了接下来就要让它跑起来。这一步很多人会卡在 PHP 版本、扩展安装、伪静态几个地方。我的建议是先用 PHP 内置服务器跑通再考虑放 Nginx/Apache这样排查范围小很多。3.1 环境准备PHP 版本与扩展检查先确认你机器上的 PHP 版本和已加载扩展。这套源码在 PHP 7.4 环境下最稳8.2 也能跑但部分老自定义函数会触发弃用警告表现为页面顶部出现黄条警告或者日志刷屏。执行下面命令看环境php -v php -m | grep -E pdo|pdo_mysql|mbstring|openssl|curl|fileinfo composer install --no-devgrep 那行如果缺少 pdo_mysql就需要在 php.ini 里打开扩展没有 mbstring 会导致字符串截断函数不可用登录注册界面直接白屏。Composer 安装依赖时如果网速不稳定可以换成国内镜像源composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/这段命令里的 no-dev 参数值得说明生产环境装依赖时不带测试工具减少暴露面本地调试时建议去掉 no-dev否则缺了开发辅助包路由调试工具栏不显示你很难定位 404 原因。3.2 初始化数据库与配置文件数据库初始化脚本在 sql/ticket.sql里面包含建库、建表和演示数据。我先建空库再导入避免脚本里的 CREATE DATABASE 与本地字符集冲突mysql -uroot -p -e CREATE DATABASE ticket_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; mysql -uroot -p ticket_db sql/ticket.sql导入后打开 app/config/database.php修改连接参数return [ driver mysql, host 127.0.0.1, port 3306, database ticket_db, username root, password 你的密码, charset utf8mb4, timezone 08:00, ];三个最容易错的地方。一是密码含特殊字符时PHP 字符串里要转义比如$要用单引号包裹二是 charset 必须 utf8mb4如果写成 utf8导入 emoji 表情或者特殊符号会报错或变问号三是 timezone 不设置某些场次比较逻辑会用 MySQL 的 NOW()与你本地时间差 8 小时导致“活动还没开售”或“已结束”的误判。3.3 启动内置服务器并验证首单流程配置没问题就能用 PHP 内置服务器快速启动不需要装完整 nginxcd ticket-system php -S 0.0.0.0:8080 -t public浏览器访问http://127.0.0.1:8080/activity/list能看到活动列表就说明入口和数据库正常了。然后你可以用 curl 模拟一次下单curl -X POST http://127.0.0.1:8080/order/create \ -H Content-Type: application/json \ -d {session_id:1,ticket_type_id:1,quantity:2}如果返回{code:0,order_no:20250...}就说明下单链路通。再去数据库看一眼预占库存SELECT id, name, stock, price FROM ticket_type WHERE id 1;stock 应该比初始值少了 2说明扣减生效。最后刷新订单列表页能查到刚下的订单整条链路就算闭环了。这里有一点要特别注意内置服务器是单线程的用来验证逻辑没问题并发压测或真实部署时一定要换 Nginx/FPM。注意PHP 内置服务器适合本地调试正式上线前把 document root 指向 public并且给 runtime 目录写权限否则日志和缓存写不进去页面会一直转圈。4. 二次开发动刀点支付回调、票种规则与库存扣减本地跑通只是起点大多数下载这套源码的人都是为了在上面对接自己的支付渠道、改票价规则或者想办法扛住抢票高峰。这一章我把最常改的三个位置拆开讲。4.1 支付回调处理逻辑验签、幂等、更新订单支付回调是票务系统里最容易出问题的环节。网上这个源码版本自带的回调往往是模拟开发环境真正上线需要替换成你的支付商户号。回调处理里的核心是验签和幂等我一般会在 PayNotifyController 中这样组织public function handle() { $payload file_get_contents(php://input); $data json_decode($payload, true); // 1. 验签防止伪造回调请求 $isValid PayService::verifySign( $data[order_no], $data[total_amount], $data[sign] ); if (!$isValid) { return fail; // 返回非success让渠道继续重试 } // 2. 幂等已支付的订单直接返回成功避免重复入账 $order $this-orderModel-findByOrderNo($data[order_no]); if (!$order || $order[status] 1) { return success; } // 3. 事务里更新订单状态记录支付流水 $db-beginTransaction(); try { $db-execute( UPDATE orders SET status1, paid_atNOW() WHERE order_no:no AND status0, [no $data[order_no]] ); $db-insert(payment_logs, [ order_no $data[order_no], trade_no $data[trade_no], amount $data[total_amount], raw_data $payload, created_at date(Y-m-d H:i:s), ]); $db-commit(); return success; } catch (Exception $e) { $db-rollback(); return fail; } }这里的三个参数 order_no、trade_no、total_amount 必须和下单时传回支付渠道的完全一致。回调验签失败一般有两个原因一是签名算法用http_build_query拼接时数组顺序与渠道要求不一致二是数据库里存的总金额是浮点型取出后变成 49.999999导致验签金额对不上。解决办法是下单时把金额转成分为单位的整数再参与验签数据库里存整数分值展示时再除以 100。4.2 票种规则与限购逻辑改造源码自带的基础票种只有名称、价格、库存。真实业务里常有“早鸟票每人限购 2 张”“学生票必须验证身份”这类需求。我一般先在 ticket_type 表上增加字段ALTER TABLE ticket_type ADD COLUMN limit_per_user INT NOT NULL DEFAULT 0 COMMENT 每人限购张数0不限, ADD COLUMN need_verify TINYINT NOT NULL DEFAULT 0 COMMENT 是否需核验身份;然后在下单控制器里加一段判断查用户在该场次已支付和待支付的订单if ($ticket[limit_per_user] 0) { $bought $this-orderModel-countUserPurchased( $userId, $sessionId, $ticketId, $ticket[limit_per_user] ); if ($bought $quantity $ticket[limit_per_user]) { throw new BizException(该票种每人限购 .$ticket[limit_per_user]. 张); } }countUserPurchased 的本质是一个 join 查询orders 表关联 order_items过滤掉 status 为已取消和已退款的订单只统计状态为 0、1、3 的订单。很多翻车现场就是把已取消的订单也算进去用户取消一单后限购数永远到不了只好重新注册账号买客服压力直接拉满。4.3 高并发下的库存扣减与超时释放抢票场景下直接用事务锁是可行的但要看锁的粒度。上面的 stock :n 原子更新已经解决超卖的主要问题但它会锁住这条票档记录同一秒内大量请求会排队。更常见的做法是给场次或票档加一个 Redis 计数器先预扣再写订单// 伪代码Redis 预扣DB 异步扣减 $redisKey ticket:stock: . $ticketTypeId; $current $redis-decrBy($redisKey, $quantity); if ($current 0) { $redis-incrBy($redisKey, $quantity); // 回补 throw new BizException(库存不足); }但要清楚Redis 预扣只解决瞬时并发数据库里 stock 字段仍然要在事务里扣减双方要保持最终一致。我在实际改这套源码时会保留单机 MySQL 原子 UPDATE 作为兜底Redis 只做前置熔断。另外超时释放脚本里有个常见错误直接把待支付订单全部扫一遍然后 UPDATE 库存加回来但没判断这个订单是不是已经被用户取消过。释放操作要带条件否则同一订单被取消脚本跑两遍库存就虚增了-- 超时取消前先确认订单状态仍是待支付 UPDATE orders SET status2, cancel_timeNOW() WHERE order_no:no AND status0 AND created_at :expire_time;如果影响行数为 1才再去执行库存回补。这就是为什么 cancelExpired 里必须先用影响的函数判断订单状态而不是先 SELECT 再 UPDATE。5. 常见问题与避坑安装和上线必踩的五个坑这套源码我在部署和二次开发中反复踩过不少坑挑五个最高频的按“现象、原因、解决”写清楚能帮你少走很多弯路。5.1 白屏加 Fatal error: Call to undefined function现象首页打开是全白打开 PHP 错误日志后看到Uncaught Error: Call to undefined function curl_init()或者create_function()。原因服务器 PHP 缺少 curl 扩展或者源码是从 PHP 5 升级来的用了已经被 7.x/8.x 移除的 create_function、mysql_xx 系列函数。解决先在 php.ini 中打开 extensioncurl、extensionmbstring、extensionpdo_mysql。然后全局搜索create_function把它替换成匿名函数写法很简单// 旧写法 $callback create_function($v, return $v[price] 100;); // 新写法 $callback function ($v) { return $v[price] 100; };搜索时不要只搜 create_function还要搜mysql_开头的函数常见的是 mysql_query、mysql_fetch_assoc这些都是 PHP 7 里删干净的老 API。5.2 导入 SQL 时中文乱码或半路失败现象ticket.sql 用 mysql 命令导入中途报错某张表建到一半失败强行导入成功后前端页面活动标题全部是问号。原因SQL 文件本身的字符集与数据库不一致或者里面用了utf8mb4_0900_ai_ci这种 MySQL 8.0 排序规则导入到 5.7 时直接不认识更常见的是 Windows 下用记事本打开 SQL 后另存为 UTF-8 with BOMBOM 头被 MySQL 解析成无意义特殊字符。解决把库、表全部统一成 utf8mb4_general_ci导入时显式声明字符集mysql -uroot -p --default-character-setutf8mb4 ticket_db sql/ticket.sql导入后再检查一边命令行里执行SHOW CREATE TABLE activity看 ENGINE 是不是 InnoDBCHARSET 是不是 utf8mb4。不是的话删掉重建别指望中途改排序规则能自动纠正已有数据。5.3 Nginx 下访问 /order/list 一直 404现象Nginx 部署后首页能打开但跳转到一个虚拟路径就 404页面上的静态资源却正常。原因Nginx 没配置 try_filesPHP 框架入口没有接管虚拟路径。Apache 的 .htaccess 对 Nginx 不生效。解决在 server 块里加上location / { try_files $uri $uri/ /index.php?$query_string; }注意这一行的顺序可以微调当你的路由需要带 query 参数时写/index.php?$query_string而不是/index.php否则控制器拿不到 GET 参数。另外如果源码跑在子目录/ticket/下try_files 里也要改成/index.php?$query_string否则请求总是落到根目录。5.4 并发下单后库存对不上现象抢票模拟 20 个并发最终 sold_tickets 比总库存多或者负库存。原因代码写成了“先 SELECT 库存再在 PHP 里判断库存是否大于 0然后 UPDATE”这个判断和更新之间没有原子性多个请求同时通过判断。还有一种原因是超时取消脚本与支付回调同时执行库存被回补两次。解决把库存扣减改成带条件的原子 UPDATE并检查影响行数$affected $db-execute( UPDATE ticket_type SET stock stock - :n WHERE id :id AND stock :n, [n $qty, id $ticketTypeId] ); if ($affected 0) { throw new BizException(库存不足); }每次下单只允许真正扣减成功的请求继续写订单表其他请求直接失败。再强调一次所有库存回补操作前都必须用 UPDATE 影响行数判断原订单状态不能只靠 SELECT 判断。5.5 订单已扣款但后台状态仍是“待支付”现象用户用微信扫码付了钱回到订单页一直显示待支付甚至过一会儿被超时脚本取消了。原因回调请求没能到达服务器。常见三处回调 URL 写成了 http但微信支付要求 https服务器防火墙拦了陌生 UA代码里回调入口被加了登录鉴权支付渠道没有 session 直接 302 跳转。解决把回调路由加进白名单关闭该路由的登录拦截改为验签。然后在回调入口临时加一行日志error_log(json_encode([ post $_POST, header getallheaders(), ])); file_put_contents(/tmp/pay_callback.log, $payload, FILE_APPEND);如果日志文件长期为空说明请求根本没进 PHP去查服务器访问日志确认渠道是否定访问到你的地址。回调处理成功后一定要用exit(success)输出纯文本才退出不要 echo JSON 或跳转否则渠道会认为回调失败并反复重试。6. 上线前最后一道工序功能验证与安全加固源码改到能跑业务之后别急着上线。我习惯在最后一步固定做三件事全流程回测、安全加固、数据库备份。功能回测别只测“下单→支付→查看订单”要测全状态流转创建订单后不支付等超时看库存是否回补支付回调重复推送两次看是否会重复改订单退款后再次下单看限额和库存释放。用一个简单脚本模拟并发下单能帮你提前看到超卖问题for i in {1..50}; do curl -X POST -s http://127.0.0.1:8080/order/create \ -d {session_id:1,ticket_type_id:1,quantity:1} done wait脚本跑完去 MySQL 查 ticket_type 表的 stock如果接近负数那就要回上一章把原子扣减补上。安全加固方面这套源码常见的薄弱点是后台路径没有限流、上传目录可执行 PHP、SQL 查询在个别功能里用了字符串拼接。我一般会做四件最小改动// 入口处统一过滤输入去掉 NULL 字符和多余的空白 $_GET array_map(trim, $_GET); $_POST array_map(trim, $_POST);上传目录在 Nginx 中禁止解析 PHP文件上传后强制重命名为带随机串的文件名。后台登录接口加验证码和 IP 频率限制。数据库备份脚本只保留最近 7 天每天凌晨执行一次mysqldump。这套源码对我最大的价值不是上的 tickets 表有多复杂而是把票务里“强库存、强时效、多渠道对账”这几个核心问题完整演示出来了。从那以后我每次拿到一套 PHP 票务源码都会先强制走一遍“环境检查、开事务、验签、状态机核对”四步确认能完整重现交易链路后再谈二次开发。这样做的结果是上线后出问题的概率低了很多希望你也能从这个源码里收获同样的手感。本文还有配套的精品资源点击获取