Appearance
项目题回答框架
项目背景：做了什么游戏或系统
项目背景这一段要先讲清楚：你做的是一个什么东西，而不是一上来就讲代码细节。面试官先听懂项目，后面才好追问你的模块、难点和优化。
推荐回答顺序
1. 先说项目类型 比如：第三人称动作 Demo、2D Roguelike、塔防游戏、卡牌战斗、资源管理系统、热更新系统、编辑器工具链。
2. 再说核心玩法或核心目标 游戏项目就说玩家主要做什么。 系统项目就说它解决什么工程问题。
3. 补技术栈 比如：Unity、C#、URP、UGUI、Addressables、AssetBundle、Animator、对象池、事件系统、状态机。
4. 说你负责的模块 不要只说“我参与了开发”。要说清楚你负责什么。 比如战斗系统、技能系统、背包 UI、资源加载、对象池、配置表工具、性能优化。
5. 补规模或结果 比如完成了玩法闭环、能现场演示、优化了 GC、降低了加载耗时、支持资源分包。
可直接背的开场句
我做的是一个 Unity 第三人称动作战斗 Demo，核心玩法是角色移动、锁定敌人、释放技能、受击反馈和关卡战斗闭环。技术上主要用 C#、Animator、CharacterController、对象池、事件系统和资源异步加载。我重点负责战斗流程、技能系统和性能优化。
更系统一点的说法
NOTE
我做的是一个 Unity 游戏客户端 Demo，目标不是只做单个功能，而是搭出一个完整的小型客户端框架，包括场景切换、UI 管理、资源加载、对象池、事件系统、角色状态机和基础战斗流程。这样面试时我可以围绕一个完整项目讲架构、性能、资源和玩法闭环。
我的职责：我负责哪些模块
这一段不要说“我都参与了”。面试官更想听的是：你主责哪些模块、边界是什么、具体做了什么、和谁联调、最后有什么结果。
推荐回答顺序
1. 先说主责模块 最好控制在 2 到 3 个核心模块。 比如：战斗系统、技能系统、UI 管理、资源加载、对象池、事件系统、配置工具、性能优化。
2. 说模块边界 哪些是你负责的，哪些不是你负责的。 比如客户端负责表现、输入、动画、特效、UI 刷新；服务端负责最终伤害、背包货币、排行榜数据。
3. 说具体实现 不要只说“我负责技能系统”。要补实现内容。 比如技能释放流程、CD 管理、目标筛选、命中检测、Buff 触发、动画同步。
4. 说协作对象 比如和策划对配置表字段，和美术对动画事件和特效挂点，和服务端对协议字段，和 UI 对红点刷新。
5. 说结果 比如完成了战斗闭环、减少 GC、加载更平滑、模块可复用、方便扩展新技能。
可直接背的说法
IMPORTANT
我主要负责战斗相关和客户端基础框架两块。战斗里我负责角色状态机、技能释放流程、命中判定、Buff 触发、动画事件同步和受击反馈；基础框架里我负责对象池、事件管理器、资源异步加载封装和 UI 管理。我的边界主要在客户端表现和交互逻辑，服务端权威数据比如最终伤害、货币和背包变更由服务端处理。做完后项目能跑通完整战斗闭环，并且通过对象池和资源缓存减少了战斗中的 GC 和加载卡顿。
更短的面试版
TIP
我主责的是战斗系统、技能系统和一部分客户端基础框架。具体包括角色状态机、技能 CD、目标筛选、命中判定、Buff 表现、对象池、事件系统和资源加载封装。我的重点不是只把功能写出来，而是保证模块之间边界清楚，后续新增技能、特效和 UI 表现时不需要大改核心逻辑。
技术难点：当时最难的问题是什么
这个问题不要回答成“时间紧、需求多、bug 多”。更好的回答是：讲一个具体技术问题，并讲清楚现象、难点、定位过程、解决方案、结果和复盘。
推荐回答顺序
1. 先说问题现象 比如战斗中偶发卡顿、技能命中和动画不同步、资源卸载不干净、切场景峰值内存过高、弱网下角色位置抖动。
2. 说为什么难 难点通常不是代码多，而是：复现不稳定、多模块交叉、异步时序复杂、性能瓶颈不明显、客户端和服务端边界不清。
3. 说怎么定位 比如用 Profiler 看主线程耗时，用 Memory Profiler 查资源引用，用日志记录状态流转，用断点确认生命周期顺序，用二分法排除模块。
4. 说怎么解决 比如拆模块、加状态机、对象池、异步预加载、引用计数、分帧执行、缓存组件、减少 GC、补防御性检查。
5. 说结果和复盘 比如卡顿降低、GC Alloc 下降、加载更平滑、模块更容易扩展，并沉淀成规范或工具。
可直接背的模板
当时最难的问题是 XXX。它难不是因为代码量大，而是因为它涉及多个模块，问题表现不稳定，单看某一个模块很难定位根因。我先通过 Profiler、日志和断点把问题拆开定位，然后调整了核心流程，并补了防护和验证指标。最后结果是 YYY，后续也把这套处理方式沉淀成了规范。
Unity 示例回答
NOTE
我当时遇到比较难的问题是战斗中偶发卡顿。它难在卡顿不是每次都出现，而且同时涉及技能特效、伤害飘字、对象创建、动画事件和 UI 刷新。最开始看起来像是动画问题，但我用 Profiler 分析后发现，某些技能释放时会同时 Instantiate 多个特效和飘字，还伴随字符串拼接和事件广播，导致那一帧 GC Alloc 和主线程耗时都升高。
我的处理方式是把子弹、特效、飘字都接入对象池，技能释放前做资源预加载，战斗日志和飘字文本减少临时字符串分配，同时把部分非关键 UI 刷新延迟到下一帧。优化后战斗中的 GC Alloc 明显下降，技能释放时的帧耗时也更稳定。这个问题让我意识到，性能问题不能靠猜，要先用工具定位，再按模块逐个拆。
解决方案：怎么拆分、怎么实现、怎么优化
解决方案：怎么拆分、怎么实现、怎么优化
这段要讲成一个工程闭环：先拆问题，再定模块和接口，然后实现核心流程，最后优化并验证结果。不要只说“我重构了”“我优化了”，那样太空。
推荐回答顺序
1. 怎么拆分 把大问题拆成几个层： 数据层、逻辑层、表现层、资源层、工具层。
比如技能系统可以拆成：技能配置、技能释放流程、目标筛选、命中判定、Buff 触发、动画表现、特效音效。
2. 怎么实现 先跑通主流程，再补边界。 比如先实现“按下技能键 -> 检查 CD -> 播放动画 -> 开启判定 -> 命中目标 -> 造成伤害 -> 播放反馈”。
3. 怎么优化 针对热点优化，不要无脑优化。 比如用对象池减少子弹和特效创建销毁；用异步加载和预加载减少切场景卡顿；用事件系统降低 UI 和业务耦合；用分帧执行减少单帧峰值。
4. 怎么验证 用数据证明。 比如 Profiler 看主线程耗时、GC Alloc、加载峰值、内存占用、DrawCall、帧率变化。
可直接背的模板
我的解决思路是先把问题拆开，不把所有逻辑堆在一个模块里。我会先拆出数据层、逻辑层、表现层和资源层，然后用清晰接口串起来，先保证主流程跑通，再针对性能热点做缓存、对象池、异步加载或分帧处理，最后用 Profiler 和日志验证效果。
Unity 项目示例
NOTE
以技能系统为例，我会把技能拆成配置数据、释放逻辑、目标筛选、命中判定、表现层和资源层。配置数据只描述技能 ID、CD、范围、伤害参数和特效路径；释放逻辑负责检查条件和推进状态；目标筛选负责找敌人；表现层负责动画、特效、音效；资源层负责异步加载和缓存。
优化上，技能特效和伤害飘字会接对象池，常用资源提前预加载，非关键 UI 刷新可以延迟或合并，避免一帧里同时 Instantiate、加载资源、刷新大量 UI。最后用 Profiler 看技能释放时的 GC Alloc 和主线程耗时是否下降。
结果数据：帧率、内存、加载时间、代码复杂度、复用效率
结果数据：帧率、内存、加载时间、代码复杂度、复用效率
这一段的核心是：用前后对比证明你做的事情真的有效。不要只说“优化后变流畅了”，要说优化前、优化后、怎么测、结果说明什么。
推荐回答顺序
1. 帧率 可以说平均帧率、最差帧、主线程耗时。 比如：战斗场景优化前技能释放时主线程峰值接近 18ms，优化后稳定在 9ms 左右。
2. 内存 要分清峰值内存、常驻内存、Managed Memory、Native Memory、GC Alloc。 比如：对象池和缓存后，战斗中每帧 GC Alloc 从几 KB 降到接近 0。
3. 加载时间 可以说首屏加载、切场景加载、资源异步加载进度。 比如：切场景从 3.2s 降到 1.8s，并且加载过程不再长时间黑屏。
4. 代码复杂度 这不是说行数越少越好，而是说模块边界更清楚，改动影响范围更小。 比如新增一个技能时，只需要加配置和表现逻辑，不需要改技能主流程。
5. 复用效率 可以说同类功能新增成本下降。 比如原来新增一种子弹或特效要重复写加载、创建、销毁逻辑，接入对象池后只需要配置 Prefab 和生命周期回调。
可直接背的模板
优化前，XXX 场景里主要问题是 YYY，比如主线程耗时高、GC Alloc 明显、加载时间长或者模块耦合高。我用 Profiler、Memory Profiler 和日志做了前后对比，优化后指标变成 ZZZ。这个结果说明不只是功能能跑，而是性能更稳定、扩展成本更低。
Unity 示例说法
TIP
我当时对战斗场景做过一次优化。优化前技能释放时会同时创建特效、飘字和临时对象，Profiler 里能看到主线程有明显尖峰，GC Alloc 也比较明显。后来我把子弹、特效、飘字接入对象池，常用资源提前预加载，并减少字符串临时拼接。优化后战斗中的 GC Alloc 基本降到 0，技能释放时的主线程峰值也明显下降，低端机上的帧率更稳定。
面试注意点
CAUTION
没有精确数据时，不要硬编特别夸张的数字。可以说：“我当时用 Profiler 做过对比，主要观察的是主线程耗时、GC Alloc 和加载峰值，结论是优化后尖峰明显减少。”这样比乱报数字更稳。
复盘反思：如果重做会怎么改
这个问题不能只说“我会写得更好”。面试官真正想看的是：你能不能看见当时方案的局限、问题根因，以及下一版更成熟的工程方案。
推荐回答顺序
1. 先说明当时限制 比如时间有限、目标是先完成玩法闭环、项目规模还小、当时更关注功能跑通。
2. 承认暴露的问题 比如模块边界不够清楚、资源释放不统一、性能指标不够早、工具链不足、测试覆盖不够。
3. 说清楚根因 不要只说“写得不够好”。 要说是架构分层不够、缺少统一规范、缺少自动检查、缺少指标监控，还是过早把逻辑写死。
4. 给出重做方案 比如重新拆数据层、逻辑层、表现层；资源统一引用计数；技能系统配置驱动；增加 Profiler Marker；接入资源检查工具。
5. 说预期收益 比如扩展更快、bug 更少、加载更稳、内存更可控、后续新增功能改动范围更小。
可直接背的模板
如果重做一次，我不会否定当时的方案，因为当时目标是先把核心玩法闭环跑通。但复盘来看，主要问题是 XXX。根因是 YYY。下一版我会从 ZZZ 入手，比如重新拆模块边界、补工具检查、加性能指标和资源生命周期管理。这样可以让项目在后续扩展时更稳定，也能降低维护成本。
Unity 项目示例
TIP
如果重做一次战斗系统，我会更早把技能数据、释放逻辑、表现层和资源层拆开。当时为了快速做出效果，技能流程、动画事件、特效生成和伤害表现耦合得比较紧，后面新增技能时容易牵一发动全身。
重做的话，我会让技能配置只描述数据，技能执行器只负责流程推进，目标筛选、命中判定、Buff、表现层各自独立。特效和飘字统一走对象池，资源加载统一走异步封装和引用计数。这样新增技能时主要改配置和少量表现逻辑，不需要频繁改核心流程。
面试加分说法
IMPORTANT
我觉得复盘最重要的是不要只看功能有没有完成，而要看这个方案能不能支撑后续扩展。功能跑通只是第一步，后面还要关注模块边界、性能指标、资源生命周期、工具链和测试回归。