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

本地存储的两大风险

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

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，合并逻辑单独成函数并写单元测试——存档合并代码平时没人看，出错就是舆情事件。最后别忘了日志：每次合并、拒收、恢复都留痕，出了申诉才有据可查。

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

createfile (path)

创建文本，本地存储先建文件，注意相对路径的基准目录

createfile('..\\QuestDiary\\abc.txt')

addtextlist (path,str,line)

写入指定文本文件，按行写入，0 到 65535 的行号上限决定了单文件容量

getliststring(path, str, result1, result2)

获取文本文件指定行的内容，读取时行号要自己维护，缺失行返回空

getliststring(path,str,result)

获取文本文件指定行的内容[根据符号分割]，一行多字段时按分隔符直接拆开

changetongfile(path, str, line, model)

更改文件内容，原地改内容，比整文件重写更安全

tongfile(model, fileName)

通区创建/删除文本，需要跨区共享的存储走通区文件

updatetongfile( fileName)

通区同步文本，同步时机不对会造成读到半份数据

【框架设计】宠物进阶：进化材料链与形态切换

【框架设计】坐骑系统：碎片合成与品质保底

【网络通信】动作与表情：社交广播的轻量协议

【性能调优】延迟结算：非紧急任务的队列消化

【安全加密】数据脱敏：日志与取证导出的隐私处理

【界面UI】BUFF 图标栏：增益排列与剩余时间