徐术挺-漫思录

17-组件是什么

19分钟阅读

第 17 章 组件是什么：Unity 的积木哲学

前面十几章，你学了一堆”概念”：坐标、网格、三角形、光照、摄像机、雾、声音采样……这些在现实里都是自然存在的现象。但进了 Unity，它们不是凭空飘在那儿的，而是被打包成一个个叫**组件（Component）**的东西，戳在”物体（GameObject）“身上。

这一章要解决的，是一个你迟早会撞上的困惑：

“我学了这么多概念，可 Unity 里到底怎么用？我写代码时，这些东西从哪来？”

答案就是——组件。一个空物体，加上一堆组件，就成了游戏里能跑、能看、能响、能被打的东西。

理解这一章，是你从”懂概念”跨到”能动手”的门槛。也是你后面做塔防、做联机、去面试的底子。

17.1 一个空物体 + 一堆插件 = 一个能跑的东西

先建立一个最朴素的心智模型。

在 Unity 里，最基础的单元叫 GameObject（游戏物体）。但你要知道一个反直觉的事实：GameObject 本身几乎什么都不会。

它就是一个”容器”，一张”身份证”——有个名字，有一个位置（Transform），如此而已。它不会动、不会响、看不见、碰不到。就像一个刚领到的空白员工工牌，上面什么技能都没印。

那能力从哪来？从挂在它身上的组件来。

你想让它能被看见？挂一个 MeshRenderer（网格渲染器）。 想让它有形状、能被打中？挂 MeshFilter（用哪个网格）+ Collider（碰撞体）。 想让它出声？挂 AudioSource。 想让它受重力、能被推？挂 Rigidbody。 想让它播放走路动画？挂 Animator。 你自己写的游戏逻辑？写成一个脚本，也是一个组件，挂上去。

所以记住一句话：一个物体的”能力”，等于它身上挂着哪些组件的组合。

这跟”它是一个什么类”没关系。一个物体之所以是”敌人”，不是因为它继承了 Enemy 类，而是因为它身上拼了”渲染 + 碰撞 + 血量脚本 + AI 脚本”这一堆东西。

反问你一下：如果你只能给空物体贴”技能标签”来定义它，那”塔”和”敌人”的差别，本质上是它们身上贴的标签组合不同——你能说出一座塔和一个敌人，标签组合上大概差在哪吗？（先别急着翻答案，自己想三十秒。）

17.2 为什么不用”继承树”？——组合优于继承

这里有个设计哲学，你作为 Go 程序员会特别有共鸣。

传统面向对象（OOP）喜欢用继承来复用能力：

GameObject
  └─ MovingObject
       └─ Character
            └─ Enemy
                 └─ FlyingEnemy

问题来了：如果有个东西”既会飞、又会游泳、又会唱歌”，继承树怎么写？硬套的话，层级会爆炸，而且很多能力是交叉的，不是”谁包含谁”。

Unity 的解法干脆利落：不要深继承，把能力拆成一个个独立组件，谁需要就挂谁。

  • 敌人 = 空物体 + 渲染 + 碰撞 + 物理 + 血条（自定义）+ AI（自定义）
  • 塔 = 空物体 + 渲染 + 碰撞 + 攻击脚本（自定义）
  • 子弹 = 空物体 + 渲染 + 碰撞（触发）+ 移动脚本

你看，敌人和塔都”看得见、碰得到”，但它们不需要是同一个父类的子类——它们只是”都挂了渲染和碰撞”而已。要加一个新能力（比如”中毒”），敌人不用改代码，再挂一个 PoisonStatus 组件就行。

这叫 组合优于继承（composition over inheritance）。

你现在应该有点”对味”了——Go 语言干脆没有传统继承，它靠 struct 嵌套和接口来组合能力。 Unity 的组件系统，和你在 Go 里把一个 struct 嵌进另一个 struct 来获得能力，思路是同一个祖宗。区别只是：Go 里你在代码里写嵌套，Unity 里你可以在编辑器里用鼠标拖拖拽拽就把组件拼上去，连代码都不用改。

生活化类比：继承像”血统”——你是你爸的儿子，天生带着他的特征，改不了。组合像”装备”——今天穿防弹衣就是坦克，明天换跑鞋就是游击兵，装备一卸，身份就变了。游戏里物体要灵活变身份，所以装备（组件）比血统（继承）好用。

17.3 Transform：每个物体都强制拥有的”地基组件”

你可能注意到了，我前面说”空物体什么都不会”，但又说它”有一个位置（Transform）“。这不矛盾吗？

