有人问我这个问题，我尝试解答一下，因为要让大多数人明白，可能有点难。
我先说答案：游戏程序偷懒了，虽然这很难，但不是做不到避免这个问题。
游戏里面，我们常规行为，都是客户端，发送给服务器，服务器进行处理后写入数据库并返回客户端。
比如，我十连抽，客户端告诉服务器，我要进行10连抽，服务器会判断你有没有资格，如果有，就根据逻辑，返回一个10连抽的结果，写入数据库，并返回给客户端。
客户端的工作是，如果你没有10把钥匙，就不让你可以点击这个10连抽。但是，如果有人通过抓包，获取到了这个10连抽的请求的格式，就可以模仿发送请求，也就是绕开客户端的限制，恶意的请求，所以服务器在这里，必定是要有判断的。
所以，你看客户端的工作就是提供用户操作的便利，避免一些无效操作，提供方便，服务器端是严格进行管控的。
客户端到服务器，还有一种请求方式，叫做广播，就是2个人看到完全相同的内容，比如寰球和聊天，都是通过广播形式完成，广播就是一个客户端发送，然后服务器端同时发给每个接受广播的客户端。这种消耗明显要高于前面说的一对一的请求。
我们玩的吃鸡也是通过广播来实现两个人两个设备，呈现内容显示一致的，但这里会有一个问题，就是A和B两个要保持一致，最硬的条件是网络延迟，然后就是如果数据再通过服务器进行校验，就会更多的产生延迟，我不知道有没有说清楚，就是为了同步，只能尽可能减少服务器的处理。
好了，问题就出现了，对于战斗这种这么高频率交互的业务，服务器根本无法校验，能同步就已经很厉害了，你想那么多技能，那么快的速度，那么多的变化，我都叹为观止了，吃鸡的战斗都不会那么复杂。
所以，在战斗这部分，就没有了服务器的逻辑参与，理解了吗？
就是为了体验足够好，就放弃了服务器对战斗的校验。
所以，被抓包后，模仿了一些请求，或者修改本地内存里面的一些数据，就可以通关了。因为服务器没有校验，所以客户端告诉服务器通过，服务器就认为通关了。
但这也不是无法避免，至少我参与的项目，是有验算环节的，也就是说把战斗的部分内容截取，然后交给服务器，服务器只在结算的时候进行一次验算，如果不通过就认为战斗无效。
这个有可能有点晦涩，最简单的验算，就好比你角色没有75级，就不可能过200关，这就好理解了吧。一旦有这种验算，就不会存在你说的问题了。
所以我说，这个是程序偷懒了，这不是做不到，但我依然觉得不可思议，那么复杂的游戏都做出来了，这么会这个环节，没去细扣。
唯一的解释就是，做的时候偷懒，然后上线势头太猛，所有精力都放在了继续开发新功能上，而出现的这个问题，交给运营去头疼。
以上，是我不太成熟的观点，接受批评斧正。