后端经验迁移地图：哪些能复用，哪些要重学

你已经知道怎样管理复杂度、避免重复处理、设计接口和定位故障。这些能力都能复用。需要调整的主要是：执行节奏、对象生命周期、资源形式，以及客户端信任边界。

从“收到请求才干活”到“每帧都可能干活”

后端接口通常由请求触发。游戏除了事件，还会持续进行输入采样、动画、模拟与渲染。假设一秒显示 60 帧，一帧总预算约 16.7 毫秒；其中还要留给渲染、物理和系统开销。一次同步阻塞可能直接被玩家看见。

这不意味着把所有东西都塞进 Update。分数变化时刷新 UI 是事件；移动和镜头跟随才经常需要按帧处理。把不会变化的工作重复做几十次，是常见的性能浪费。

迁移对照表

后端概念	可以借用的理解	别照搬的地方
容器与依赖	Inspector 引用把对象连接起来	Unity 不会自动替你解析所有业务依赖
数据记录与显示层	规则状态与 GameObject 视图分开	屏幕位置不应成为唯一业务数据
服务生命周期	Awake、启用、销毁等钩子	不同对象的执行顺序不能随意假定
定时任务	协程、计时器和逐帧处理	协程通常仍在主线程，不是后台工作线程
配置中心	ScriptableObject 或序列化配置	运行时状态不能直接当作持久化配置
连接池	游戏对象池减少重复创建	回收时要重置状态、事件和引用
日志与追踪	Console、Profiler、真机日志	画面卡顿需要分析帧时间与分配
镜像和部署产物	构建出的小游戏工程与资源	编辑器运行不等于最终目标运行

客户端状态不等于可信事实

玩家本地的分数、货币和设备时间都可以被修改。后端经验能帮助你判断哪些数据可以本地保存，哪些必须由服务端决定。

例如广告奖励，客户端可以展示“正在确认奖励”。永久货币的增加则需要可信的发奖流程。单靠按钮禁用和本地标志无法跨设备防重。

一个容易过度设计的地方

不要第一天就把小型单机合成游戏做成几十个服务、事件总线和抽象工厂。你熟悉的分层原则仍有用，但边界应围绕真实变化：合成规则、棋盘状态、视图表现和平台服务就已经是清晰的起点。

当你确实需要“编辑器假广告”和“微信真广告”两种实现时，再抽出明确的平台接口。只有一个实现而且没有替换需求的抽象，通常只会增加 AI 理解工程的成本。

给 AI 的背景说明

我有后端经验，但刚接触 Unity。解释方案时，请指出哪些是 C# 逻辑，哪些要在 Inspector 配置，哪些属于 Unity 生命周期。请把主线程上的工作、异步等待和平台限制讲清楚，不要假设我知道场景挂载步骤。

这能避免 AI 给你一段看似完整、实际上没有挂载对象和引用的代码。后面每一章都应回答两个问题：代码什么时候运行？它依赖的对象和配置在哪里？

参考：Unity 执行顺序、Unity 协程。