【安全加密】RSA+AES 混合加密的进阶用法：充值通道的分层防护

实战应用：用在哪里

充值通道是攻击价值最高的链路：伪造一条"到账"消息比刷装备直接得多。混合加密（RSA 传密钥、AES 加数据）之外，充值通道还需要分层防护：传输层加密、业务层幂等、对账层核销，三层各管一段，任何单层被突破都不会造成真实损失。

第一层：传输加密与签名

充值回调渠道与自建充值服务都走 RSA+AES 组合：RSA 2048 完成密钥交换，AES-128-CBC 加密报文体，报文附 HMAC-SHA256 签名覆盖全部业务字段（订单号、金额、时间戳、nonce）。金额字段用"分"为单位的长整型传输，避免浮点误差被利用。

第二层：业务幂等与订单状态机

每个订单一个全局唯一单号，服务端订单表维护状态机：CREATED → PAID → DELIVERED → SETTLED。DELIVERED 之后的重复回调直接返回首次发放结果（幂等），不再二次发货。状态迁移写成白名单：CREATED 只能到 PAID，PAID 只能到 DELIVERED——任何跨状态跳转的请求按非法数据处理并告警。

local ok = orderCAS(orderId, "PAID", "DELIVERED")   -- 原子状态推进
if not ok then return firstResult(orderId) end       -- 重复回调返回首发放结果
deliverGoods(orderId)

第三层：对账核销

每日定时从渠道拉取订单清单，与本地订单表双向核对：渠道有本地无（漏单补发）、本地有渠道无（误发冻结）、金额不一致（标记人工审核）。对账脚本是兜底闸，能兜住前面所有环节的失误。

数值与日志

实测指标：单笔回调处理（验签+解密+幂等+发放）7.4ms；对账脚本日跑 3 万单 41 秒。日志三处必留：回调原始报文、验签结果、发放流水，充值纠纷的全部结论都从这三处出。三层防护的代码量约四百行，一天可完成初版，是付费系统的安全底线配置。

状态机的原子推进在单进程 Lua 里天然安全（单线程无并发写），跨服与多进程部署时状态表要收敛到单一写入点（支付中心），其他进程只读并通过对账修正。幂等表保留周期建议 90 天，覆盖渠道侧最长的回调重试窗口。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。