卡密系统实战：用卡密做付费邀请码与兑换码

卡密系统在社区里本质是一条流水线：一串密钥 → 一次性核销 → 统一记账入账。想用它做付费邀请码和兑换码，关键是分清两件事——卡密负责"给钱/给额度"，邀请码负责"给注册资格"，两者在 Clara BBS 后台是两个独立管理入口，运营上组合、系统里不混批。

先把三个概念拆开，别一上来就生成卡密

结论：卡密是载体，兑换码是卡密的一种用法，邀请码是另一套东西。

卡密（后台「卡密」管理）生成的是一批"卡号+密钥"，用户在前台兑换后走系统的统一记账，落到后台「货币管理」里你定义好的某一种货币上。所以"兑换码"不是一个独立模块，它就是卡密最常见的用途。

邀请码（配合后台「系统设置→注册邀请」与「邀请码」管理）管的是注册门槛：开启邀请注册后，没有邀请码就注册不了。这意味着它的作用点是"谁能进站"，而不是"给多少钱"。

结论：卡密决定用户能拿到多少货币，邀请码决定用户能不能进来，两个入口分开管、分开导出，是最省心的做法。

路线一：卡密当兑换码，四步跑通

结论：只做站内消费闭环的话，卡密是零开发成本方案。

1. 后台「货币管理」先建好货币，明确这批兑换码对应哪种货币、什么面额。
2. 后台「卡密」批量生成，导出卡号密钥文件——导出文件不要放在网站公开目录，这是最常见的泄露口子。
3. 用户在站内兑换，系统按统一记账入账，余额到账。
4. 余额的去向：购买全文出售的付费帖、购买带价格的附件、发悬赏（发布即托管冻结）、送礼物打赏、用户间转账（费率、限额、每日次数后台可配）。

注意点有两个：一是兑换码核销后就失效，多渠道售卖时别把同一批卡密重复发给不同买家；二是兑换这类行为可以挂到「积分规则」上，顺手给经验或其他货币，做二次激励。

路线二：卡密做付费邀请码，分清"付款"和"发票"

结论：付费邀请码的实质是"先收钱、再发票"，卡密承接的是付款核销这一环，邀请码一定要单独生成。

后台「卡密」面板生成的是货币兑换卡密，它不会直接吐出一枚邀请码——这是很多人踩的第一个坑。落地有两种做法：

半自动：先在「邀请码」里批量生成邀请码并留存，同时生成对应的卡密批次当付款凭证。用户买到卡密、完成兑换（或凭卡密联系你核销）后，你按批次对应把邀请码发出去。批次号和邀请码一一对应做好表格，对账不会乱。

全自动：写一个小插件放到 content/plugins，利用运行时钩子，在卡密兑换成功后自动触发邀请码发放。Clara BBS 的插件是运行时钩子加载、保存即生效，不用编译、不用清缓存，改动成本很低。

结论：只要你的流程里出现"卡密兑换后自动发邀请码"，就一定需要一个自写插件来桥接，系统自带的卡密和邀请码是两条不相交的线。

三个必须提前想清楚的点

结论：卡密系统的风险不在功能，而在发放和售后。

第一，边界要交代清楚。兑换码换到的是后台定义好的货币，不是"任意权益"。会员套餐的 6 项权益（表情包/图片上传/AI 助手/隐私/编辑/内容权限）是在后台套餐里勾选配置的，跟卡密兑换不是一回事，别在商品页写"买卡密送会员"却指望系统自动开通。

第二，库存和有效期管理靠批次，不靠记忆。生成时按用途、按渠道分批次，卖完即止，别一次性导出全站卡密。

第三，售后对账依赖统一记账。转账、悬赏、礼物、附件交易、卡密兑换都走同一套账，出问题时从货币流水往回查，比翻聊天记录快得多。

一句话收束：把卡密当"发钱的口子"、把邀请码当"进门的票"，两条线各自批量生成、各自留档，中间的自动化环节用一个运行时钩子插件补齐——这就是卡密系统做付费邀请码和兑换码最稳的落地方式。