用一个 struct 给游戏关键数值上锁：ProtectedInt 反作弊实践

读这篇能拿到什么

读完这篇你会拿到三样东西。一是一套"轻量运行时数值保护"的完整实现思路：怎么用一个 struct 就让内存里的生命、金币、伤害不再以明文躺着，怎么让"改一个内存地址"这种最常见的作弊手段在下次读取时自己暴露。二是一条从"客户端探测"到"服务器判定"的证据链设计：探测到异常不崩溃、不封号，而是攒成两个可上报的计数，交给服务器做最终判断。三是一份清醒的能力边界清单：这个方案防得住什么、防不住什么，哪些数据还必须靠服务器权威校验。

什么场景下用得上

它适合这类需求：你有一批局内关键整数 ------生命、金币、伤害、卡牌点数、计分输入------它们只活在单局内存里，是内存修改器（金山游侠、GameGuardian 那类）最直接的目标；你又不想为了防护把成百上千处 hp - 10 这样的业务代码全部改成专用读写 API。

如果你的项目满足下面几点，这套做法会很顺手：数值以 C# 字段形式散落在各处业务逻辑里、通过隐式运算被反复读写；你已经有单局存档和对局结算上报的通道，能顺路把反作弊信号带出去；你的定位是"抬高作弊成本 + 拿到风险信号"，而不是"客户端就地封杀"。反过来，如果你要保护的是磁盘存档明文、或者需要对抗能读懂并一致改三处字段的定向工具，这个方案单独用不够，得往下看能力边界那一节。

它是怎么做的

核心就一个 struct，内存里不存真值，存三个字段：

csharp 复制代码

private int _salt;     // 逐实例随机盐
private int _encoded;  // 真值 XOR 盐
private int _check;    // 真值 XOR 盐 XOR 魔数

读取时 _encoded ^ _salt 还原真值，再拿真值重算校验和跟 _check 比对，不一致就上报：

csharp 复制代码

private int Decode()
{
    if (_salt == 0 && _encoded == 0 && _check == 0) return 0; // default 视为合法 0
    var value = _encoded ^ _salt;
    if ((value ^ _salt ^ CheckMagic) != _check)
        ProtectedValueGuard.ReportTamper(_check); // 失配上报，但仍返回解码值
    return value;
}

关键设计有几处值得说。第一，_encoded 和 _check 相互独立，内存修改器通常只改一处（改的是它看到的那个值），另一处不会同步跟着变，于是下次 Decode() 必然失配。第二，探测到篡改不抛异常、照常返回解码值 ，这样既不影响主逻辑，也不给作弊工具一个"我被发现了"的明确时机。第三，用 _check 当字段身份 key------它在篡改后不变，所以同一个字段被 UI 每帧狂读也只算作"一类值被改过"，不会被读取频率放大。

对业务代码几乎零侵入，靠 int 双向隐式转换：

csharp 复制代码

ProtectedInt health = 100;   // int -> ProtectedInt，重新生成盐和校验
int cur = health;            // ProtectedInt -> int，触发解码校验
health = cur - 10;

所以老代码大多只换字段类型就能编译通过。ProtectedLong 是同构的 64 位版本，用来保护计时类字段（累计用时）。

探测信号汇到一个静态类 ProtectedValueGuard，它维护两个维度的计数：TamperCount（去重后被改的字段种类数，约等于"改了几类值"）和 MismatchReadCount（不去重的失配读取次数，反映篡改的持续和频繁程度）。开局重置，让检测以单局为边界；存档前抓快照、读档后恢复，保证断线重连或域重载后已有记录不丢。结算时写进对局记录，再映射成协议字段上报服务器。

序列化上，转换器只写明文真值、读档时重建盐和校验，所以存档格式和旧版一模一样（"health": 587），旧存档无缝兼容，档内不残留编码痕迹。

好在哪里

侵入性极低。 靠隐式转换，几十上百个读写点不用动，这是它能在一个成熟项目里落地的前提------换成"人人都得调 .GetValue()"的方案，改造成本和回归风险会高一个量级。

把"数值异常"变成了"明确信号"。 没有保护时，你只能看到"这个玩家金币多得离谱"这种业务现象，很难区分是 bug 还是作弊。有了编码/校验分离，单点改值直接变成一个可计数、可上报的篡改事件。

