购物网站怎么生产卡密信息

```html

你在电商平台下单买一张100元话费充值卡，购物付款成功后页面立刻弹出一串16位字母数字组合——这就是网站卡密。它不是生产从某个仓库里“捡”出来的，而是卡密系统在几毫秒内现场算出来的。

我拆过几个小平台的信息卡密生成逻辑，最粗暴的购物做法是：运营在后台设置好“面额100元、数量500张、网站有效期3年”，生产点击生成。卡密服务器调用一个随机字符串函数，信息比如用Python的购物secrets.token_hex(8)，生成类似a3f9c2e1b7d4086f的网站十六进制串。然后拼上平台前缀，生产比如JD100-，卡密变成JD100-a3f9c2e1b7d4086f。信息这就算一张卡密。500张就是循环500次，每生成一张就往数据库的card_secrets表里插一条记录，字段包括卡号、密码、面额、状态（未使用/已锁定/已作废）、绑定订单号（如果已售出）。

但纯随机有个坑：可能撞车。两个用户拿到同一串字符怎么办？大平台不会只靠随机。他们会用“卡号+校验位”的算法。比如卡号前12位是随机码，第13位是前12位通过Luhn算法算出的校验值。用户输入时，前端先校验第13位对不对，不对直接报“卡密无效”，根本不用查数据库。这能挡掉一大半乱输的请求。我见过一个日订单十万级的平台，数据库里卡密表用card_no做唯一索引，插入时如果重复就自动重试，重试三次还冲突就报警——实际上一年也碰不到一次。

更关键的是“预生成”和“实时生成”的区别。卖视频会员月卡这种标准化商品，平台通常提前生成一批卡密，比如一次性生成10万张，存进数据库。用户下单后，系统只是从“未使用”状态里挑一张，标记为“已售出”，然后返回给用户。这叫预生成，好处是快，坏处是占存储——10万条记录不算什么，但如果是千万级呢？所以有些平台改用“实时生成+加密签名”。用户付款成功那一刻，服务器用密钥对“订单号+时间戳+随机数”做HMAC-SHA256，取前16位作为卡密。这样不用存卡密本身，只存订单和密钥。用户兑换时，服务器重新算一遍签名，对比是否一致。我试过某小众发卡网，它的卡密就是ORDER123-7f3a9c2e这种格式，后半段明显是哈希值。这种方案省数据库，但密钥泄露就全完了。

还有个细节：卡密里的字符集。纯数字容易被暴力猜解，纯字母容易混淆（比如0和O，1和l）。所以很多平台用“去混淆字符集”：23456789ABCDEFGHJKLMNPQRSTUVWXYZ，去掉0、1、I、O。生成时从这32个字符里随机取。32^16约等于1.2e24，暴力穷举不现实。但如果你只生成8位，那就只有32^8约1.1e12，用GPU集群几小时能跑完。所以短卡密必须配合频率限制——同一IP每分钟最多试5次，否则封禁。

最后说个真实案例。去年有个做游戏点卡的朋友，图省事用Math.random()生成卡密。结果JS的随机数种子被预测，有人写脚本批量猜出了几千张未使用的卡密，损失十几万。后来他换成crypto.randomBytes，并且每张卡密绑定一个一次性兑换令牌，才算堵住。所以卡密生产不是“随便生成一串字符”，它背后是随机性、唯一性、防碰撞、防猜测、存储成本、兑换效率的平衡。你每次点“立即购买”后看到的那串码，背后可能跑了几十行代码和两三张数据库表。