咨询独立开发的大佬一个问题, 大佬们的兑换码都是怎么处理的?

批量生成存数据库

第二种假设秘钥漏了你不炸了

@walle1530 哈哈哈哈 我也觉得不太合适 但是有个想法想验证下

记得前前同事用 uuid.md5.hashCode/100000 结果上线三个月后重复了

@spritecn 为啥用哈希做兑换码, 我认知中哈希只能用来做验证啊, 还不如用个 uuid

@JoeJoeJoe 就是个随机 id,但需求方要求是纯数字

@spritecn #6 我也没整过这种兑换码, 不晓得现在主流做法是啥, 但是用哈希这种不唯一的生成之后, 得做下校验吧.

ps: 有没有大佬介绍下现在主流的兑换码实现方案?

批量生成兑换码，保存到数据库，同时兑换码本身带有部分校验逻辑（如校验位、活动标识）。核销时既能快速查表，又能做基础校验，避免误输和伪造。

存到数据库更稳妥，一则如楼上所说更安全，二则可以方便地控制兑换码，比如停用某个兑换码。你用 key 解析的话，后续想加限制就得改代码

同意 8 楼说法，本身带校验位可以让你快速判断兑换码是否合法，但是实际是否有效还应该以数据库中的内容为准。

你有一个私钥
你的程序内置对应的公钥
程序安装后根据设备信息生成一个唯一编码
用户拿着唯一编码找你，你用私钥对唯一编码签名，拿到一个签名字符串（兑换码）
用户在程序中输入这个兑换码，程序通过内置的公钥验证签名确定这个兑换码有效

为了区分不同等级的兑换码，你可以拥有多个不同级别的私钥，在你的程序中内置多个不同的公钥。程序通过判断签名是哪个私钥的签名来确定这个兑换码的级别。

比如这个兑换码有 32 字节，前面 16 字节是随机数 A ，后面 16 字节 B=hash(A+C+salt1)，服务器存随机数 A, 随机数 C, 验证哈希 D=hash(B+salt2)
把兑换码印刷之后，就可以把 salt1 记在小本本上，然后把 B 从数据库中删掉。
简单的校验可以是限定随机数 A 具有某些性质，比如某两位和必须为固定值。

设计比较简单，活动标识 3 位-渠道标识 3 位-10 位随机字符串 存数据库

之前用 cursor 写过，提供的方案是后端数据库一个兑换码表，批量生成唯一值，哪个用户兑了就标记已兑状态，实现不难。

@0x93ee 以前很多共享软件就是这么做的。

生成 uuid 然后存库 并对字段做唯一约束

只存数据库，不用搞什么校验位，兑换码这种功能请求量太少了，给上个索引，你数据库 CPU 都上不了 1%，
10000 以内的直接创建， 创建的时候唯一索引，太多开个队列创建就好了，加个批量创建批次码很管用，经常让查
兑换的时候加个乐观锁

用 guid 最好，注意不是 uuid ，uuid 单个位只能是 16 进制数字范围，容量比 guid 小很多

不过注意，兑换接口一定要防止穷举，错误到一定次数 ban 掉

@opengps 穷举 guid 吗。。有这算力去挖矿不是更好

@fdd92 #20 你能让攻击者也这么想吗？显然做不到，所以网络防护必须得有所应对