卡密核销系统开发

项目背景

这是一组用 Go 写的平台类项目，共 2 个仓库。一个是元数据底座，提交 25 次，带 Docker 部署配置，仓库内有 12 篇文档；另一个是卡密生成与交付平台，最后提交在 2026 年 9 月，仓库内有 7 篇文档。两者都是 Go 技术栈，规模不大，但定位清楚——一个做底座，一个做具体交付。

客户当时的状态

重复开发是这类项目的核心痛点。每来一个交付，都要重新定义一遍业务对象、重写一遍列表和表单，改一处字段要动好几处代码。这种模式在交付量上来之后就走不通了。另一条线是卡密的生成、分发与核销：卡密一旦发出去，状态必须清楚，谁生成、发给了谁、有没有核销，出问题要能查。

我们的做法与取舍

第一个取舍是用元数据描述业务对象，把重复的增删改查收进底座。业务对象先用元数据定义出来，界面与接口由底座按定义生成，新增一个对象不再需要重写一遍代码。

第二个取舍是底座与交付物分离。底座只做平台能力，具体业务放在使用底座的交付项目里。这样底座升级不会绑死某一个交付，一个底座能支撑多个交付物。

第三个取舍是把卡密做成独立的交付产品，不和底座揉在一起。卡密链路有自己的生成、分发与核销状态，独立出来才好维护，也方便单独交付给需要的客户。

系统怎么承载这条链路

底座这一层负责元数据定义、页面与接口生成、以及权限等公共能力；交付层是具体业务，按底座的约定挂上去；卡密则是另一条独立链路，负责生成与核销。两层之间靠元数据定义衔接，而不是靠代码复制。底座与卡密端虽然都是 Go，但维护节奏可以分开，互不等对方发版。

交付状态与边界

代码处于维护状态，卡密端最近提交在 2026 年 9 月。边界说明：底座提供的是通用能力，具体业务能否落地取决于元数据定义得是否合适，定义不清仍会返工；卡密的安全强度取决于生成规则与保管方式，我们负责系统内的生成与核销，不承担贵方保管环节的责任；这套项目规模不大，公开口径不含任何量化收益，提交次数与文档篇数是仓库里可见的事实，仅此而已。