kamiFaka（中文名佰阅发卡，MIT 协议，2300+ star）是 Vue3 + Flask 构建的卡密发卡系统：前台逛店下单，后台走 /admin，支付回调后自动出货。README 给的场景是电子券、论坛邀请码、充值卡、注册码、CDK 这类虚拟商品，还带 2 到 4 层的分层批发模式。
是什么
README 列的能力：集成支付宝当面付、微信官方、Payjs、虎皮椒、YunGouOS、易支付、Mugglepay、Stripe 等十几种支付接口；普通用户用邮箱或短信收货，管理员通知覆盖邮箱、短信、TG、微信、QQ；数据库可分离，兼容 MySQL、PostgreSQL 和 SQLite；长卡密导出 txt；列表/卡片/宫格三种主题；JWT 认证；Limter 做访问频率限制。首页库存提示的做法在源码注释里写明：按商品名对卡密计数，可重复卖的卡恒算充足，计数为 0 判缺货。要先说清一件事：README 里开源版 v1.8 和「专业版 v2.0」是两套东西，专业版不在这个仓库，功能列表两边混着写，读代码以仓库实际为准。
技术栈与部署
README 明写的依赖：前端 UI 用 Stisla，交互层 Vue 3，后端 Flask，管理员接口 Flask-JWT。线上最快路径是官方 Docker 镜像：
docker run --name kmfaka -itd -p 8000:8000 baiyuetribe/kamifaka:latest
# 卸载
docker rm -f kmfaka && docker rmi -f baiyuetribe/kamifaka:latest后台路径 /admin，默认管理员 admin@qq.com、密码 123456。源码二改走 README 链接的《开发环境安装教程.md》。Python 具体版本要求 README 没写，得自己试。
值得抄的三点
一、TempOrder 与 Order 两张表的两段式订单。下单先落 TempOrder（out_order_id、status=False），支付回调 notify_success 只认领 status=False 的记录，先把状态翻真再生成正式订单；make_order 第一行判断 Order 表里是否已有同 out_order_id——有就直接返回。回调重复打多少次，只可能出一单，幂等靠「查存在性」实现，不靠消息队列。
二、reuse 字段决定的两类卡。Card 表只有 prod_name、card、reuse、isused 四个业务字段。reuse=True 的卡表示同一张可以反复卖，多件订单直接按数量拼字符串，源码注释里留了性能记录：几十万份的拼接只花几十毫秒；不可复用的卡 filter_by(isused=False).limit(nums) 一次拿多张再逐条翻状态，拿不够数就补空位并记「已缺货」日志。注释里保留了写法的迭代过程，读起来能看出作者在什么量级上换的方案。
三、支付适配器统一成同一形状。service/util/pay/ 下每个渠道一个目录，各自实现 create_order(商品名, out_order_id, 金额) 这组签名，pay_url 按渠道名分发，新增一个渠道的改动量是一个分支加一个文件。通知路由靠 contact 字段格式推断：正则命中手机号走短信，否则走邮箱，管理员侧按 Notice 表逐渠道开关派发。邮箱/短信/TG 通知丢给 ThreadPoolExecutor 后台执行，每路通知单独 try/except，通知服务故障不拖发货主流程。
别踩的坑
一、占卡是「先查 isused=False 再更新状态」，没有行锁也没有原子 UPDATE，两个并发回调命中同一张未用卡时可能重发。README 没写承载上限，别直接当高并发成品用。
二、代码里留着大段被注释掉的实验实现（主动查单接口、旧的批量更新写法），有的已废弃；读的时候以当前生效分支为准，别把废弃逻辑抄回自己项目。
三、缺货订单在返回里用空值占位，前端轮询怎么解析残缺订单，README 没讲协议细节，得自己读用户端接口。四、notify_success 出异常只 print 加写日志，不向支付回调方返回失败信号，发货挂了上游没有感知，只能靠用户查单兜底，这类静默失败建议自己加告警。
许可证
README 的授权说明写得很直接：MIT 协议，可免费使用、复制、修改，但要求保留页面底部作者信息和 License 声明。它比标准 MIT 多了一句署名要求，商用部署时把底部信息抹掉不符合作者的明示要求。
暂无评论内容