企业官网建设流程全解析

刚被Unity的API列表淹没那会，我是真懵。今天看到 GameObject.AddComponent，明天看到 Quaternion.Slerp，每个教程都只讲单个API能干什么，可一放进自己的项目里，就不知道什么时候该用哪个。后来带新同学也发现，大家卡住的点几乎一样：不是API记不住，是不知道引擎会把它们按什么顺序调用。这篇Unity学习01_常用API，我不按官方文档一条条翻译，而是把这些高频API放到“引擎实际运行逻辑”里重新讲一遍，顺便把常见坑标出来。适合刚会搭场景、准备开始写玩法的初学者；如果你写过一段时间但经常回来查API，也能当一份索引用。

1. 先拆掉“背API”的误区：对象模型与生命周期才是地基

很多人一上来就背API，效果特别差。因为Unity的核心不是一个一个孤立的方法，而是一套“每秒不知道执行多少次”的消息循环。你写的脚本只是挂在某个组件上，引擎在特定时机调用特定方法。不理解这套调度规则，API学得再多也是散装知识。

1.1 GameObject 和 Component 是一对多的容器关系

在Unity里，场景中的每个可见或不可见事物，都是一个 GameObject，但它本身几乎不提供行为，只是一个容器。行为全部来自挂在它上面的 Component。Transform 是组件，MeshRenderer 是组件，你自己写的 MonoBehaviour 脚本也是组件。所以，“创建一个物体”这句话，更准确的说法是“创建一个 GameObject 容器，再往里面放组件”。

容器与组件之间是典型的“一对多”关系。一个 GameObject 上可以同时挂着 Transform、Collider、Rigidbody、多个脚本。拿到 GameObject 引用之后，想要某个组件，用 GetComponent ()；想给它加一个能力，用 AddComponent ()；不想要了，用 Destroy(component)。这套组合拳就是 Unity 对象模型里的增删查。

我要强调一点：AddComponent () 是有返回值的。直接写go.AddComponent<Rigidbody>()而不接收返回值，等于把那个新组件的引用丢了。稍后你想要改刚体参数，又得 GetComponent 一次。虽然单次获取的消耗不算大，但这种“添加完就当甩手掌柜”的习惯，在复杂对象上会积累出一堆无效代码。正确做法是接住它，例如：

Rigidbody rb = go.AddComponent<Rigidbody>();

后续统一用 rb 操作，代码也更清楚。

新手还会把 GameObject.Find() 当成万能工具。我的建议是：只在初始化阶段用 Find/FindWithTag 建立引用，不要放进 Update 或频繁调用的方法里。因为 Find 是按名字遍历场景对象的，每帧都找一次，场景一大就是纯 CPU 浪费。绝大多数情况下，把需要的引用通过 Inspector 拖拽，或通过静态容器、事件系统传递，都比运行时“大海捞针”靠谱。

1.2 生命周期回调：引擎在固定时机自动打给你的电话

MonoBehaviour 的生命周期回调是Unity脚本的基础协议。把它们想象成引擎在固定时机给你打的电话：你不接没关系，信号还在走；你接了就执行里面的代码。下面这张表列出的顺序值得背下来：

很多人会问，Awake 和 Start 到底有什么不同。简单说：Awake 适合做“自己内部”的准备，Start 适合做“依赖别人准备完毕”的事。比如在 Awake 里 GetComponent 缓存自己的 Rigidbody，在 Start 里去读取另一个脚本的字段。如果你在 Awake 里访问别人 Start 才初始化的数据，很容易拿到空引用。

OnEnable 和 OnDisable 看起来不起眼，其实很关键。如果你在一个对象上订阅了全局事件，却忘了在 OnDisable 里退订，那对象就算被 SetActive(false)，事件触发时回调依然会执行，造成“幽灵逻辑”。所以事件订阅和退订放到 OnEnable/OnDisable 一起做，是我比较推荐的习惯。

这里要特别提醒：不要主动去调用生命周期方法。把 Awake、Start、Update 当成“引擎按流程拨给我的电话”。如果一段初始化逻辑就是想在多个时机复用，那就把它抽成一个普通方法，从对应的生命周期里调用，而不是手动去调别人的 Awake。

2. 高频的 GameObject 操作：创建、查找、销毁的注意点

