先说个我一直想吐槽的事情：很多刚接触 Unity 的新人，会把“Unity 脚本”理解成“用某门编程语言写代码”。这个理解不能说错，但容易带偏方向。Unity 里的脚本，本质上是挂在场景里某个游戏对象上的“行为组件”——它控制这个对象在运行时做什么、怎么做。换句话说，脚本不是独立的程序，它是游戏对象的一个零件，和 Transform、Rigidbody、Camera 这些组件躺在同一个 Inspector 面板里。
这篇文章就围绕 Unity 脚本这套核心玩法展开，我会从组件与生命周期讲起，把移动、输入、交互、协程、性能优化、常见报错这些新手一定会撞上的东西全部串起来。无论你是刚装好 Unity 还在纠结“脚本到底挂了没挂上”的纯小白，还是已经在写一些简单控制逻辑、想搞清楚为什么代码越来越卡、莫名报错的老手，这篇都能帮你在 Unity 脚本这条路上少走很多弯路。
1. 先搞清楚 Unity 脚本的运行机制：它不是一个独立程序
1.1 脚本是“组件”，不是“程序”
很多从 Python、Shell 或者纯 C 语言转过来的朋友，第一次看到 Unity 工程里的.cs文件，脑子里默认套用的还是“写一个入口函数，从上往下执行”的思路。实际上，Unity 脚本的默认基类是MonoBehaviour，它只做一件事：被 Unity 引擎以组件方式挂到 GameObject 上之后，由引擎在特定时机回调你写的函数。
你可以把场景想象成一部电影，GameObject 是演员，脚本就是你递给演员的剧本。剧本不能自己跑，它必须被交到演员手上，演员按照导演（引擎）的节奏去念台词。所以脚本文件本身不执行，它只是一个定义；真正执行的是“挂载了该脚本的游戏对象”。
这也解释了一个新手最常问的问题：为什么我写好了脚本、没有报错，但是游戏里什么反应都没有？多半是因为没把脚本拖到任何 GameObject 上，或者脚本虽然挂上了，但里面没有引擎会调用的函数（比如Start、Update），代码根本没有执行入口。
1.2 生命周期回调：Unity 脚本的“节拍器”
引擎是如何调用你的代码的？核心就是生命周期回调。每个挂载了脚本的 GameObject，在被实例化、启用、每帧更新、销毁等节点，引擎都会自动调用脚本中对应名字的函数。常见的就这几个：
| 回调 | 调用时机 | 典型用途 |
|---|---|---|
Awake | 对象实例化后立即调用，且只调用一次，脚本未启用也会调用 | 初始化自身引用、赋值字段 |
OnEnable | 每次脚本变为启用状态时调用（包括首次挂载） | 注册事件、订阅消息 |
Start | 第一次Update前调用，且只调用一次 | 获取其它组件引用、初始化逻辑 |
Update | 每帧调用一次，频率不固定，高配机器帧率更高、调用更频繁 | 处理输入、常规逻辑更新 |
FixedUpdate | 固定时间间隔调用，默认 0.02 秒一次（50Hz） | 物理相关操作，如刚体加力、移动 |
LateUpdate | Update之后调用，每帧一次 | 相机跟随、在所有物体移动完后再做最终调整 |
OnDisable | 脚本变为禁用状态时调用 | 反注册事件、释放资源 |
OnDestroy | 对象被销毁时调用 | 清理动态创建的对象、保存数据 |
注意：Awake和Start的区别是面试和实际开发里最容易踩的坑。Awake在对象实例化时立刻执行，即使脚本组件是禁用状态，它也会跑；Start则是在脚本被启用且即将进入第一帧时执行。所以如果你在Awake里引用了还没初始化的外部对象，很可能会拿到空引用。我的习惯是：自身字段的初始化放Awake，需要依赖其它对象已准备好的操作放Start。
Update和FixedUpdate的区别同样关键。Update每帧次数和人眼刷新率、机器性能直接相关，60帧的屏幕每秒调用 60 次，144Hz 的屏幕就更多；而FixedUpdate独立于帧率，固定 50 次每秒。做物理移动时如果放在Update里，帧率波动会导致物体速度忽快忽慢，放在FixedUpdate里才能保证物理模拟的稳定性。
1.3 为什么是 C#：从 IL2CPP 说起
Unity 脚本的默认语言是 C#，如果你对 C# 还不太熟，也不要有心理负担。Unity 脚本用到的 C# 只是语法层面的子集思路，主要面向游戏逻辑，不需要一开始就把 LINQ、泛型、委托这些东西全啃完才动手。
Unity 背后的编译流程大概是这样的：C# 源码先被编译成 IL 中间语言，最终再转为Mono 虚拟机运行或IL2CPP 转换的 C++ 后再编译。在编辑器环境下，默认使用 Mono 运行，调试方便、编译快；发布到移动端或 WebGL 平台时，通常开启 IL2CPP，运行效率更高、代码也更难被直接反编译。这也是为什么你经常在打包设置里看到“Scripting Backend: Mono 2.0 / IL2CPP”这个选项的原因。
理解这一点，对你日常写脚本的意义在于：你用 C# 写的代码，最终在移动端会被转换成高性能 C++ 执行，所以你不需要为了“引擎能跑多快”而牺牲代码可读性；但也不要写出大量每帧执行的低效代码，因为 IL2CPP 只是优化了执行层，优化不了你的算法本身。
2. 动手写第一个脚本：从创建到挂载到真正跑起来
2.1 创建脚本的正确姿势与命名规范
在 Unity 中创建脚本，最直接的方式是在 Project 窗口右键 → Create → C# Script。你也可以在菜单栏 Assets → Create → C# Script。需要注意几点：
文件名必须和类名一致。新建脚本默认叫
NewBehaviourScript，如果你改了文件名，类名不会自动跟着变。如果直接编译，Unity 会报错，因为文件名和类名对不上，脚本无法作为组件挂载。手动改名时，建议连文件带类名一起改，或者先创建一个名字合适的脚本再打开编辑，避免后续手忙脚乱。类名要用大驼峰命名（PascalCase）。比如
PlayerController、EnemyAI，不要用playercontroller这种全小写，也不要带空格和特殊字符。这不仅是规范问题，更是为了防止在某些平台或版本上产生序列化异常。脚本文件要放在
Assets目录下任何一个文件夹里都可以，但建议建立清晰目录结构。比如新建Scripts/Player、Scripts/Enemy、Scripts/UI等文件夹，别把所有脚本堆在一个根目录下。工程一大了，光是找文件就能把你逼疯。
创建之后，双击脚本文件，Unity 会打开默认的代码编辑器（推荐安装 Rider 或 VS Code，不要用系统记事本硬写，后面再解释为什么）。
Unity 新建脚本的默认模板是这样：
using UnityEngine; public class YourFileName : MonoBehaviour { // Start is called before the first frame update void Start() { } // Update is called once per frame void Update() { } }2.2 第一个真正有行为的小脚本：手动控制方块移动
我们做一个最经典的效果：用键盘方向键控制一个方块在场景中前后左右移动。先创建一个 Cube（GameObject → 3D Object → Cube），再新建脚本PlayerController，把脚本拖到 Cube 上。然后打开脚本，改成下面这样：
using UnityEngine; public class PlayerController : MonoBehaviour { public float moveSpeed = 5f; void Update() { float horizontal = Input.GetAxis("Horizontal"); float vertical = Input.GetAxis("Vertical"); Vector3 direction = new Vector3(horizontal, 0, vertical); transform.Translate(direction * moveSpeed * Time.deltaTime); } }逐行拆解这段代码：
public float moveSpeed = 5f;：一个公共字段。只要字段是 public，就会在 Inspector 面板上显示出来，可以直接在编辑器里调整数值，而不需要回代码里改。这是 Unity 工作流最核心的乐趣之一——代码和编辑器联动。Input.GetAxis("Horizontal")：这是旧版输入系统里读取“水平轴”输入的方法，默认对应键盘 A/D 和方向键左右。GetAxis的特点是返回一个从 -1 到 1 的连续值，而且带平滑过渡，所以移动手感会比单纯的GetKeyDown好很多。Vector3 direction：构造一个三维向量，把水平输入放到 X 分量、垂直输入放到 Z 分量，Y 分量保持 0，这样方块只会在地面上移动。transform.Translate(...)：让物体在本地空间或世界空间做位移。这里没指定第二个参数，默认是相对于自身坐标系的移动。Time.deltaTime：这一帧实际消耗的时间，单位是秒。如果不乘Time.deltaTime，移动速度受帧率影响极大——60 帧下每秒走 60 个单位，30 帧下每秒只走 30 个单位。乘上它之后，速度就变成“每秒 5 米”这种绝对数值，和帧率无关。
把脚本挂上去、点击 Play，用方向键控制方块，它就该动了。如果没反应，按这个顺序排查：
- 脚本有没有挂到 Cube 上？Inspector 里有没有看到 Player Controller 组件？
- 场景里是不是有多个物体，控制的是别的对象？
- 有没有把
Update写成update？C# 严格区分大小写，方法名错了引擎不会调用。 - 是不是脚本里还有编译错误？Console 窗口有没有红色报错？有错误时 Unity 会拒绝运行 Play 模式。
2.3 Inspector 面板与序列化字段：代码和编辑器之间如何对话
刚提到public字段会显示在 Inspector 面板上，背后的机制是 Unity 的序列化系统。所谓序列化，就是把对象的状态转换成可以存储或传输的形式，Inspector 里看到的数值、场景保存进.unity文件、预制体修改，都依赖这套机制。
这里有几个实践上的关键规则：
public字段默认会被序列化并显示在 Inspector 中。private字段默认不会显示，但如果加了[SerializeField]特性，Unity 也会把它序列化并显示出来。public字段如果不想暴露到 Inspector，可以加[HideInInspector]特性。
我在实战中推荐的做法是：能不用 public 就不用 public，而是用 private + [SerializeField]。原因很简单：public 意味着外部任何代码都能随意修改这个字段，容易在多人协作或复杂逻辑中产生不可控的耦合；而private [SerializeField]既保留了 Inspector 可视化的便利，又限制了外部访问，安全性高得多。
public class PlayerController : MonoBehaviour { [SerializeField] private float moveSpeed = 5f; }除了字段序列化，还有几个特性值得立刻记住：
[SerializeField] private GameObject _bulletPrefab; [Range(0, 100)] public int health = 50; // Inspector 里变成滑动条 [Header("移动参数")] public float jumpForce = 10f; // Inspector 里显示分组标题 [Tooltip("跳跃力度，单位是牛顿")] public float jumpForce2; // 鼠标悬停显示提示这些特性对调试和团队交接非常有用。给字段加上合理的Header、Tooltip，几个月后你自己回来看工程，或者把代码交给同伴，省下的沟通成本非常可观。
3. 组件交互：脚本操作 Transform、Rigidbody 和其它脚本
3.1 获取组件的三种姿势，以及它们的区别
脚本在游戏对象上作为一个组件存在，它经常需要操作同一个对象上的其它组件，或者场景中另一个对象上的组件。三种常见方式：
方式一：Inspector 拖引用
[SerializeField] private Rigidbody _rb; [SerializeField] private Transform _target;然后在 Inspector 面板上把对应组件或对象拖进去。这最稳妥、性能最好，适合目标明确、引用关系固定的情况。
方式二：GetComponent 运行时获取
private Rigidbody _rb; void Start() { _rb = GetComponent<Rigidbody>(); }GetComponent按类型查找当前对象上的组件。注意：它只查当前对象，不会自动找子物体或父物体上的组件。在Start或Awake里调用一次、缓存结果是可以的；但如果在Update里每帧调用，会产生额外的查询开销，属于性能小陷阱。
方式三：场景查找
GameObject player = GameObject.Find("Player");这是性能最差、最不推荐的方式。Find、FindObjectOfType、FindWithTag这些 API 看起来很方便，实则需要遍历场景中所有对象，而且对对象名极其敏感——只要名字改了一个字符，运行时就拿到空引用。我见过太多项目因为到处用Find，在场景物体一多之后出现卡顿和莫名报错。能用 Inspector 拖引用解决的，别用查找。
3.2 Update 里经常做的事：读取输入、控制移动、监听按键
Unity 脚本的逻辑代码绝大部分集中在Update里。除了上面用过的Input.GetAxis，还有几个高频输入接口需要掌握：
| API | 返回 | 适用场景 |
|---|---|---|
Input.GetKeyDown(KeyCode.Space) | 按下瞬间那次 Update 返回 true | 跳跃、开火等一次触发事件 |
Input.GetKey(KeyCode.W) | 按住期间每帧返回 true | 持续移动、持续加速 |
Input.GetKeyUp(KeyCode.E) | 松开瞬间返回 true | 松开按键才触发的交互 |
Input.GetMouseButtonDown(0) | 左键按下瞬间返回 true | 点击交互 |
Input.mousePosition | 鼠标在屏幕上的像素坐标 | 射线检测、UI 跟随 |
写输入代码时的一个建议：不要直接在Update里写一堆if (Input.GetKey(KeyCode.X))的硬判断，而是先定义好“输入映射”或状态变量，再集中处理。比如：
private bool isJumpPressed; void Update() { isJumpPressed = Input.GetKeyDown(KeyCode.Space); }这样后续做“取消输入、做输入缓冲、接入虚拟摇杆或手柄”时，你的改动会小得多。如果你用的是 Unity 新版 Input System 包，它的事件驱动模型会天然帮你解耦这些问题，但那是另一个篇章，这里先用旧版输入把概念理顺。
3.3 事件型脚本：碰撞、触发器、UI 按钮点击
脚本不仅仅是每帧轮询，它还大量依赖引擎在“发生某件事”时回调你的代码。最常见三种：
碰撞回调OnCollisionEnter
两个物体发生物理碰撞时，会调用挂载在物体上的脚本的相关方法：
void OnCollisionEnter(Collision collision) { Debug.Log("撞到了: " + collision.gameObject.name); }前提是：两个物体都至少有一个 Collider 组件（Box Collider、Sphere Collider 等），并且至少其中一个带有 Rigidbody 组件。两个都没刚体，物理系统不认为它们会发生碰撞。
触发器回调OnTriggerEnter
把 Collider 勾选为Is Trigger之后，这个 Collider 就变成“触发器”——不再阻挡物体，而是在物体进入、停留、离开时发出回调：
void OnTriggerEnter(Collider other) { if (other.CompareTag("Player")) { Debug.Log("玩家进入区域"); } }注意对比：碰撞回调的参数类型是Collision，触发回调的参数类型是Collider，写法不一样，新手包括我自己都拼错过。触发器通常用于采集道具、进入区域触发剧情、检测攻击范围等场景。
UI 按钮监听
UI 脚本里最基础的需求是“点击按钮触发事件”。可以用 Inspector 绑定的方式，把按钮的onClick事件拖到某个脚本的方法上；也可以在代码里动态注册：
[SerializeField] private Button _startButton; void Start() { _startButton.onClick.AddListener(OnStartClicked); } private void OnStartClicked() { Debug.Log("开始游戏"); }UI 按钮的委托注册是“事件驱动”的典型体现——你不需要每帧去检查用户有没有点击，Unity 帮你监听，点到了就回调。
4. 高频实战：移动、旋转、渐隐、相机跟随与计时器脚本
4.1 移动三件套：Translate、Rigidbody、CharacterController
移动物体有三种常见路径，对应不同需求：
Transform 直接移动
transform.Translate适合 UI 动画、简单的非物理移动、场景装饰物动画。优点是简单直接；缺点是完全没有物理交互，物体穿过其它 collider 时不会有阻挡。
Rigidbody 物理移动
[SerializeField] private Rigidbody _rb; [SerializeField] private float moveForce = 10f; void FixedUpdate() { float h = Input.GetAxis("Horizontal"); float v = Input.GetAxis("Vertical"); Vector3 movement = new Vector3(h, 0, v); _rb.AddForce(movement * moveForce); }注意：物理移动要放在FixedUpdate里，因为你操作的是物理组件，需要和物理引擎的固定步长保持同步，而不是跟随渲染帧率。
CharacterController 角色控制器
这是角色类游戏的经典选择，自带斜坡检测、碰撞和防滑效果，不像 Rigidbody 容易把人推飞，也比较接近真实角色的移动手感。移动时调用CharacterController.Move()或SimpleMove()，传入的也是带Time.deltaTime的速度向量。
private CharacterController _controller; void Update() { float h = Input.GetAxis("Horizontal"); float v = Input.GetAxis("Vertical"); Vector3 move = new Vector3(h, 0, v) * moveSpeed; _controller.SimpleMove(move); }4.2 旋转与朝向：LookAt 与四元数的入门
很多新手一看旋转就头大，这个心态我特别理解。你只要记住一个原则：在 Unity 脚本里，不要直接修改变换的欧拉角来旋转，除非你非常明确自己在做什么。优先使用transform.rotation = Quaternion.Euler(...)或者transform.Rotate(...)，因为直接改欧拉角很容易遇到“万向锁”问题，导致旋转结果不符合直觉。
而“让 A 物体看向 B 物体”这个需求，Unity 已经给了你现成的接口LookAt：
[SerializeField] private Transform _target; void Update() { transform.LookAt(_target); }这个代码让当前物体的 Z 轴正方向始终朝向_target，常用于敌人追踪角色、相机跟随目标。
如果想让旋转平滑过渡，而不是瞬间转向，配合Quaternion.Lerp或Quaternion.Slerp：
Quaternion targetRotation = Quaternion.LookRotation(_target.position - transform.position); transform.rotation = Quaternion.Slerp(transform.rotation, targetRotation, Time.deltaTime * 5f);Slerp是球面插值，得到的过渡路径更自然，不会被欧拉角数值突变干扰。同样，位置平滑则常用Vector3.Lerp或Vector3.MoveTowards。
4.3 渐隐渐显的隐藏小技巧：控制物体逐渐消失
很多项目里都有“让物体慢慢淡出再销毁”的需求。最直观的办法是修改Material的透明度，但直接改透明度比较繁琐，需要设置材质的渲染模式。更简单的路线是：
- 把物体挂在 Canvas 下，用 UI 元素（比如
Image、RawImage），或者给它挂一个CanvasGroup组件。 - 每帧调节
CanvasGroup.alpha，或者配合CanvasGroup.interactable = false禁止交互。 - 用协程或
Update把 alpha 从 1 平滑降到 0。
private IEnumerator FadeOut(CanvasGroup group, float duration) { float elapsed = 0f; while (elapsed < duration) { elapsed += Time.deltaTime; group.alpha = 1 - elapsed / duration; yield return null; } group.alpha = 0f; group.gameObject.SetActive(false); }对于普通的 3D 物体，也可以使用Color.Lerp配合透明 Shader；或者直接缩小物体 Scale 到 0 后 SetActive(false)。具体选哪种不关键，关键是理解“在持续一段时间内改变某个值”这三种常见套路：写在 Update 里累计时间、协程里 yield 循环、或者是做 Tween 动画（比如 DOTween）。DOTween 是老项目里几乎人手一个的库，能大幅简化“平滑改变数值”的代码量，新手学到后期建议必装。
4.4 相机平滑跟随的经典写法
相机跟随也是固定流程。最基础的是把相机作为角色的子物体，或者每帧把相机位置赋值到角色位置之上：
// 简单版 transform.position = _target.position + offset;但直接赋值的位置会让相机生硬抖动，尤其是角色带跳跃或加速时特别明显。更顺滑的是使用Vector3.SmoothDamp做一个带阻尼的追尾跟随：
[SerializeField] private Transform _target; [SerializeField] private Vector3 offset = new Vector3(0, 3, -6); [SerializeField] private float smoothTime = 0.2f; private Vector3 _velocity; void LateUpdate() { Vector3 desiredPosition = _target.position + offset; transform.position = Vector3.SmoothDamp(transform.position, desiredPosition, ref _velocity, smoothTime); transform.LookAt(_target); }关键在于LateUpdate：先确保所有Update里的角色逻辑都执行完了，相机再把最终位置对上。如果放在Update，相机的更新顺序和角色更新的先后不确定，画面就会有一帧抖动。SmoothDamp的_velocity参数是内部累积速度，必须用ref关键字传一个持续存在的变量，每次调用它会自动更新，这也是它比手动 Lerp 更顺滑的原因。
4.5 计时器与延迟执行：Invoke 和 Coroutine 的选择
延时触发逻辑是几乎每个游戏都会用到的。Unity 提供了几种方式，区别如下：
| 方式 | 特点 | 适用场景 |
|---|---|---|
Invoke("MethodName", 2f) | 延迟 2 秒调用方法，只能按方法名字符串调用，不方便传参 | 简单的延迟调用 |
InvokeRepeating | 每隔一段时间重复调用 | 间隔性刷怪、技能冷却提醒 |
协程StartCoroutine | 可用yield return null、yield return new WaitForSeconds(...)实现各类延迟、逐帧等待 | 复杂的时序逻辑、动画序列 |
Update中累加计时器 | 手动控制时间累加 | 倒计时、冷却计算 |
协程是新手进阶的必学内容，感受一下延迟 1 秒后执行：
IEnumerator AttackRoutine(float delay) { yield return new WaitForSeconds(delay); Debug.Log("Attack!"); } void Start() { StartCoroutine(AttackRoutine(1f)); }协程不是多线程，它只是利用 C# 迭代器做了一个“可暂停执行的函数”。整个协程还是在主线程上跑的，任何耗时的同步计算依然会卡住游戏。如果你要做的是大规模数据计算或网络请求等待，那就得另找方案（如 async/await、Job System），不要误以为开了协程就能并行。
5. 脚本性能优化：别让代码亲手拖垮帧率
5.1 Update 是万恶之源？不，是垃圾代码才是
很多人会把“每帧执行”看作性能杀手，实际上Update本身的调用开销并不大，真正的性能问题出在你在Update里做了什么。几个典型的反面教材：
反例 1：每帧查找组件
void Update() { transform.GetComponent<Rigidbody>().AddForce(...); // 每帧都查 }应对：在Awake或Start里缓存一次组件引用。
反例 2：每帧创建新字符串
void Update() { Debug.Log("当前分数: " + score); // 每帧产生字符串、触发 GC 垃圾回收 }游戏运行中频繁拼接字符串会在托管堆上产生大量垃圾，触发 GC 时就会出现明显的卡顿。尤其是在 UI 显示面板上每帧更新文字，用StringBuilder或者按需刷新（比如只在数值变化时更新）可以避免大量无意义分配。
反例 3：每帧调用 Find
void Update() { GameObject player = GameObject.Find("Player"); }这个在之前已经反复警告过了，场景复杂时一次 Find 的耗时可能超过你一个完整逻辑帧的预算。
5.2 缓存、对象池、事件驱动：三板斧提升帧率
性能优化不是玄学，就三板斧：
第一板斧：缓存。所有需要重复使用的组件、Transform、Material 都缓存成字段，在生命周期早期取一次。特别是transform属性，Unity 内部每次访问它都要做获取原生对象的桥接，虽然开销小，但你每帧调用几十次同样浪费。
第二板斧：对象池。频繁创建和销毁 GameObject（比如子弹、敌人、飘字），会导致场景反复实例化和销毁，触发 GC 与原生对象分配。对象池的做法是预先创建一批对象，不用的回收到池子里，需要时从池子里取出来启用。
第三板斧：事件驱动替代轮询。尽量让逻辑在“事件发生时”才执行，而不是每个帧都跑一遍检查。比如 UI 血量条，与其每帧更新 HUD 文字，不如在角色真正扣血时才通知 UI 更新。能减少的 Update 工作量，本质上都是白赚的帧数。
5.3 Unity Profiler：边写脚本边看性能
说再多不如实际测量。Unity 自带的 Profiler 窗口（Window → Analysis → Profiler）可以看清每个脚本方法占用的 CPU 时间、GC 分配、渲染和物理耗时。新手可能看不懂太深的分析，但至少要学会看两件事：
- CPU 时间线里每个方法占的比例，哪个脚本的
Update是瓶颈。 - GC Alloc 一栏有没有持续上涨——如果快速上涨，说明产生了大量垃圾对象。
我在工作中见到的性能问题，90% 都可以通过“先 Profile，再优化”的方式定位。很多人不打开 Profiler 就凭感觉乱改，往往会做出“把移动代码从 Update 改成 FixedUpdate”这种无效优化，正确的路径永远是用数据说话。
6. 脚本常见问题与报错排查实录
6.1 每次都见面的 NullReferenceException
十有八九的新手报错都是这个：某个变量是空的，但你尝试使用了它。出现这个报错，先别慌，控制台会告诉你具体是哪个脚本、哪一行出了问题。常见原因：
- 声明了
[SerializeField] private GameObject target;但忘了在 Inspector 里拖引用。 GetComponent<某组件>()返回了 null，因为该对象上根本没有这个组件。- 名字大小写写错，导致
Find返回 null。
排查顺序建议是：先看报错的行号，再高亮选中那个对象，打开 Inspector 看脚本组件上哪个字段显示为None，检查场景中是不是对象被提前销毁或未实例化。有一个小技巧：给可能为 null 的字段写Debug.Assert(field != null, "reason")，运行时一进场景就能快速扫描所有缺失引用，比在游戏里点着到处试高效得多。
6.2 脚本挂不上去：文件名与类名不一致
这个报错在 Console 里通常长这样：...error CS0103: The name 'XXX' does not exist in the current context，或者MonoBehaviour script cannot be attached。最常见原因：
- 你右键新建了脚本，然后重命名了文件名，但类名没改。
- 你复制了一个脚本文件却没有同步改类名。
- 类名首字母小写，和文件名唯一区别是大小写，在 Windows 上可能没问题，但打包到别的平台时容易出诡异问题。
建议的做法是：养成“改文件名必改类名”的肌肉记忆，新建脚本后在代码编辑器里先把类名改成最终版本，再拖到对象上。一旦发现脚本组件图标变成灰色小文件，十有八九是编译有问题或脚本丢失，优先看 Console。
6.3 脚本编译错误导致无法播放
Unity 中没有独立编译脚本的沙盒——脚本在编辑器里和游戏运行时是同一套环境。所以一旦脚本里有语法错误，Unity 会拒绝进入播放模式。对策：
- 代码编辑器里尽量用 Rider 或 VS Code 装上 C# 扩展，写代码时就能提示语法错误，不用等回 Unity。
- 养成写几行代码就切回 Unity 让它自动编译的习惯。Unity 会自动监听脚本变化并重新编译，观察 Console 有没有报错，比写完一大坨再冷不丁编译要高效得多。
- 如果
Console里紫红色报错刷屏，先修第一个报错，后面的往往是连锁反应。
6.4 旧版本工程打开后中文注释乱码
Unity 默认按 UTF-8 处理脚本文件，但很多老项目的脚本是用带 BOM 或 GB2312 编码保存的。在更新到新版本后，中文注释就可能乱码，严重的还会因为字符串编码问题导致编译报错。处理方式：
- 不要让脚本文件是 GB2312，遇到老文件用 VS Code 打开，右下角点编码 → “通过编码保存”，改成 UTF-8。
- 不要直接在 Unity 内置的脚本编辑器里反复保存乱码文件，容易二次污染。
- 如果整个项目所有脚本都乱码，优先用 PowerShell 或写个小工具批量转码，别一个文件一个文件手动改。
6.5 常见问题速查表
| 症状 | 可能原因 | 快速处理 |
|---|---|---|
| 脚本挂上了但没有执行 | 没有引擎回调入口（没有 Start/Update）；脚本可能被禁用 | 确认脚本组件启用，检查方法名大小写 |
| 移动速度不一样 | 没乘Time.deltaTime | 位移、旋转均乘Time.deltaTime |
| 物理物体不动 | 力加在Update而不是FixedUpdate | 移到FixedUpdate |
OnTriggerEnter不触发 | 没有 Collider、没勾 Is Trigger | 给两个对象加 Collider，勾选触发器 |
| 点击按钮没反应 | 没注册点击事件；按钮被遮挡 | 检查 EventSystem；检查 UI 层级 |
| 场景切换后变量丢失 | 场景里手动拖的引用没有保留 | 用 ScriptableObject 或静态管理类保存 |
| 打包后脚本行为异常 | 用了编辑器相关 API 未预处理 | 用#if UNITY_EDITOR包裹编辑器代码 |
排查问题和写代码一样，养成从“框架层 → 对象层 → 代码细节”依次排查的习惯。先在脑子里确认：这个脚本挂在哪？有没有编译错？组件引用齐不齐全？然后再深入单行代码逻辑去找问题。很多新手一报错就跑到网上复制粘贴代码，反而浪费大量时间。
我个人在这些年带项目时，最大的一个体会是：Unity 脚本的学习曲线并不是“学会 C# 语法 → 学会调用 API”，而是“理解游戏对象这个系统 → 理解生命周期 → 学会用组件思维组织代码”。语法只是工具，思维方式才是真正的分水岭。等你能清晰地看出一个功能应该写成哪个生命周期函数、应该用哪些组件配合、哪些事情应该交给事件而不是每帧轮询，Unity 脚本对你来说就不再是拦路虎，而是实现创意最顺手的工具。
