国内大部分的手游团队都是前后端分离的，因此在遇到了bug的时候需要区分是客户端的问题还是服务端的问题并修复+判断后续更新方案。上一篇文章中大致列举了一些游戏bug，一般来说处理它们对应的职能团队是：
客户端：界面显示问题（比如动画、模型、图片、文本等资源显示有误）、卡顿甚至卡死问题、闪退问题
服务端：数据错误、逻辑错误、登陆问题、回档问题、网络问题
有一些问题需要细查之后判断：支付问题、部分数据问题、部分逻辑问题、部分显示问题、部分登陆问题，还有策划填错表导致的问题，需要程序判断影响范围以及后续处理方案。
为什么有些问题需要细查之后才能判断呢？因为存在这样的情况：
- 玩家报一些资源没有到账，但是查服务器日志到账了，只是客户端显示有误
- 玩家报客户端显示有问题，但实际上是服务器下发的数据有误导致的显示问题
- 玩家报客户端显示的资源数目有问题，查下来玩家的资源数目正确，但是服务器发送了错误的推送导致问题
- 玩家报登录不进游戏，查下来服务器正常、玩家数据无误，但是客户端的错误逻辑导致了玩家登录失败
- 对于支付问题，需要结合支付接口文档及流程具体查看失败原因，确认是前端还是后端的参数或回调有问题，支付接口是否有前端/后端更新等等
一般来说，大部分问题有一个简单粗暴的判断方式：大退&重新登陆游戏，看问题是否依旧存在。对于大多数游戏来说，玩家的客户端数据都是在重新登陆的时候由服务端全量下发到客户端的，对于上面1、2类型的问题能够很容易地通过这样的方式排查。对于类型3、4、5的问题，一般需要服务端和客户端通过代码逻辑，结合日志来确认。
对于网络问题，可能需要运维同事配合性能监控一同排查问题，是带宽不够需要扩容，还是遭到了攻击，还是云服务厂商遇到了问题，等等等等。
对于由全公司的中台/平台开发，项目内代码只进行调用的接口，也会需要找相关同事一同进行bug排查。
对于策划填表错误导致的问题，需要确认
- 改表后功能能否恢复正常，是否需要程序的额外处理
- 在表格错误期间，玩家数据受到的影响能否在表格改正后恢复，是否需要处理脏数据，处理脏数据是否由运营处理即可，还是必须有程序参与
还有一些问题会和客户端存在机器本地的数据有关系，这种可以通过换设备方式进行复现&排查，因为不涉及服务端就不具体展开了。
后记
和第一篇的发布时间隔了好久。实际上第二篇在笔记本内写完之后没多久，chatGPT还有各种各样的大模型横空出世，对于刚刚开始燃起码字之魂的我来说是当头一盆冷水，我开始怀疑自己写的这些内容有没有价值，会不会对于读者来说这个时间不如去问gpt，甚至还能问得有来有回。不过转念一想，最早开始写这些内容也是为了记录一下过往的踩坑经历，就算最后成为了AI的血肉养料，它们也是我的经历和思考。