对象模型这一个知识点能覆盖掉一半日常API调用。剩下的高频操作基本都在“创建物体、查找物体、销毁物体”这三个动作上。

2.1 三种创建对象的姿势各有用处

创建 GameObject 最常见的有三种写法，适用场景完全不同：

Instantiate 是运行时动态生成的核心API。它的返回值类型是 Object，所以在用的时候最好明确泛型或做类型转换。比如克隆一个预制体并当作 GameObject 使用：

GameObject clone = Instantiate(original);

如果你清楚模板是某类组件，也可以直接克隆组件：Instantiate(rend)会返回一个新的 Renderer。但日常项目里，克隆 GameObject 占了绝对多数。

克隆出来的物体会保留模板的激活状态。如果模板本身是 SetActive(false) 的，克隆体也是失活的。所以常见做法是先把预制体做成失活，需要时再实例化并 SetActive(true)，这样能避免实例化出来的东西在初始化完成前就被玩家看到。

2.2 GetComponent 是高频操作，但别忘了缓存

GetComponent 是Unity脚本里出场率最高的API之一，但它不是免费的。如果你在 Update 里每帧调用 GetComponent，速度慢不说，代码也会变得很乱。尤其是在多脚本互相引用的项目里，一段逻辑里到处 GetComponent，后续维护时根本分不清依赖关系。

我自己的习惯是：在 Awake 阶段统一把用到的基础组件缓存成私有字段。

public class PlayerController : MonoBehaviour { private Animator animator; private Rigidbody rb; private void Awake() { animator = GetComponent<Animator>(); rb = GetComponent<Rigidbody>(); } }

之后的 Update 或方法里，直接用缓存字段就好。GetComponentInChildren 和 GetComponentInParent 更贵，尽量只在初始化时用。如果一个组件要被很多脚本访问，可以在首次拿到后存入一个全局容器或静态字段，避免每次都查。

2.3 销毁对象要理解 Destroy 的两个特性

第一个特性：Destroy 不是立即从内存移除，而是延迟到当前帧更新结束后真正销毁。所以同一帧里，你先 Destroy 一个对象，紧接着去访问它的组件，仍然可能拿到数据。这种“尸体引用”是很多异步逻辑 Bug 的来源。

第二个特性和 C# 的判空有关。Unity 对==做了重载，一个已经销毁的 GameObject 引用，用if (go != null)判断会返回 false。但底层的 C# 对象其实还留在托管堆里，并没有变成 null。所以不要以为go = null;就万事大吉，这只是让引用失效，真正的卸载还要等引擎处理。

另外一个容易忽略的点：Destroy 父物体时，子物体也会一起被销毁。所以不用写循环去逐个销毁子节点。如果只是想让物体暂时“消失”而不是销毁，用go.SetActive(false)更合适，激活状态切换比销毁重建快得多。

销毁还有一个常用重载：Destroy(gameObject, 2f)，指定延迟两秒后销毁。制作“子弹飞出去两秒后消失”这类效果，一行就搞定。

3. Transform 常用 API：位置、旋转、缩放的坑与正确写法

Transform 是每个 GameObject 必然有的组件，也是新手最容易“感觉懂但写错”的地方。原因很简单：位置、旋转、缩放这些概念在编辑器里看是直观的，一旦到代码里，世界坐标、本地坐标、四元数这些抽象概念全冒出来了。

3.1 position 和 localPosition 为什么不一样

当一个物体没有父节点时，position 和 localPosition 的数值完全一样。但一旦把它放进另一个物体下面，两者就开始分道扬镳：position 是该物体在世界空间里的绝对坐标，localPosition 是它相对于父节点坐标系的偏移。

新手很容易踩这个坑：把叶子节点的 position 读出来，然后赋给另一个物体的 localPosition，结果位置偏到姥姥家。正确的思路是，想让子物体“固定在父物体身上的某个相对位置”，就用 localPosition；想让子物体“出现在世界上的某个点”，就用 position。

同时要注意，父子关系改变时，Transform 上保留的数值不会自动“翻译”成你想要的状态。所以用transform.SetParent(parent, true)时，第二个参数 worldPositionStays 表示是否保持世界坐标不变。多数情况下你希望设为 true，让Unity自动帮你换算 localPosition，而不是改完父节点后物体“啪”地跳走。