不矛盾。Unity 给每一个 GameObject 强行塞了一个 Transform 组件，你删不掉。为什么这么霸道？

回到第 2 章。任何一个物体，要在虚拟世界里”存在”，就得有个”地址”——它在哪、朝向哪、多大。这就是 Transform 干的事：它管三件事——

  • Position（位置）：世界里的坐标。
  • Rotation（旋转）：朝哪个方向。
  • Scale（缩放）：放大缩小多少倍。

Unity 强制每个物体都有 Transform，因为没有坐标的物体没法渲染、没法算碰撞、没法被摄像机看到。坐标是一切的地基，所以引擎替你默认装好了。

还有个关键：第 2 章讲的”局部坐标”和”层级”，在组件层面也成立。你把物体 A 拖到物体 B 下面（Hierarchy 面板里），A 就成了 B 的”子物体”，A 的 Transform 坐标就变成相对 B 的。B 一移动，A 跟着动——父子关系，本质是 Transform 的层级链。

思考题铺垫：你前面学过”父物体移动子物体跟着动”。现在你知道了，这背后的机制就是——子物体的 Transform 存的是”相对父物体的偏移”，渲染时再一级级往上加，算出世界坐标。这和 DOM 的 position: relative 父容器移动子元素跟着动，是不是一个道理？

17.4 组件之间怎么”配合”和”通信”

组件默认是”互不认识”的。这是新手第一个卡点：

“我给敌人写了 AI 脚本，它怎么知道玩家在哪？”

答案是：组件不会自动知道彼此，你得帮它们建立联系。常见两种方式：

方式一：引用（直接牵线） 你在代码里写 player = GameObject.Find("Player").GetComponent<PlayerHealth>();，意思是”去场景里找到叫 Player 的物体，拿下它身上的 PlayerHealth 组件”。也可以在编辑器 Inspector 里，把一个物体直接拖到脚本的 public 字段上，运行时自动就有引用了。

方式二：事件 / 消息（广播） 一个组件”死了”，它不认识谁关心这件事，但它可以广播一声”我死了！“。别的组件如果提前”订阅”了这个事件，就会收到通知，各自反应（播放音效、加分、生成掉落物）。这叫观察者模式，你写 Go 时用的 channel / 回调订阅，思想一模一样。

设计心法就一条：组件尽量只管自己的事（单一职责），需要别人时通过引用或事件去拿，别把依赖写死。 一个 EnemyAI 不该硬编码”玩家必须是某个具体类”，它只需要”一个能提供位置的物体”——这就是接口思想的用武之地，和你写 Go 时”依赖接口不依赖实现”完全同构。

17.5 自定义组件：MonoBehaviour 与它的生命周期

你写的每个游戏脚本，本质上就是一个组件。规则很简单：让你的类继承 MonoBehaviour，它就能被挂到物体上。

using UnityEngine;
public class EnemyHP : MonoBehaviour {
    public int hp = 100;
}
// 把这个脚本拖到敌人物体上，敌人就有了"血量"这个能力

但光会写不够，你必须理解组件的”生命周期”——也就是引擎在什么时候调用你脚本里的哪些方法。这是 Unity 面试的高频题，也是你写逻辑不出 bug 的前提。

常见生命周期方法（按时间顺序）：

  • Awake()：物体”出生”时调用，用来初始化自己。所有物体的 Awake 都跑完，才进入下一步。
  • Start()：在第一次 Update 之前调用一次，用来做”依赖别人的初始化”（比如去拿玩家的引用）。
  • Update()：每一帧调用一次，大约每秒 60 次。你游戏里”持续发生的事”（移动、检测输入、计时）都放这。
  • FixedUpdate()：物理步调用，固定时间间隔（默认约每秒 50 次）。凡是跟物理（力、碰撞、Rigidbody）相关的，都放这，别放 Update。
  • LateUpdate()：所有 Update 跑完之后调用，常用于”摄像机跟随”——等玩家先移动完，摄像机再跟，不会抖。
  • OnDestroy()：物体被销毁时调用，用来清理（取消事件订阅、释放资源）。

为什么要把 Update 和 FixedUpdate 分开？回到第 1 章那个”16 毫秒算完一帧”的约束。物理需要稳定的步长才能保证模拟不漂移（你玩物理引擎最懂这个），但渲染帧率是波动的。混在一起，物理会时快时慢。所以引擎把”每帧”和”每物理步”拆成两个口子，你各回各家。

思维切换提醒：你写 Go 的 HTTP handler，是”来一个请求，处理一个”（事件驱动）。Unity 的 Update 是”每一帧，都来一遍”（轮询/状态机驱动）。你写游戏逻辑时，要习惯”每帧都检查一下当前状态”，而不是”等某个事件触发”。这是从后端思维切到游戏思维的第一个坎。

