卡密这件事我写了两年：2019 年写在网页里，2025 年搬进 Telegram 又写了一遍

2019 年 7 月，我发布了星空云发卡系统。它是用来在线卖卡密的：生成卡密、管库存、买家付款后自动发货，三件事做成一套系统。但要说这套逻辑的根在哪，得往前翻到 2018 年。

骨架是商城给的

2018 年 6 月，星空云商场上线，这是我第一套自己从头写完的商城，商品、订单、发货一条链全部落地。2018 年 10 月出了星空云商场 Pro，是它的加强版，模板体系和多商户场景在这版补齐。后面所有系统都从这套骨架上长出来，发卡系统也不例外——它说到底就是把商城里「发货」那一环，从发实物换成了发卡密。剩下的难处，全在卡密自己身上。

卡密的技术内核，就四件事

看着只是生成一串字符串，实际要处理生成、扣减、发货、对账四个问题。

生成：批次加规则。后台建批次，定前缀、长度、字符集，一次批量生成几千上万条入库。字符集要手动避开容易混淆的 0 和 O、1 和 l；卡密字段建唯一索引，重复的根本插不进去。批次各自独立：出了多少、剩多少、卖给了谁，查一个批次就清楚。

扣库存：必须原子。库存不是一个可以随便减的数字，而是「从批次里取出一条未售卡密、标记成售出」这个动作。热门商品会撞并发：最后一张卡两个人同时下单。做法是取卡和落订单放在同一个事务里，取的时候带上状态条件，抢输的那边直接失败重来。一张卡只会落到一个订单头上。

发货：回调驱动，得做幂等。付款回调进来，从批次取一张卡写进订单，页面展示卡密，整个过程不到一秒。坑在回调会重复到达：网络超时重发、对方重试，处理不好一张卡发两次。所以拿订单号做幂等键，同一个订单的重复回调只发一次卡，后面进来的只回结果。

对账：三份账互相对。订单状态、卡密状态、批次剩余数量，理论上要一一咬合。但异常会让它对不上：扣了卡订单没落，落了订单卡没标出去。我挂了个定时任务定期对账，超时未支付的订单把占用的卡退回批次，对不上的记进后台异常列表，留着人工处理。

2023 年开源，这套东西歇了一阵

2023 年 6 月，我把星空云商城和星空云发卡一起免费开源放了出去，和 TG 云支付停售是同一时间。代码散到别人手里继续跑，我自己这边，这套发卡逻辑暂时停了下来。

2025 年，搬进 Telegram 重写一遍

2025 年 9 月，TG 发卡上线。它是把发卡系统和商城搬进 Telegram 的机器人，配套小程序一起发布，用户不用离开 TG 就能下单发货。形态变化比想象中大：

• 会话即下单。原来要商品页、下单页、收银台三个页面来回跳；现在商品是一张消息卡片，点开选规格，按确认就成单，全程没离开聊天窗口。
• 消息即发货。原来卡密显示在「购买成功」页上，手快刷新丢了还得查订单；现在卡密直接发到会话里，丢了可以重推。
• 付款、通知、售后都在同一个会话里完成。小程序只补了批量建批次、看库存这类需要大屏幕的操作。

但拆开看，内核一点没变：批次生成、唯一索引、事务扣卡、回调幂等、定时对账，全按 2019 年的口径在新代码里重写了一遍。变的只是进出口——触发扣库存的从网页订单变成了机器人消息，发货从渲染页面变成了往会话发一条文本。

回头数一下，同一件事我确实写了两遍。第一遍解决的是「卖卡密不用人工盯」，把发货从手工复制粘贴里剥出来；第二遍解决的是「卖卡密不用打开网页」，把整条链从浏览器里剥出来。表单会消失，页面会消失，卡密还是那四件事：怎么生成、怎么扣、怎么自动发、怎么对得上。