3.2 旋转绕不开 Quaternion，但真正要背的只有三个

Unity 的 rotation 属性是 Quaternion 类型，不是 Vector3。直接写transform.rotation = new Vector3(0, 45, 0)会直接报类型不匹配。新手初次看到 Quaternion 会觉得很难，其实日常开发记住三个API就够了：

Quaternion.Euler(0, 45, 0); // 用欧拉角构造四元数 Quaternion.LookRotation(transform.forward); // 让物体“看向”某个方向 Quaternion.Slerp(from, to, t); // 在两个旋转之间插值

引擎内部用四元数是为了避免欧拉角插值时出现的万向锁问题，同时在旋转之间做插值更平滑。你没必要手写四元数乘法，只要理解“旋转的数值单位是不是角度，而是旋转状态”就行。

如果你在编辑器里调试某个角度，真正想改的是 eulerAngles。例如让物体逐步旋转到固定角度：

Vector3 targetAngle = new Vector3(0, 45, 0); transform.eulerAngles = Vector3.MoveTowards(transform.eulerAngles, targetAngle, 90f * Time.deltaTime);

还有一个坑经常出现在角色朝向：直接用transform.forward时，旋转会影响这个方向，因此读完 forward 后最好 normalized 一下，避免父节点缩放带来的长度漂移。

3.3 移动物体：直接改 position 和 Translate 怎么选

最简单直接的位置增量写法是：

transform.position += Vector3.forward * speed * Time.deltaTime;

这是沿世界坐标系Z轴方向移动。如果想让物体沿自身朝向移动，用：

transform.position += transform.forward * speed * Time.deltaTime;

Transform.Translate 本质上是帮你处理了“自身坐标/世界坐标”的切换：

transform.Translate(Vector3.forward * speed * Time.deltaTime);

默认按自身坐标移动；需要按世界坐标时，写明 Space.World：

transform.Translate(Vector3.forward * speed * Time.deltaTime, Space.World);

关键点是，别把两种坐标系混在一起用。很多斜向移动速度异常的情况，都是因为没有 normal 方向向量：斜着移动时，Vector3(1, 0, 1) 的长度是 1.414 左右，所以角色斜走会明显更快。先 normalize 再乘速度，是解决这个问题的标准做法。

如果你的物体挂了 Rigidbody，那么移动方式要另说。靠 transform.position 直接改位置，会让物理引擎的碰撞和速度状态产生混乱，造成抖动、穿墙。正确的做法是rb.MovePosition(rb.position + offset)，或者施加一个速度/力。记住一个原则：有刚体就走物理API，没有刚体才自由操作 Transform。

3.4 方向向量和坐标转换的实用API

Transform 除了位置和旋转，还提供了一组方向向量：transform.forward、transform.right、transform.up，它们分别返回物体自身坐标系下 Z 轴、X 轴、Y 轴在世界空间中的方向。这个特性在做相对移动、朝向判断时非常有用。

还有两个坐标转换API，虽然出现频率不高，但用对时很省事：

• TransformPoint(Vector3 localPos)：把一个本地坐标转换为世界坐标。
• InverseTransformPoint(Vector3 worldPos)：把一个世界坐标转换到物体本地坐标。

举个具体的场景：你想判断某个世界坐标点是在角色的前方还是后方，可以Vector3 local = transform.InverseTransformPoint(targetPoint);，然后看 local.z 的正负。这个读法比计算点积直观多了。

4. 让行为稳定运行：Time 与 Mathf 的实战用法

很多新手写出来的移动速度在不同帧率下一会儿快一会儿慢，问题基本都出在 Time 相关API的使用上。

4.1 为什么所有增量计算都要乘 Time.deltaTime

Unity 的 Update 是“每帧”调用，但每帧的真实耗时不是固定的。如果直接写transform.position += Vector3.right * speed;，那么帧率越高的机器上物体跑得越快。这就好比同一个动作在60FPS下每秒执行60次，在30FPS下每秒执行30次，次数不一样，位移量自然不一样。

正确做法是把“每秒速度”换算成“每帧位移”：

transform.position += Vector3.right * speed * Time.deltaTime;

