前言¶
写 Unity 脚本时，出问题往往不在大逻辑，而在几处固定套路：Awake 和 Start 谁先执行、GetComponent 为什么每帧都慢、物理为什么必须放在 FixedUpdate、以及那个最坑的——Destroy 之后的对象看起来不是 null。这些点每个项目都会踩一遍，靠记忆补不如把它交给一个能随取随用的参考。
下面介绍的 Skill 就是为此准备的。它来自 ClawHub 上的 @clawhub_ivangdavila/unity，版本 v1.0.0，MIT-0 协议，作者 Iván。它不是一套可运行的框架，而是一份 Unity 常见错误与正确写法的速查清单，覆盖生命周期顺序、组件缓存、物理时机、假 null、协程、对象池、序列化等九个主题。
需要说明的是：本次核对时，任务线索里提到的 Zoom Video SDK、Unity 视频会议封装、5 分钟预检清单等内容，在官方页面与抓取资料中均未出现，本文不采用。以下只写能核对到的部分。
这是什么¶
一个面向 Unity 开发者的参考型 Skill，定位是「避免常见错误」，不是重构工具。它解决问题的方式是：当你写 MonoBehaviour 代码时，提醒你正确的顺序和正确的调用位置，避免因为框架约定不熟而写出隐性 bug。
出品方为 ClawHub 上的 @ivangdavila/unity，当前版本 v1.0.0，页面显示最后更新于 5 个月前，安全审计为 Pass。标签里带 requires_api_key=false，不需要额外密钥。
核心功能¶
已核实的内容包括九个主题，下面按主题列出要点。
生命周期顺序¶
Awake在Start之前执行，自身初始化放Awake，跨组件引用放StartOnEnable在Start之前，但在Awake之后- 脚本之间的执行顺序不确定，需要时用 Script Execution Order 设置
Awake即使脚本被禁用也会调用，Start只在启用时调用
GetComponent 性能¶
- 每帧调用
GetComponent很慢，应在Awake或Start里缓存 GetComponentInChildren会递归搜索，层级深时开销大TryGetComponent返回布尔值，省掉判空，略快- 用
RequireComponent属性保证依赖存在并写明要求
物理时机¶
- 物理逻辑写在
FixedUpdate而不是Update，与帧率无关 FixedUpdate每帧可能执行 0 次或多次，不要假设与帧一一对应- 用
Rigidbody.MovePosition，直接改transform.position绕过物理 Update里用Time.deltaTime，FixedUpdate里用Time.fixedDeltaTime
Unity 假 null¶
- 已销毁的对象并不是真的
null，== null为 true，但对象仍存在 - 空值条件运算符
?.在这里不可靠，改用== null或布尔转换判断 Destroy不会立即生效，对象要到下一帧才消失DestroyImmediate只应在编辑器里用，打包后会有问题
协程¶
StartCoroutine要求MonoBehaviour处于激活状态，禁用或销毁后协程停止yield return null等一帧，定时用yield return new WaitForSeconds(1)StopCoroutine需要同一方法或协程引用，字符串重载不可靠- 协程不能返回值，需要用回调或写回字段
Instantiate 与对象池¶
Instantiate开销大，频繁创建销毁的对象应当池化Instantiate(prefab, parent)直接设定父级，省掉一次SetParent- 回收前用
SetActive(false)，不要用Destroy - 池中非激活对象放在统一的父级下，保持层级干净
序列化¶
- 私有字段要在 Inspector 里显示，用
[SerializeField]，优先于public public字段自动序列化，但会暴露不想给的接口[HideInInspector]隐藏但仍序列化，[NonSerialized]才完全跳过- 已序列化字段会保留 Inspector 里的值，代码里的默认值在首次序列化后被忽略
ScriptableObject¶
- 作为资产存在的数据容器，可跨场景和 Prefab 共享
- 加
CreateAssetMenu属性可直接右键 Create - 运行时不要在构建版本里修改，改动不会保存（编辑器里除外）
- 适合做配置和物品表，减少 Prefab 重复
常见错误¶
- 每帧调用
Find系列方法，应缓存引用 - 标签比较用字符串，应改用
CompareTag("Enemy") - 物理查询会分配内存，用 NonAlloc 变体如
RaycastNonAlloc - UI 锚点设置不当，换分辨率就拉伸异常
async/await缺少上下文，可用UniTask或谨慎处理错误
安装与启用¶
官方页面给出的安装命令如下：
$ openclaw skills install @clawhub_ivangdavila/unity
另一处入口写的是 npx skills，两者是同一安装流程的不同调用方式。装完后在支持 ClawHub Skills 的 agent 环境中按 skill 名称引用即可。
说明：官方资料里没有提到 Cursor、Codex CLI 或 Claude Code 的专门接入方式，这里不臆测。如果你用的环境不在上述范围内，建议先确认该 agent 是否支持 ClawHub 的 skill 格式。
典型用法¶
这个 Skill 本身不含可执行示例，价值在于写作时的即时参考。实际用法是：打开它，按主题查一条规则，然后回头检查自己的代码。
举例说明用法。当你写了一段每帧调用 GetComponent 的代码：
void Update()
{
var health = GetComponent<Health>();
health.TakeDamage(1);
}
对照上面「GetComponent 性能」一节，应改成在 Awake 里缓存：
private Health _health;
void Awake()
{
_health = GetComponent<Health>();
}
void Update()
{
_health.TakeDamage(1);
}
再比如判断对象是否已被销毁。直接写 if (obj == null) 可能产生假阳性判断，按「假 null」一节的说明，用布尔转换或显式判断来处理，避免在 Destroy 尚未生效的那一帧里做出错误决策。
适用场景与注意¶
适合正在写 MonoBehaviour 脚本、希望少踩框架约定坑的 Unity 开发者，尤其是从其他引擎转过来、对 Unity 生命周期不熟悉的人。也适合做代码评审时作为一份固定检查清单。
需要注意几点：
- 它只覆盖 Unity 客户端脚本层面的常见错误，不涉及服务端、网络、渲染管线优化，也不涉及任何视频会议或 SDK 集成内容。
- 页面显示最后更新于 5 个月前，Unity 版本迭代较快，建议对照你实际使用的 Unity 版本验证少数 API 行为。
- 清单是提示性的，不是强制规则。某些项目里有意违反某条约定（比如放弃对象池）可能是合理的，需要自己判断。
结尾¶
这个 Skill 的价值在于把分散在官方文档各处的约定集中成一份可检索的清单，省掉反复查证的成本。如果你在 Unity 项目里经常和生命周期、缓存、物理时机较劲，可以装一份放在手边。
官方地址：ClawHub 页面 https://clawhub.ai/ivangdavila/unity ，SkillHub 页面 https://www.skillhub.cn/skills/clawhub_ivangdavila/unity 。
