Dujiao-Next 自动发卡系统

如果你做过数字商品的在线销售——卡密、激活码、会员订阅、虚拟服务之类的——大概率听说过[[独角数卡]]（Dujiaoka）。这个基于 [[Laravel]] 框架的开源自动发卡系统在 GitHub 上积累了接近 12000 个 Star，是中文开源社区里最知名的发卡平台之一。我自己也用过一段时间，整体功能完整，但作为一个 PHP 项目，在部署和性能方面确实有一些让人头疼的地方。

最近发现原作者 assimon 做了一件大事——用 [[Go]] 语言从零重写了整个系统，推出了全新的 Dujiao-Next。从 2026 年 2 月创建仓库到现在，已经迭代到了 v0.1.8 版本，更新频率非常高，基本上两三天就有一个新版本。虽然还处于早期阶段，但架构上的变化非常值得关注。

为什么要重写

先说说旧版独角数卡的情况。原版基于 PHP 的 Laravel 框架开发，后台管理使用 laravel-admin，前端用 [[Bootstrap]]。这个技术栈在功能实现上没有问题，独角数卡也确实做到了开箱即用、支持多种支付渠道、自定义模板等核心功能。但随着用户量的增长和需求的变化，PHP 技术栈的一些固有限制逐渐暴露出来。

部署复杂度是第一个痛点。跑一个 Laravel 项目，你需要 PHP、Composer、Nginx/Apache、MySQL、Redis、Supervisor 这一整套环境。对于有运维经验的人来说不算什么，但对于很多只想快速搭一个发卡站的站长来说，光是配置 PHP 版本、安装扩展、设置定时任务就能折腾半天。虽然后来有了 Docker 方案，但底层的复杂度并没有真正降低。

性能是第二个问题。PHP-FPM 的进程模型在高并发场景下的表现有限，对于一个需要处理支付回调、实时库存扣减、并发订单的系统来说，Go 的协程模型天然更适合。特别是在秒杀或者批量下单的场景下，这个差异会比较明显。

前后端耦合是第三个问题。旧版使用 Blade 模板引擎做服务端渲染，前端和后端代码混在一起。想换一套前端界面，需要深入理解 Laravel 的模板机制和路由规则。对于想做二次开发或者自定义界面的用户来说，门槛不低。

Dujiao-Next 的技术架构

新版 Dujiao-Next 在架构上做了彻底的重新设计。整个系统被拆分成了四个独立的仓库，各自独立开发和部署。

服务端（dujiao-next/dujiao-next）使用 Go 语言编写，Web 框架选用了 [[Gin]]，ORM 使用 [[GORM]]，数据库支持 [[SQLite]] 和 [[PostgreSQL]]。整个后端是一个纯粹的 REST API 服务，不再承担任何前端渲染的职责。这意味着你可以用任何前端框架来对接这套 API，甚至可以只通过 API 调用来管理你的发卡业务。

用户前台（dujiao-next/user）使用 [[Vue]] + [[TypeScript]] 开发，是一个独立的单页应用。用户浏览商品、下单支付、查看订单、管理钱包等操作都在这个前端完成。因为是独立项目，替换前端界面变得非常简单——你甚至可以用 React 或者其他任何框架重新写一个前端，只要对接同一套 API 就行。

管理后台（dujiao-next/admin）同样是 Vue + TypeScript 的独立项目，提供商品管理、订单管理、支付配置、系统设置等后台功能。

文档站（dujiao-next/document）包含了完整的部署教程和使用指南。

这种三端分离的架构设计，比旧版的 Laravel 全栈模式灵活得多。每个部分都可以独立升级、独立部署、独立扩展。如果你只想换一个好看的前台界面，完全不需要碰后端代码。

核心功能

虽然 Dujiao-Next 还在快速迭代中，但核心的发卡业务功能已经相当完整。从发布历史来看，团队的开发节奏非常紧凑，从 2 月底的 v0.0.5-beta 到 3 月底的 v0.1.8，每个版本都有实质性的功能新增和问题修复。

商品和库存管理

支持多级分类、SKU 级别的库存管理和定价。你可以为同一个商品设置不同规格的 SKU，每个 SKU 有独立的价格、库存和卡密池。库存告警功能会在卡密数量低于阈值时发出通知，避免出现售罄无货的尴尬情况。v0.1.7 版本还新增了成本价功能，可以在后台直接看到每个商品的利润情况。

卡密的管理也做了优化。支持批量导入，对大量卡密的处理做了专门的性能优化（旧版在卡密数量多的时候批量导入会失败，新版已修复）。卡密搜索支持忽略大小写，方便快速定位特定卡密的状态。

支付渠道

这是发卡系统的命脉。Dujiao-Next 目前支持的支付方式包括：

  • [[支付宝]]（当面付、手机支付、PC 支付）
  • [[微信]]支付
  • [[PayPal]]
  • [[Stripe]]
  • 易支付（通用彩虹版）
  • [[USDT]] 相关支付（Bepusdt、TokenPay）
  • OKPay

v0.1.6 版本还为 PayPal 渠道增加了汇率转换和目标货币支持，对于面向海外用户的卖家来说很实用。支付系统采用了统一的抽象层设计，新增支付渠道只需要实现对应的接口，不需要改动核心业务逻辑。

用户系统

新版增加了完整的用户中心，这是旧版独角数卡比较薄弱的一个环节。用户可以注册登录（支持 [[Telegram]] 登录）、管理个人信息、查看历史订单、使用钱包余额支付。