speed 以“单位/秒”为单位，Time.deltaTime 是上一帧到这一帧实际消耗的秒数。这样无论帧率怎么波动，一秒钟的累计移动都基本等于 speed，物体快慢才能一致。

FixedUpdate 里的时间步长是固定的，和帧率无关，物理引擎默认按照每秒50次固定步长来算。不要在 FixedUpdate 里用 Time.deltaTime 或者 Time.deltaTime 去处理游戏逻辑，会拿不到“这一帧”的真实感觉；在 FixedUpdate 里确实要用 deltaTime 的话，正确的应该是 Time.fixedDeltaTime。不过日常移动逻辑还是放在 Update 里更直观，物理行为才放 FixedUpdate。

4.2 Time.timeScale 暂停游戏时，UI和倒计时怎么办

Time.timeScale 是全局时间缩放因子，设置为 0 可以让整个游戏逻辑暂停。但要注意，它影响的是所有基于 Time.deltaTime 的逻辑，也包括协程里的 WaitForSeconds。如果你只是暂停游戏，却希望界面动画、新手引导倒计时继续走，就要用 unscaled 系列的API：

Time.deltaTime; // 受 timeScale 影响 Time.unscaledDeltaTime; // 不受 timeScale 影响

举一个我实际用过的场景：游戏暂停菜单弹出后，UI按钮的呼吸动画要动，背景粒子要缓慢旋转，但场景里的敌人和角色全部冻结。当时我把所有UI动画的更新都改成Time.unscaledDeltaTime，暂停逻辑才不会连带把菜单也冻住。

另一个相关API是Time.time，它返回从游戏开始到当前帧经过的总秒数，会受 timeScale 影响。Time.realtimeSinceStartup则是从进程启动到现在的真实时间，不受 timeScale 影响。做性能统计、超时判定时，这两个的差别要分清楚。

4.3 Mathf 常用函数，一张表足够应付大部分日常

Mathf 是Unity对C# Math的增强封装，处理浮点、角度、插值特别顺手。下面这几个是我几乎每个项目都会用到的：

有个关于 Lerp 的经典误解：Mathf.Lerp(a, b, 0.5f)不是“移动一半距离然后停下”，它是一次性跳到中点。很多教程写“每帧 Lerp(0.5) 实现平滑跟随”，实际上每帧起点都在更新，所以物体会先快后慢地趋近目标。这种追踪效果没问题，但如果想要严格的匀速靠近，就用 MoveTowards。

实战里我特别喜欢把 Mathf.PingPong 和 Time.time 组合起来做循环动画，比如让一个巡逻点来回移动：

float patrolX = Mathf.PingPong(Time.time * 2f, 5f); transform.position = new Vector3(patrolX, 0f, 0f);

这样物体就会在0和5之间来回走，省去自己维护方向标志位的代码。

5. 输入与物理检测：让对象真正“动起来”和“探到东西”

游戏逻辑里，用户输入和物理检测是两块最贴近玩法表现的API区域。玩起来手感和它门高度相关，坑也挺多。

5.1 Input 的三组常用方法要放在 Update 里

Input 类在 Update 里读取是最合理的选择，因为 Update 正好和帧同步。三组最容易混淆的读取方式：

• Input.GetKeyDown(KeyCode.Space)：松手后的“按下瞬间”这一帧返回 true。
• Input.GetKey(KeyCode.Space)：按住期间每帧都返回 true。
• Input.GetKeyUp(KeyCode.Space)：松开的瞬间这一帧返回 true。

如果你想做一个“按下空格时跳跃”的判断，用 GetKeyDown。如果写成了 GetKey，角色会在按住空格期间反复跳跃，这就是典型的按一次跳好几次的Bug来源。

对于移动类输入，更常用的是输入轴：

float h = Input.GetAxis("Horizontal"); float v = Input.GetAxis("Vertical");

GetAxis 返回的是连续值，有平滑过渡；GetAxisRaw 返回 -1、0、1。两者都基于 Input Manager 里的配置。我用 GetAxis 多一些，因为它天然自带平滑滤波，手感不会那么“硬”。但要注意，如果项目支持多玩家，每个玩家使用不同手柄时，直接用 Input 类可能会冲突，该换新输入系统就得换。

