Flutter+Node.js实时游戏：游客与登录玩家内购安全方案咨询

问题背景 #

我开发的实时游戏采用Flutter前端+Node.js后端，内置商店支持金币购宝石、宝石购头像，玩家分游客/登录两种状态：

• 游客：数据仅通过sqflite本地存储，内购全在前端处理（核心代码如下），存在被篡改数据的风险
• 登录用户：数据同时存在本地sqflite和后端MySQL，内购由后端校验更新，安全性有保障但成本可控

当前游客内购核心代码：

void buyGems(int coins, int gems) async {
    showErrMsg(coins, user.userData.coins, "no_coins_for_bundle_msg");
    user.userData.coins = user.userData.coins - coins;
    user.userData.gems += gems;
    await user.saveOrUpdateUserInLocalDb(user.userData);
}

痛点：游客内购全前端处理易被篡改，全移到后端又会增加服务器负载，预算有限，求平衡方案。

低成本安全方案建议 #

1. 本地数据签名校验（零服务器成本） #

• 打包时给Flutter嵌入一个本地密钥（别明文写死，可通过代码混淆或动态生成）
• 每次存储用户数据时，用密钥对核心字段（金币、宝石、已解锁头像）生成HMAC签名，和数据一起存在sqflite里
• 启动APP、每次内购前后都校验签名：如果签名不匹配，直接把游客数据重置到初始状态
• 示例逻辑：

  // 生成签名
  String generateSignature(UserData data) {
    String payload = "${data.coins}-${data.gems}-${data.unlockedAvatars}";
    return Hmac(sha256, utf8.encode(localSecret)).convert(utf8.encode(payload)).toString();
  }
  
  // 校验签名
  bool validateSignature(UserData data, String savedSignature) {
    return generateSignature(data) == savedSignature;
  }
  

• 优势：完全本地处理，没服务器成本；篡改数据必然导致签名失效，普通玩家很难绕过

2. 游客数据轻量化后端校验（极低负载） #

• 不给游客创建完整账号，只给每个游客生成一个随机UUID绑定本地数据
• 内购时，前端把UUID+当前核心数据+购买请求发给后端，后端只做极简校验：
  1. 从环境变量取商品价格（避免前端篡改定价）
  2. 校验请求里的用户数据是否满足购买条件（金币≥所需数量）
  3. 不存储游客数据，只返回校验结果+新的核心数据签名
  4. 前端收到有效响应后，再更新本地数据并存储新签名
• 优势：后端只做逻辑校验，不存数据，资源消耗极小；彻底避免前端篡改价格和数据

3. 游客转登录的激励机制（缩小风险范围） #

• 设置激励：游客绑定账号（登录）就能领额外金币/宝石
• 游客状态下只开放低价值商品购买，高价值商品必须登录后才能解锁
• 既降低游客内购的风险影响范围，又引导用户转为登录状态，统一用安全的后端流程

4. 本地核心数据加密存储 #

• 对sqflite里的核心用户数据字段（金币、宝石）做加密存储，别用明文
• 加密密钥可以结合设备唯一标识（比如Android的IMEI、iOS的IDFA，注意权限合规）+APP包名生成，提升篡改难度
• 就算玩家找到数据库文件，也没法直接修改明文数据

方案选择建议 #

• 预算极低：优先选本地数据签名校验+加密存储，完全无服务器成本，能挡住绝大多数普通篡改行为
• 有少量预算：选轻量化后端校验，进一步提升安全性，后端仅处理校验逻辑，资源消耗可以忽略
• 长期运营：搭配游客转登录激励，逐步减少高风险的游客内购场景

内容的提问来源于stack exchange，提问作者Mona