简介：这份爱发发卡网源码是一套基于PHP的自动发卡平台商业源码，面向希望快速搭建数字商品销售站点的开发者与创业者，可用于游戏点卡、会员激活码、虚拟货币等虚拟商品的在线自动售卖。系统已集成支付宝、财付通、微信支付、QQ钱包等主流官方接口，并接入易宝、云支付等第三方通道，支付选择较为多元；同时具备防SQL注入、XSS过滤与订单数据加密等安全机制，支付完成后自动生成并展示卡密，减少人工干预。压缩包共约2000个文件，整体32.4MB，以gif、png、jpg等图片素材和php脚本为主，另含js、css、html等前端资源，以及少量asp、aspx、dll、bat、sh等辅助文件，覆盖前端模板、后台管理、数据库配置与支付SDK等模块。目前已有1674人学习下载，适合熟悉PHP与Web开发的个人或团队在此基础上定制支付方式、调整界面布局或优化性能，快速落地符合自身业务需求的发卡系统。
1. 自动发卡平台源码到底在解决什么问题
如果你手上有一批虚拟商品——软件激活码、会员充值卡、课程兑换码、游戏点卡——却还在用人工核对订单、手动复制卡密、微信里一条条发，那这套 PHP 自动发卡平台源码就是冲这个场景来的。它的核心逻辑很朴素：买家下单付款，系统从卡密库里按规则取一条未售出的卡密，自动展示或发到买家邮箱，同时把这条卡密标记为已售，整个过程不需要人盯着。标题里的「爱发发卡网源码」本质是一套基于 PHP 的轻量级电商系统，只不过商品不是实物，而是字符串形式的卡密。它适合个人开发者、小团队、做虚拟资源分销的从业者，尤其是那些不想上大型商城、只想快速搭一个能收钱能发卡的站点的人。这套源码能不能直接用、部署要几步、卡密并发怎么不重复发，是接下来要一层层拆开的东西。
2. 把源码跑起来之前，先看清它的骨架
拿到一个xxx.zip压缩包，很多人第一反应是解压丢到网站根目录，浏览器一开，白屏或者报错，然后开始怀疑源码有问题。实际上自动发卡平台的运行依赖比普通博客复杂，它要处理支付回调、卡密库存、订单状态机，任何一个环节配置不对都跑不通。这一章先把骨架拆开，让你知道每个目录在干什么，再动手部署。
2.1 目录结构与核心文件职责
解压之后，典型的自动发卡平台源码会长这样（不同版本命名有差异，但职责大同小异）：
/ 根目录 ├── admin/ 后台管理入口 ├── api/ 支付回调、异步通知接口 ├── config/ 数据库、站点、支付配置 ├── core/ 核心类库（数据库封装、订单处理、卡密抽取） ├── install/ 安装向导（部分版本有） ├── template/ 前台模板 ├── upload/ 卡密文件、商品图片上传目录 └── index.php 前台入口core/是整站的心脏，里面通常有一个Order.class.php或类似文件，负责「创建订单 → 锁定卡密 → 支付成功 → 释放卡密」这条链路。api/目录下的文件是支付平台异步通知的落点，比如notify.php，它必须能在没有登录态的情况下被外部访问，同时要验签。config/里一般有一个database.php和一个config.php，前者填数据库连接，后者填站点域名和支付参数。
我一般会先打开config/看配置项，再打开core/看订单处理逻辑，最后才去动模板。顺序反了容易在模板里改半天，结果发现是卡密抽取逻辑有并发缺陷。
2.2 环境要求与依赖检查
PHP 自动发卡平台对环境的硬性要求集中在三点：PHP 版本、MySQL 版本、伪静态支持。
| 组件 | 常见要求 | 检查命令 |
|---|---|---|
| PHP | 7.2 ~ 8.0（部分老源码只支持 5.6） | php -v |
| MySQL | 5.6+ / MariaDB 10.2+ | mysql --version |
| Web 服务器 | Nginx 或 Apache，需支持 rewrite | nginx -v |
| 扩展 | pdo_mysql、curl、openssl、mbstring | php -m |
用宝塔面板的话，直接在软件商店装 PHP 7.4 和 MySQL 5.7，然后在 PHP 设置里把pdo_mysql、curl、openssl勾上。命令行检查扩展：
# 列出已加载的 PHP 扩展，确认关键扩展存在 php -m | grep -E 'pdo_mysql|curl|openssl|mbstring'如果输出里少了任何一个，去php.ini里把对应扩展前面的分号去掉，重启 PHP-FPM。这一步不做，后面安装向导会卡在数据库连接或者支付回调验签失败，报错信息还不一定直白。
2.3 数据库导入与配置文件修改
源码包里通常带一个.sql文件，在install/或者根目录。导入之前先建库：
-- 创建数据库，字符集用 utf8mb4 避免卡密里的特殊字符乱码 CREATE DATABASE card_platform DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 创建专用用户，不要直接用 root CREATE USER 'card_user'@'localhost' IDENTIFIED BY '换成你的强密码'; GRANT ALL PRIVILEGES ON card_platform.* TO 'card_user'@'localhost'; FLUSH PRIVILEGES;然后导入表结构：
# 把 sql 文件导入刚建的库，-p 后面回车输入密码 mysql -u card_user -p card_platform < /path/to/install.sql导入完成后，编辑config/database.php：
<?php // 数据库连接配置，host 一般本地就是 127.0.0.1 return [ 'host' => '127.0.0.1', 'port' => 3306, 'dbname' => 'card_platform', 'username' => 'card_user', 'password' => '换成你的强密码', 'charset' => 'utf8mb4', ];参数说明：host用127.0.0.1比localhost在某些环境下更稳，因为localhost可能走 socket 连接导致权限匹配不上。charset必须是utf8mb4，卡密里如果包含 emoji 或者特殊符号，utf8会截断导致卡密发出去是残缺的，这种坑我踩过，买家收到一半卡密，售后成本极高。
2.4 伪静态规则与入口绑定
自动发卡平台的前台商品页、订单页通常走index.php?c=xxx&a=xxx这种参数，为了 URL 好看和 SEO，源码会带伪静态规则。Nginx 下在站点配置里加：
# 伪静态规则，把 /product/123 这类路径重写到 index.php location / { if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?$1 last; } }Apache 下则是.htaccess文件，源码包里一般自带，确认AllowOverride All已开启即可。改完 Nginx 配置记得nginx -t测试语法，再nginx -s reload。我见过有人直接 reload 没测试，结果整个站点 502，排查半天发现是少了一个分号。
3. 卡密自动发放的完整链路怎么跑通
部署只是让站点能打开，真正决定这套源码能不能用的，是「下单到发卡」这条链路是否可靠。自动发卡平台最怕两件事：一是钱付了卡没发，二是同一张卡密发给了两个人。这一章把链路拆成下单、锁卡、回调、发货四段，每段给出可验证的做法。
3.1 下单与卡密锁定的事务处理
买家点击购买，系统要做的是：创建订单记录，同时从卡密表里选一条status=0（未售）的卡密，把它标记为status=1（锁定）并关联到订单。这两步必须在一个数据库事务里完成，否则并发下单会出现超卖。
<?php // core/Order.class.php 中创建订单的核心逻辑 $pdo->beginTransaction(); try { // 1. 插入订单，状态为待支付 $stmt = $pdo->prepare("INSERT INTO orders (product_id, user_contact, amount, status, created_at) VALUES (?, ?, ?, 0, NOW())"); $stmt->execute([$productId, $contact, $price]); $orderId = $pdo->lastInsertId(); // 2. 锁定一条卡密，FOR UPDATE 防止并发读到同一条 $stmt = $pdo->prepare("SELECT id FROM cards WHERE product_id = ? AND status = 0 LIMIT 1 FOR UPDATE"); $stmt->execute([$productId]); $card = $stmt->fetch(); if (!$card) { throw new Exception('库存不足'); } // 3. 把卡密标记为锁定并绑定订单 $stmt = $pdo->prepare("UPDATE cards SET status = 1, order_id = ? WHERE id = ?"); $stmt->execute([$orderId, $card['id']]); $pdo->commit(); } catch (Exception $e) { $pdo->rollBack(); // 返回库存不足或系统繁忙 }逻辑说明：FOR UPDATE是行级锁，保证两个并发请求不会同时读到同一条未售卡密。参数上，status字段建议用0=未售 1=锁定 2=已售 3=作废四态，比单纯用0/1更容易排查问题。如果源码里没有用事务，只是先查再更新，那在高并发下必然超卖，这是很多免费发卡源码的通病，需要自己补上。
3.2 支付回调的验签与幂等
支付平台（支付宝、微信、第三方聚合支付）在用户付款后会异步通知api/notify.php。这个接口必须做两件事：验签和幂等。
<?php // api/notify.php 简化逻辑 $raw = file_get_contents('php://input'); $data = json_decode($raw, true); // 1. 验签，防止伪造回调 $sign = $data['sign']; unset($data['sign']); ksort($data); $expected = md5(http_build_query($data) . $secretKey); if ($sign !== $expected) { exit('sign error'); } // 2. 幂等，同一笔订单重复通知只处理一次 $orderId = $data['out_trade_no']; $stmt = $pdo->prepare("SELECT status FROM orders WHERE id = ?"); $stmt->execute([$orderId]); $order = $stmt->fetch(); if ($order['status'] == 2) { exit('success'); // 已处理过，直接返回成功 } // 3. 更新订单为已支付，卡密状态改为已售 $pdo->beginTransaction(); $pdo->prepare("UPDATE orders SET status = 2, paid_at = NOW() WHERE id = ?")->execute([$orderId]); $pdo->prepare("UPDATE cards SET status = 2 WHERE order_id = ?")->execute([$orderId]); $pdo->commit(); echo 'success';参数说明：$secretKey是支付平台分配的密钥，存在config/里，不要硬编码在notify.php中。幂等判断用订单状态而不是时间戳，因为支付平台可能因为网络问题重复通知多次。返回给支付平台的必须是它约定的成功标识（通常是success字符串），否则它会一直重试，把服务器打满。
3.3 卡密展示与邮件发送的触发时机
订单状态变为已支付后，前台订单页要能展示卡密，同时如果买家填了邮箱，要发一封邮件。展示逻辑直接查cards表里order_id对应的记录即可。邮件发送建议异步，不要卡在回调里。
<?php // 发货逻辑，放在订单支付成功之后 function deliver($orderId, $pdo, $mailer) { // 查出该订单绑定的卡密 $stmt = $pdo->prepare("SELECT card_content FROM cards WHERE order_id = ? AND status = 2"); $stmt->execute([$orderId]); $card = $stmt->fetch(); if (!$card) { // 记录日志，人工介入 error_log("订单 {$orderId} 已支付但无卡密"); return false; } // 发邮件，失败不影响卡密展示 try { $mailer->send($orderId, $card['card_content']); } catch (Exception $e) { error_log("邮件发送失败: " . $e->getMessage()); } return true; }这里的关键是：邮件发送失败不能回滚订单，卡密已经在数据库里，买家刷新订单页就能看到。邮件只是锦上添花，把它做成阻塞操作是自找麻烦。我一般会把邮件任务写进一张mail_queue表，用定时脚本去消费，这样即使邮件服务挂了，也不影响主流程。
3.4 用 curl 模拟一次完整下单验证链路
部署完不要急着上生产，先用 curl 走一遍完整流程，确认每一步的返回符合预期。
# 1. 模拟下单，拿到订单号 curl -X POST 'https://your-domain.com/index.php?c=order&a=create' \ -d 'product_id=1&contact=test@example.com' # 2. 手动把订单状态改成已支付（模拟支付回调） # 实际生产环境这一步由支付平台触发，测试时直接改库 mysql -u card_user -p card_platform -e "UPDATE orders SET status=2 WHERE id=1; UPDATE cards SET status=2 WHERE order_id=1;" # 3. 查询订单，确认卡密已展示 curl 'https://your-domain.com/index.php?c=order&a=detail&id=1'如果第三步返回的 HTML 里能看到卡密内容，说明链路通了。如果看不到，去core/里看订单详情查询有没有加status=2的条件，很多源码在这里会判断订单状态，状态不对就不展示卡密。
4. 避坑：自动发卡平台最常见的五类翻车
这套源码跑通不难，难的是跑稳。下面五类问题是我在实际使用和帮人排查时遇到频率最高的，每一条都按「现象 → 原因 → 解决」写清楚。
4.1 卡密重复发放
现象：两个买家买了同一个商品，收到的卡密一模一样。原因：下单时没有用事务加行锁，两个请求同时读到同一条status=0的卡密，各自更新，后更新的覆盖了前一个的order_id。解决：按 3.1 的方式，把「查未售卡密」和「更新为锁定」放进同一个事务，查询时加FOR UPDATE。如果源码本身不支持，就在core/里找到对应方法手动改。
4.2 支付回调不生效
现象：用户明明付了钱，订单状态还是待支付，卡密没发。原因通常有三种：回调地址填错、验签失败、服务器防火墙拦了支付平台的 IP。解决：先看api/notify.php有没有收到请求（在文件开头写一行file_put_contents('notify.log', date('Y-m-d H:i:s') . PHP_EOL, FILE_APPEND);），如果日志为空，说明请求没到，检查支付平台后台的回调地址和服务器安全组。如果有日志但验签失败，核对密钥和签名算法，注意ksort排序和http_build_query的编码方式要和支付平台文档一致。
4.3 卡密文件导入后乱码
现象：后台导入卡密 txt 文件，前台展示出来是乱码或者只有一半。原因：txt 文件编码是 GBK，而数据库和页面是 UTF-8，导入时没有转码。解决：导入前用iconv转码，或者在 PHP 导入逻辑里加一行：
// 把 GBK 编码的卡密内容转成 UTF-8 $content = mb_convert_encoding(file_get_contents($file), 'UTF-8', 'GBK');另外确认数据库表和字段的字符集是utf8mb4，连接配置里也写了utf8mb4，三处一致才不会乱码。
4.4 后台登录被暴力破解
现象：后台日志里大量登录失败记录，或者某天发现卡密被批量导出。原因：后台入口路径太简单（比如/admin/），登录没有验证码和失败次数限制。解决：把admin/目录改名成一个不容易猜的路径，登录页加验证码，连续失败 5 次锁定 IP 15 分钟。这些改动在admin/的登录控制器里加几行判断即可，成本很低但效果明显。
4.5 订单状态卡在「已支付未发货」
现象：订单状态是已支付，但卡密状态还是锁定，没有变成已售。原因：支付回调里更新了订单状态，但更新卡密状态的 SQL 执行失败，或者两个更新不在同一个事务里，前者成功后者失败。解决：把订单状态更新和卡密状态更新放进同一个事务，任何一步失败都回滚。同时加一个定时任务，每 5 分钟扫描一次「订单已支付但卡密未售」的记录，自动补发并告警。
5. 让发卡平台更耐用的三个进阶习惯
跑通和跑稳之间，差的是日常维护的习惯。这一章不讲大道理，只说三个我一直在用的具体做法，每个都能直接落地。
5.1 给卡密表加一个「预占超时释放」机制
现在的逻辑是下单就锁卡，但如果用户下单后一直不付款，这条卡密就被永久锁定了，库存白白浪费。我的做法是在cards表加一个locked_at字段，下单锁卡时记录时间，然后写一个定时脚本，每 10 分钟把锁定超过 30 分钟且订单仍未支付的卡密释放回status=0。
# 定时任务，每 10 分钟执行一次，释放超时未支付的锁定卡密 */10 * * * * /usr/bin/php /path/to/cron/release_expired.php >> /var/log/release.log 2>&1release_expired.php里的 SQL：
-- 把锁定超过 30 分钟且订单未支付的卡密释放 UPDATE cards c JOIN orders o ON c.order_id = o.id SET c.status = 0, c.order_id = NULL, c.locked_at = NULL WHERE c.status = 1 AND o.status = 0 AND c.locked_at < DATE_SUB(NOW(), INTERVAL 30 MINUTE);这个机制加上之后，库存利用率明显提升，尤其是那些下单后犹豫不付的用户，不会再占着卡密不放。
5.2 用订单号做幂等键，而不是时间戳
很多源码在支付回调里用「当前时间 - 订单创建时间 < 5 分钟」来判断是否重复通知，这个逻辑在服务器时间不准或者支付平台延迟通知时会翻车。正确做法是用订单号做幂等键：回调进来先查订单状态，已经是已支付就直接返回成功，不再重复处理。这个判断成本极低，但能避免 90% 的重复发货问题。
5.3 每天备份卡密表和订单表
自动发卡平台的数据价值全在卡密和订单上，丢了就真没了。我的习惯是每天凌晨用mysqldump备份这两张表，保留最近 7 天。
# 每天凌晨 3 点备份 cards 和 orders 表 0 3 * * * mysqldump -u card_user -p'密码' card_platform cards orders | gzip > /backup/card_$(date +\%Y\%m\%d).sql.gz备份文件不要放在网站根目录下，放到一个 Web 访问不到的路径，否则等于把卡密库公开了。恢复的时候直接gunzip再mysql导入即可。
最后说一个我自己的教训：早期图省事，把卡密直接存在upload/目录下的 txt 文件里，结果某次服务器迁移，upload/被当成临时文件清掉了，损失了一批卡密。从那以后，所有卡密一律入库，文件只做导入用，导入完就删。这个习惯看起来笨，但省心。希望帮到你。
本文还有配套的精品资源，点击获取