钱包系统是 v0.0.3-beta 就上线的核心功能。用户可以预充值余额，支付时支持三种模式：纯余额支付、余额加在线支付组合支付、纯在线支付。每一笔资金变动都有明细记录。对于回头客比例高的业务场景，钱包功能能有效减少支付手续费的损耗。

v0.1.2 版本上线了会员等级系统，可以根据消费金额自动升级会员等级，不同等级享受不同的折扣优惠。这对于提升用户黏性和复购率很有帮助。

站点对接和分销

这是一个比较有特色的功能。Dujiao-Next 支持多级站点对接，你可以把自己的商品通过 API 同步到下游站点，下游站点直接售卖你的商品。v0.1.6 版本增强了这个功能，支持商品自动加价调价、自定义汇率转换，让上下游之间的价格策略更灵活。

v0.0.7-beta 版本还新增了推广返利模块，支持推广员制度。

Telegram Bot 集成

从 v0.1.0 开始，Dujiao-Next 逐步完善了 [[Telegram]] Bot 的集成。不仅支持 Telegram 登录，还支持通过 Bot 进行群发消息、订单通知等操作。后续版本还优化了 Telegram 管理页面，修复了支付业务 ID 暴露的安全问题。

其他功能

  • 自定义导航和博客功能（可配置开关）
  • 订单通知邮件模板自定义
  • 支付回调日志追溯
  • 礼品卡功能
  • 自定义 JS 代码注入
  • 促销活动价设置（SKU 级别）

部署方式

Dujiao-Next 提供了三种部署方式：手动部署、Docker Compose 部署和 aaPanel 可视化部署。

对于大多数用户来说，[[Docker]] Compose 是最推荐的方式。Go 编译出来的是一个单独的二进制文件，不需要像 PHP 那样依赖一堆运行时环境。整个服务端就是一个可执行文件加一个配置文件，配合 Docker 部署极其简单。数据库默认支持 SQLite，对于中小规模的站点来说甚至不需要额外部署数据库服务——这和旧版必须依赖 MySQL + Redis 的架构相比，运维成本大幅降低。

如果你的业务量较大，可以切换到 PostgreSQL 作为数据库后端，获得更好的并发性能和数据管理能力。

手动部署也很直接，安装 Go 环境后，go mod tidy 拉依赖，go run cmd/server/main.go 就能启动服务。对于想做二次开发的开发者来说，这个上手门槛比 Laravel 项目低不少。

与旧版独角数卡的对比

维度 旧版独角数卡 Dujiao-Next
语言 PHP (Laravel) Go (Gin + GORM)
前端 Blade 模板 + Bootstrap Vue + TypeScript（独立项目）
架构 全栈单体 前后端分离，API/User/Admin 三端
数据库 MySQL（必需）+ Redis（必需） SQLite（默认）/ PostgreSQL
部署 PHP + Composer + Nginx + MySQL + Redis + Supervisor 单二进制 + 配置文件，Docker 一键
用户系统 基础 钱包、会员等级、Telegram 登录
站点对接 无 多级站点对接、自动调价、汇率转换
开源协议 MIT GPL-3.0
GitHub Star 约 12000 约 250（新项目）

需要注意的一个变化是开源协议从 MIT 改成了 GPL-3.0。这意味着如果你基于 Dujiao-Next 做二次开发并分发，需要同样以 GPL 协议开源你的修改。对于纯粹自用部署的场景没有影响，但如果你打算做一个闭源的商业化版本，需要留意这个许可证的约束。

当前状态和注意事项

截至目前，Dujiao-Next 已经发布了 18 个版本（从 v0.0.1-beta 到 v0.1.8），项目处于活跃开发状态，更新频率很高。从版本号和 beta 标记来看，项目还没有到 1.0 正式版的阶段，功能还在快速增加中，可能会有一些不稳定的情况。

从 release notes 来看，最近几个版本的重点在安全加固（增强支付回调验证防注入攻击）、功能完善（成本价计算、会员等级）和 bug 修复（批量导入、权限问题、库存告警）上。开发者对安全问题的响应速度值得肯定，v0.1.4 就专门修复了易支付回调验证的注入攻击风险。

如果你目前正在使用旧版独角数卡，不建议立即迁移到 Dujiao-Next。两个版本的数据结构和架构完全不同，没有官方的迁移工具。等 Dujiao-Next 进入 1.0 正式版并且提供了数据迁移方案之后再考虑切换会更稳妥。

如果你是新搭建发卡站，Dujiao-Next 是一个值得尝试的选择。Go 语言带来的部署便利性和性能优势，加上前后端分离的现代化架构，在同类开源产品中有明显的竞争力。

最后

独角数卡从 PHP 到 Go 的重写，不只是换了一门语言那么简单。前后端分离让系统的可维护性和可扩展性上了一个台阶，SQLite 的默认支持让部署门槛降到了最低，用户系统和站点对接功能的补齐让产品的商业可用性更强。

开源自动发卡系统这个赛道里，旧版独角数卡凭借 12000 个 Star 已经证明了市场需求的真实存在。Dujiao-Next 用更现代的技术栈重新回答了同一个问题——如何让个人站长和小团队用最低的成本搭建一个稳定、高效的数字商品销售平台。虽然新版还在早期阶段，但从更新速度和功能完成度来看，成为旧版的全面替代只是时间问题。

相关链接