17.6 一个敌人是怎么”拼”出来的（组合实例）

光说抽象没感觉，我们真拼一个。一个塔防里的”小兵敌人”，它身上通常挂着这些组件：

组件负责什么效果
Transform它在哪、朝哪、多大（地基，必有）
MeshFilter用哪个 3D 模型（它的形状数据）
MeshRenderer把这个模型画出来（看得见）
CapsuleCollider给它一个胶囊形的”身体”，能被子弹打中
Rigidbody受物理（比如被击退、受重力）
Animator播放”走路 / 受击 / 死亡”动画
AudioSource播放死亡音效（第 12 章学的）
EnemyHP（你写）自定义血量、受伤逻辑
EnemyAI（你写）自定义巡逻、追玩家、攻击逻辑

注意：没有一个叫”Enemy 类”的东西把这些都写死。 全是拼的。想加个”中毒掉血”效果？不用动敌人本体，再挂一个 PoisonStatus 组件，它自己每帧扣血、变绿就行。想让同一种敌人变强？改 EnemyHP 的 hp 数值，或者换套动画。

这才是组件系统的威力：改能力不改动”是什么”，只动”挂了什么”。

17.7 这一章你该带走的

  • GameObject 是空壳容器；能力来自组件，不是来自继承。
  • Unity 用组合优于继承，和你写 Go 的 struct 嵌套/接口一脉相承。
  • Transform 是每个物体强制拥有的地基组件，管位置/旋转/缩放，也管父子层级。
  • 组件间靠引用或事件通信，单一职责、低耦合是设计原则。
  • 你的脚本就是组件，继承 MonoBehaviour，生命周期方法（Awake/Start/Update/FixedUpdate/LateUpdate）决定了代码在何时跑。
  • 一个游戏物体 = 一堆组件的组合；想加效果就挂组件，想改效果就调组件参数或换组件。

下一章，我给你一张**“内置组件图鉴”**——你以后想实现某个效果，直接查”挂什么组件、调什么参数”。那是你真正动手时的”字典”。

【思考题】

  1. 你说”塔”和”敌人”的组件组合差别在哪？试着各列 5 个左右组件，并指出哪些是共用的、哪些是不同的。
  2. 为什么 Unity 要把 Update（每帧）和 FixedUpdate（物理步）分成两个方法？如果把物理计算写进 Update 会有什么隐患？
  3. 你写 Go 时习惯”事件驱动”（来请求才处理）。Unity 的 Update 是”每帧都跑”。这两种思维在写一个”敌人追玩家”的逻辑时，写法上会有什么不同？
  4. 组件之间用”引用”和用”事件”通信，各适合什么场景？举一个游戏里的例子说明你为什么选其中一种。

【参考答案】

  1. 共用：Transform、MeshFilter、MeshRenderer、Collider（都能被看见、被碰）。不同：敌人多 Rigidbody（被击退）、Animator（走路动画）、EnemyAI（主动追人）、EnemyHP（被击杀）；塔可能多”攻击脚本”（检测范围内部署、定时开火）、AudioSource（开火音效）、ParticleSystem（炮口火光），但通常不需要 EnemyAI 那种主动移动。核心差别：敌人是”主动移动的威胁”，塔是”固定位置的防御设施”——组件组合如实反映了这个身份差异。
  2. 物理模拟需要固定步长才稳定（积分误差不会累积漂移），但渲染帧率随负载波动。分开后，物理按固定频率算，渲染按实际帧率画，互不干扰。若把物理写进 Update：高帧率机器上物理”加速”、低帧率上”变慢”，同样的代码在不同设备表现不同，还会出穿透、抖动等诡异 bug。
  3. Go 写法：“玩家发来移动请求 → handler 更新玩家坐标 → 返回”。Unity 写法：“每帧在 EnemyAI.Update 里检查玩家位置 → 朝玩家方向改自己 Transform → 下一帧再检查”。前者是被动响应请求，后者是主动每帧轮询世界状态。难点在于：Unity 里”敌人追玩家”不是等玩家通知，而是敌人自己每帧去’看’玩家在哪。
  4. 引用适合”稳定、一对一”的关系：敌人 AI 需要知道玩家在哪，直接持有一个玩家引用最高效。事件适合”一对多、松耦合”：敌人死亡时，要通知音效系统放声、计分系统加分、掉落系统生成道具——它不应该认识所有这些系统，只需广播”我死了”，谁关心谁订阅。选错会让代码耦合成一团。

反向链接