【数据存储】SQLite 加密存储与本地数据防篡改

完整课程入口：996 全套课程体系 ｜ Lua 学习路径 ｜ 幂尔框架 mirs.cn

本地存储的两大风险

游戏客户端总要存东西：设置项、离线缓存、进度存档。本地数据的两大风险分别是泄露与篡改——泄露指玩家数据、配置被第三方程序读走分析；篡改更危险，金币数量、关卡进度被直接改写后回传服务器，就是刷子外挂的雏形。设计存储层时这两件事要一起考虑。

SQLite 的加密方案

SQLite 单文件、跨平台、支持 SQL 查询，是本地结构化存储的首选。明文 SQLite 用任意数据库工具就能打开，加固首选加密扩展（如 SQLCipher 思路）：整库透明加解密，应用层无感知。接入要点有三：密钥不落盘（启动时由服务器下发或由设备特征派生）；建表时把敏感字段单独拆表，缩小加密与校验范围；打开数据库失败要有降级路径——密钥错误、文件损坏都要能走到"重建库 + 从服务器拉取"的恢复逻辑，而不是崩溃白屏。

不用 SQLite 的纯文件场景（比如 Lua 侧的本地缓存表），最低限度也要做"序列化 + 异或/xxtea + 头部校验"，并保证写入是原子的：先写临时文件、校验通过后再改名覆盖，断电断进程都不会留下半个坏文件。

防篡改：签名校验

防改的核心思想是服务器说了算。本地数据加一个 HMAC-SHA256 签名：以服务器下发的会话密钥对"数据内容 + 版本号"计算签名，加载数据时先验签，签名不符直接丢弃本地数据、从服务器重新拉取。攻击者改了数据，但没有密钥就算不出新签名。

local sign = hmac_sha256(sessionKey, dataStr .. ":" .. version)
-- 加载时
if hmac_sha256(sessionKey, localData .. ":" .. localVersion) ~= localSign then
    return fetchFromServer()   -- 拒绝本地脏数据
end

配合版本号递增 + 服务器留存最新已确认版本，还能识别"回档作弊"：本地报上来的版本比服务器记录的还旧，直接拒收。

云存档冲突处理

多端登录必然遇到冲突。原则是"字段级合并优先于整档覆盖"：设置类字段按时间戳取新；进度类字段以服务器为准；无法判定的冲突保留两份并提示玩家选择。实现上给每个字段记 value + updateTime + updateFrom，合并逻辑单独成函数并写单元测试——存档合并代码平时没人看，出错就是舆情事件。最后别忘了日志：每次合并、拒收、恢复都留痕，出了申诉才有据可查。