一个经常被忽略的点：不要因为 FixedUpdate 里物理逻辑多，就把输入判断也放进去。因为 FixedUpdate 的调用频率可能比帧率高，也可能比帧率低，同一帧输入在多个 FixedUpdate 里会被重复读取，导致跳变、灵敏度异常。输入统一在 Update 里读，需要物理作用时再传递过去。

写移动时，建议把方向向量 normalize 一下，避免斜向过快：

Vector3 dir = new Vector3(h, 0f, v).normalized; transform.position += dir * moveSpeed * Time.deltaTime;

这个细节看着小，实际玩起来影响很大。

5.2 Raycast 是“从一点向一个方向发射一条射线”的查询

射线检测是鼠标点击、视野判断、自动瞄准的基础。最常用的鼠标点击选中物体写法：

private Camera mainCam; private void Awake() { mainCam = Camera.main; } private void Update() { if (Input.GetMouseButtonDown(0)) { Ray ray = mainCam.ScreenPointToRay(Input.mousePosition); if (Physics.Raycast(ray, out RaycastHit hit, 100f)) { GameObject hitObject = hit.collider.gameObject; // 处理点击逻辑 } } }

这里有个性能相关的细节：Camera.main内部是按标签查找主相机的，虽然现代版本有一定缓存，但你还是应该养成在 Awake 里缓存一次的习惯，避免每次点击都去找一次相机。

Raycast 默认检测的是碰撞体，Collider 组件是必须存在的。如果一个物体没有 Collider，射线只会穿过它。另外，射线命中触发器和普通碰撞体的行为受项目设置影响。默认情况下，触发器是否会被射线检测到由Physics.queriesHitTriggers决定，如果你发现自己明明点中了目标却没反应，先检查那个 Collider 是不是 Is Trigger。

LayerMask 是物理检测里用来“只检测特定层”的参数。它和常规整数不一样，用位运算处理。比如只想检测玩家，不检测敌人，可以：

int playerMask = LayerMask.GetMask("Player"); if (Physics.Raycast(ray, out hit, 100f, playerMask)) { }

想对蒙版取反，用~mask。这个细节很多人第一次写会写成逻辑取反，结果撞墙。

5.3 OverlapSphere 做范围检测，适合炸弹、索敌

OverlapSphere 是“以某个点为球心，探测半径内所有碰撞体”的API。用法很直接：

Collider[] results = Physics.OverlapSphere(transform.position, 5f, enemyMask); foreach (Collider col in results) { // 对范围内的敌人造成伤害 }

它的优点是简单，缺点是每次调用都会返回一个新的 Collider 数组。如果每帧都调，会产生一定的分配开销。做范围检测时，我习惯用协程或者一个计时器，把检测频率降到每0.2秒一次，而不是每帧都扫描一遍。

还有一个隐蔽的问题：OverlapSphere 返回的是碰撞体，不保证中心点在球内，可能只是碰撞体碰到球边界。所以如果你需要“以中心点距离小于某个值才算命中”的精确逻辑，还得再算一次Vector3.Distance(center, col.transform.position)，或者直接使用Physics.SphereCast做更精准的球形扫描。

6. 协程、实例化和销毁：从单帧逻辑走向流程控制

当项目开始出现“延时两秒后播放动画”“先走到门口，再开门，最后进房间”这类流程时，协程就该登场了。

6.1 协程是分阶段执行的方法，不是多线程

协程的底层是 C# 迭代器。你写一个带有yield return的方法，Unity 会在每个 yield 的暂停点停下来，等条件满足后再继续往下执行。

一个最简单的延迟调用：

private IEnumerator DelayedAction() { yield return new WaitForSeconds(2f); Debug.Log("两秒后执行"); } private void Start() { StartCoroutine(DelayedAction()); }

关键点：协程方法本身在调用时不会直接执行函数体，它只是返回一个 IEnumerator 对象。要启动它，必须用 StartCoroutine 包一层。很多新手直接调用 DelayedAction()，发现里面代码不跑，就是因为漏了这一步。

另外，WaitForSeconds 受 Time.timeScale 影响。如果游戏暂停了，协程里等的两秒可能等不到头。需要不受暂停影响的延迟，就换成 WaitForSecondsRealtime。

停止协程也有讲究。StopAllCoroutines()会把该 MonoBehaviour 上所有协程停掉；StopCoroutine需要传入启动时保存的引用。如果你在某处 StartCoroutine 后没保存返回值，事后想精准停它就会很尴尬：

private Coroutine fadeRoutine; public void StartFade() { fadeRoutine = StartCoroutine(FadeOut()); } public void StopFade() { if (fadeRoutine != null) { StopCoroutine(fadeRoutine); } }

6.2 协程和 Update 的边界在哪里

我的经验法则很简单：连续性的逐帧变化用 Update，带阶段的流程控制用协程。

如果一段逻辑里“先做A，等1秒，再做B”，写成协程的可读性极高：

private IEnumerator Sequence() { ActivateObject(); yield return new WaitForSeconds(1f); PlayAnimation(); yield return new WaitUntil(() => animatorIsFinished); DestroyObject(); }

如果把这种流程硬拆到 Update 里，你就得维护一个状态机，还要处理一堆 if 分支，代码很快就失控了。

但协程也不是越多越好。大量协程同时运行会让执行顺序难以追踪，尤其是和 UI 交互、时间线绑定的场合，出 Bug 后很难定位。大型系统里，我更愿意把流程控制放进状态机或独立的调度类，只在局部小逻辑上用协程。简单项目里协程足够好用，复杂项目别让它成为唯一武器。

6.3 Instantiate 之后的资源生命周期

Instantiate 创建出来的东西，引擎不会自动替你销毁。预制体、子弹、特效一旦生成，就会一直留在场景里，直到你主动 Destroy，或者场景被整体卸载。所以最常见的配合是：

GameObject bullet = Instantiate(bulletPrefab, firePoint.position, firePoint.rotation); Destroy(bullet, 3f);

Destroy 的第二个参数是延迟秒数，做“子弹三秒后自动消失”这种效果非常舒服。

另外要注意，实例化出来的物体，Awake 和 OnEnable 会按正常生命周期执行。如果你希望在创建后立刻改一些参数，不要把初始化代码放在 Awake 里改动时机，那样会被引擎先调，很容易拿不到外部传入的数据。更好的方式是实例化后手动调用一个普通方法，把参数传进去：

GameObject go = Instantiate(prefab); go.GetComponent<MyAbility>().Setup(target);

这样对象的初始化顺序是可控的，不会出现“Awake 先跑，Setup 方法还没被调用”的空引用问题。

6.4 对象池：SetActive 是 Instantiate/Destroy 的高性能替代

频繁创建和销毁对象最大的问题是卡顿与 GC 压力。尤其是一秒生成几十颗子弹的项目，Instantiate/Destroy 循环会不断产生垃圾内存，导致频繁的垃圾回收。我后来的处理方式是做一个最简单的对象池：

用一个 List 保存已经创建但暂时闲置的实例，需要时从池里取一个并 SetActive(true)，用完再 SetActive(false) 放回去。只有在池为空时才真正把预制体实例化一次。这样的做法既减少了 Instantiate 调用，又避免 Destroy 的延迟生效带来的潜在坑。

private Queue<GameObject> pool = new Queue<GameObject>(); public GameObject GetObject() { if (pool.Count > 0) { GameObject go = pool.Dequeue(); go.SetActive(true); return go; } return Instantiate(prefab); } public void ReleaseObject(GameObject go) { go.SetActive(false); pool.Enqueue(go); }

这套东西虽然简单，但在弹幕、敌人刷怪、UI飘字等场景里非常管用。Unity 的 API 从来不是孤立存在的，很多优化思路到最后都是多API的组合使用。

最后分享一个我自己的学习习惯。刚开始学的时候，我很喜欢把所有生命周期回调都加上日志，跑到 Play 模式里看一遍调用顺序。用这个方式建立的“引擎先做什么、后做什么”直觉，比死记任何 API 都有用。后来遇到某个回调不执行，第一反应就不再是查函数拼写，而是先问一句：这个对象现在是不是激活的？组件是不是启用？执行顺序是不是不对？这三个问题能解决掉很大一部分“脚本不工作”的疑难杂症。API 只是工具箱里的工具，真正值钱的还是你对引擎运行机制的理解。希望这篇 Unity学习01_常用API 能帮你减少一点踩坑次数。