两个维度比一个布尔标记聪明。 只报"疑似作弊 true/false"信息量太少。TamperCount 告诉服务器"改的面有多广"，MismatchReadCount 告诉服务器"改得有多持续"，两者组合让服务器更容易把偶发异常和持续作弊区分开，也更难被单点误报带偏。

处置权留给服务器，客户端只探测不审判。 客户端不封号、不回收、不改结算，避免了客户端误判直接伤害正常玩家；同时客户端本身可被逆向，把处置逻辑放客户端等于把判罚规则送给作弊者研究。

保护与存档格式解耦。 运行时怎么编码是内部实现，存档永远是普通整数，既向后兼容，也不会把内部表示固化进存档格式，日后改编码方式不影响老档。

性能消耗与优化

天下没有免费的保护。ProtectedInt 的成本集中在一点上：一次隐式转换就是一次 Decode()，也就是一次异或还原加一次校验重算。单看一次开销微乎其微，但它藏在隐式转换里，很容易在你没意识到的地方被反复触发。

最典型的坑是把受保护字段直接写进高频路径。下面这种写法，bft.health 和 bft.maxHealth 各解码了两次：

csharp 复制代码

// 不推荐：每个 bft.health / bft.maxHealth 都触发一次解码校验
healthText.text = $"{bft.health}/{bft.maxHealth}";
UpdateHealthBar(bft.health, bft.maxHealth);

放到每帧刷新的 UI、战斗结算循环、或者 for 里逐元素读的场景，这种重复解码会被帧率和循环次数成倍放大。更坑的是：如果这个字段已经被篡改，处于失配状态，那么每多读一次就多累加一次 MismatchReadCount------重复读取不仅浪费 CPU，还会把上报计数的语义带偏，让"读了很多次"看起来像"篡改很严重"。

优化手段就一条核心约定：一次解码，多次使用 。同一作用域里要多次用到某个受保护值，先隐式转换成局部 int 缓存下来，后面全用这个局部变量：

csharp 复制代码

// 推荐：只解码一次，后续全用局部 int
int cur = bft.health;
int max = bft.maxHealth;

healthText.text = $"{cur}/{max}";
UpdateHealthBar(cur, max);

写入侧同理：先在局部 int 上把业务计算全做完，最后一次性写回 ProtectedInt 字段。每次给 ProtectedInt 赋 int 都会重新生成盐、编码值和校验值，中途反复写回等于反复付这份构造成本，没有意义。项目里 Damage.GenerateDamage() 就是这么做的：全程用局部 int 计算，只在正确时机把结果写回受保护字段。

一句话记住：别让受保护字段裸奔在循环和字符串插值里，把它当"取一次就存起来的贵重品"用。 只给真正需要防护的关键整数套 ProtectedInt，普通中间变量、临时量保持原生 int 即可，不必全盘替换。

不足与边界

得非常清楚地说：这只防"改数值"，防不住"改逻辑"。 具体防不住这些：能同时读懂并一致修改 _salt/_encoded/_check 三个字段的定向工具；热补丁直接改 Decode()、ReportTamper() 或结算上报路径的代码；跳过扣费、跳过伤害、伪造奖励这类改业务逻辑而非改数值的作弊；磁盘存档里的明文整数（它只保护内存，不保护落盘明文，存档得靠加密/签名/服务端校验另行兜底）；拦截、删除、伪造客户端上报本身。

还有两个实现层面的软肋。盐来自一个确定性 LCG 序列，不是密码学随机数，面对高级分析时打散强度有限------它的目标本就是"提高普通扫描成本"而非"提供密码学安全"。另外，篡改只在字段被读取时才会暴露：如果攻击者改了某字段、而它在结算前再没被读过，客户端就不会产生失配信号。

一句话总结它的定位：ProtectedInt 是反作弊体系里的客户端探针，作用是抬高作弊成本、产出风险信号，绝不是可信根。关键经济和结算数据该由服务器校验的，仍然得由服务器校验；重要上报该做防重放和完整性保护的，一样不能省。把它当探针用，它很称职；把它当城墙用，会塌。