巨人网络游戏服务器开发一面：道具篡改与数据安全设计

《面试题目》

1. 请介绍你的第一段实习项目，你负责了哪些部分？
2. 你们项目里的加密解密是怎么实现的？
3. 你们主要是做用户数据操作的，那在保证用户数据安全性和防止数据丢失方面，有没有做过哪些相应的处理？
4. 请介绍你的第二段实习项目。
5. 你平时会用一些 AI 工具吗？
6. 使用 AI 工具的频率大概怎么样？
7. 你了解游戏开发的模式吗？游戏开发一般分为前端和后端，两者合作比较密切，你怎么看？
8. 哪些数据放在服务器端是比较安全的？哪些数据适合放在客户端？
9. 如果购买 A 道具需要 100 钻石，但前端把数据篡改，用 100 钻石买了 B 道具，服务器怎么防止这个问题？
10. 游戏里使用某个道具时，比如使用 A 道具，客户端却告诉服务器消耗的是 B 道具，这种情况应该怎么设计来避免？
11. 有一个回 500 血的药和一个回 1000 血的药，客户端默认使用的是 A 道具，但把它改成了 B 道具。后端如果只判断「行为」就去扣 A 道具，但因为客户端发的 ID 是 B 道具，结果给处理了 B 道具的效果。这种情况应该怎么设计，把行为和道具 ID 处理好？
12. 玩家在游戏里收集到几个便宜物品，上交到服务器时，客户端把这些便宜道具的 ID 全部改成贵道具的 ID 上传，这种情况怎么避免？
13. 你对巨人网络有哪些了解？
14. 有没有用过具体的游戏开发工具？
15. 之前没做过游戏，为什么投游戏公司？

《参考解析》

项目与数据安全：把「做过什么」讲到能被追问

第 1、4 题的项目介绍不是让你背简历，而是给后面所有追问搭台子：先说清项目解决什么问题、你负责哪块、用什么技术，再主动留一两个可以深挖的点，面试官多半会顺着往下问。第 2 题的加密解密要分成几层讲：传输层一般由 HTTPS/TLS 这类现成方案兜住，业务层则要先区分数据「需不需要还原」——密码、令牌这类只做不可逆的哈希加盐，手机号、支付信息这类要还原的才用对称加密；密钥不能硬编码在代码或配置仓库里，得走环境变量或密钥管理服务并支持轮换。非对称加密在业务里通常只用于签名和密钥交换，因为性能和长度开销大，不适合直接加密大批业务数据。原帖没写作者怎么答的，这里只给通用口径，别拿没做过的方案往自己项目上套。

第 3 题问的是用户数据的安全与防丢失，可以从四个方向答：一是权限与审计，谁能读、谁能改要做到最小化，敏感操作留痕；二是存储可靠性，主从或多副本、定期备份之外还要有恢复演练，只备份没验过等于没有；三是写入一致性，扣款发货这类跨表变更放进同一个事务，对外接口做幂等，防止重复提交造成重复扣减；四是数据治理，敏感字段出库脱敏、冷热数据分开存。答的时候每条都挂一个项目里的真实做法，比列名词表有说服力。

客户端不可信：服务器权威与道具篡改的通用解法

第 8 题是后面几道设计题的总纲，判据只有一条：改了这个值会不会影响公平或经济。货币、背包、属性、掉落、交易、任务进度这类全部由服务端权威存储，客户端只放表现层的东西（模型、特效、UI 状态、输入）和可以缓存的静态配置。客户端上的一切数值都当作可伪造，服务端只信自己算出来的结果。

第 9 题的 100 钻石买 B 道具，根子在「不该由客户端传价格」。客户端只允许提交「我要买商店第 i 个商品」这样的意图和标识，价格、限购、活动时间由服务端按商品配置表自己查、自己算；扣货币与发道具放在同一个事务里，请求带唯一序号防重放，最终以服务端的结果为准。把这条抽象出来就是：协议里传的是意图和标识，不是结果和数值。

第 10、11 题考的是同一件事——把「行为」和「道具 ID」拆开校验。行为决定这次允许的道具集合与消耗规则，道具 ID 决定效果，而效果参数一律从服务端配置表按 ID 查，绝不接受客户端传效果数值。这样一来，客户端谎报 ID 也只能在它真实拥有的道具里换，换到什么就按那个 ID 的效果结算；再叠加「道具必须在背包里、数量够、且属于该行为的白名单」三层校验，回 500 血和回 1000 血那两个药就不会串位：拿 A 的 ID 就按 A 扣、按 A 结算。协议上还可以带配置版本号和参数摘要，防止客户端用旧配置表或伪造参数。

第 12 题的便宜道具改贵道具，关键是不信任客户端上报的物品信息。上交、合成这类批量操作，服务端应该从自己保存的背包数据里解析出真实的 itemId 和数量，而不是直接采信请求里的 ID；如果协议必须带物品，就传槽位索引，由服务端按槽位反查自己的数据。全部校验通过后再原子扣除并发放，任一校验失败就整体拒绝，避免出现「扣了便宜的发贵的」这种中间态。

AI 工具与岗位理解：这一轮也在筛动机

第 5、6 题问 AI 工具，考的不是会不会用，而是怎么用。说清具体场景——查文档、写工具脚本、读陌生代码、辅助定位问题，再补一句你的验证方式：生成的代码要能跑、关键逻辑要自己看懂，不确认的东西不往生产环境放。频率照实说，但要落到「哪类任务交给它、哪类不交」，有边界的诚实比报一个夸张的数字安全。

第 7 题的游戏前后端协作，可以按「职责边界 + 通信协议 + 表现与逻辑分离」来答：客户端负责表现和输入，服务端负责权威逻辑与状态，两者靠协议（消息、状态同步）配合，所以设计任何一个功能都要先想清楚哪些判定必须留在服务端。第 13、15 题的公司了解和「没做过游戏为什么投游戏」，本质是求职动机题——没做过游戏不是减分项，动机讲不具体才是。提前看公司的产品线和岗位 JD，把「为什么是游戏、为什么是这家」说成一条具体理由，而不是一句「我很热爱」。

这一轮的形态：30 分钟、无手撕、有笔试复盘

原帖记录这轮 30 分钟、没有手撕代码，但有笔试复盘环节。复盘容易被当成送分环节，它其实在核对两件事：当时是真会还是蒙对的，以及错了之后能不能想明白——被问到做错的题，说清当时的思路、错在哪、正确做法是什么，比直接背标准答案有效。第 14 题问具体游戏开发工具，原帖作者说没听说过、也就没记录，这类题的正确姿态是照实说不了解，同时讲清你现有的技术栈怎么迁移过去，别硬编经历。整轮看下来，面试官一直在往「客户端不可信、服务端要权威」这条主线上压，把这套校验思路准备好，比多背几道八股更管用。