Unity GizmoExtensions工具库：提升编辑器调试与可视化效率

1. 项目概述：为什么我们需要GizmoExtensions？

在Unity开发中，尤其是涉及复杂编辑器工具、自定义组件或者关卡设计时，我们经常需要在Scene视图中绘制一些辅助图形。Unity自带的Gizmos和Handles类是我们的老朋友了，它们能画线、画球、画立方体，帮我们直观地理解对象的边界、路径点或者交互区域。但用久了你会发现，原生API提供的形状就那么几种，想画个箭头、一个扇形区域、一个带文字的标签，或者一个平滑的贝塞尔曲线，代码量瞬间就上来了，而且每次都得重新造轮子。

这就是GizmoExtensions这类工具包存在的意义。它不是一个官方包，而是社区开发者将那些高频、实用但原生日志没有的Gizmo绘制功能封装起来，形成一个开箱即用的工具箱。我最近在重构一个AI寻路系统的编辑器工具时，就深受其扰——我需要可视化每个AI的视野锥（FOV）、攻击范围、巡逻路径。用原生Gizmos画个锥体，得算顶点、连三角面，麻烦不说，性能在编辑器下也不够优雅。直到我系统地尝试了几个热门的GizmoExtensions库，才真正体会到什么叫“生产力解放”。

简单说，如果你满足于在Scene视图里画点、线、面，那原生API够用。但如果你需要：

1. 更丰富的预制图形：如箭头、弧线、扇形、网格、贝塞尔曲线、文字标签等。
2. 更便捷的绘制方式：一行代码调用，参数化控制颜色、持续时间、是否受光照影响等。
3. 更好的性能和编辑器体验：避免手动Mesh操作，支持在编辑器模式下高效绘制复杂图形。
4. 增强的调试与可视化能力：为你的自定义Inspector、编辑器窗口提供强大的可视化支持。

那么，深入了解一下GizmoExtensions，绝对是值得投入时间的一件事。它能让你的开发调试过程如虎添翼，也让你的工具看起来更专业。

2. 核心工具选型与横向对比

市面上叫GizmoExtensions或者类似名字的库不止一个，质量也参差不齐。我花了些时间，重点测试了三个在GitHub和Unity社区讨论度较高的免费方案。它们各有侧重，适合不同的使用场景。

2.1 方案A：Runtime Gizmos (开源社区版)

这是一个非常经典且功能全面的库。它最大的特点是区分了运行时（Runtime）和编辑器（Editor）的绘制。

• 核心特性：

  • 双模式支持：提供RuntimeGizmo和EditorGizmo两套API。前者在游戏运行时（Play Mode）也能绘制，且性能经过优化；后者专为编辑器模式设计，功能更强大。
  • 图形种类极多：除了基础图形，还支持绘制坐标系、视锥体、自定义Mesh、3D文本、甚至简单的图表。
  • 交互式Gizmo：部分版本提供了简单的3D控件（如移动、旋转手柄），虽然比不上专业的编辑器工具，但对于简单的自定义编辑器来说很实用。
  • 链式调用与流畅API：支持.SetColor().SetDuration().DrawWireCube()这样的链式调用，写起来很舒服。

• 优点：

  1. 功能最全，几乎你能想到的图形它都有。
  2. 文档相对完善，有较多的示例场景。
  3. 社区活跃，遇到问题容易找到讨论。

• 缺点：

  1. 代码结构稍显庞大，如果只需要几个简单功能，引入整个库有点“杀鸡用牛刀”。
  2. 部分高级功能（如交互手柄）的实现可能在不同分支版本间不一致，需要自己甄别。
  3. 由于功能多，初次学习成本略高。

实操心得：这个库适合中大型项目，或者你需要开发功能复杂的编辑器插件。它的运行时绘制性能确实不错，我在一个需要实时显示上百个AI单位视野和路径的Demo中使用了它，帧率保持得很稳定。

2.2 方案B：Gizmos Extensions (轻量实用派)

这个库更偏向于“Extensions”的本意，即对Unity原生Gizmos类的直接扩展。它通过静态类提供了一系列扩展方法。

• 核心特性：

  • 无缝集成：使用方法类似Gizmos.DrawWireSphere，变成了GizmosExtensions.DrawWireArc或Gizmos.DrawArrow（通过扩展方法）。
  • 轻量级：通常只有一个核心C#文件，直接拖入项目即可使用，几乎零依赖。
  • 专注基础图形扩展：主要提供箭头、圆弧、扇形、贝塞尔曲线等最常用但原生缺失的图形。

• 优点：

  1. 极其轻量，接入成本为零。对于小型项目或快速原型开发，这是最大的优势。
  2. API设计符合直觉，如果你熟悉原生Gizmos，上手毫无障碍。
  3. 因为简单，所以稳定，几乎不会带来兼容性问题。

• 缺点：

  1. 功能相对单一，只有绘图功能，没有交互、文字标签等高级特性。
  2. 通常只支持编辑器模式绘制，在运行时（Play Mode）使用可能需要条件编译或额外处理。
  3. 扩展的图形数量有限，遇到复杂需求可能仍需自己动手。

实操心得：这是我个人在大多数情况下的首选。当我的工具只需要画一些辅助线、范围指示器时，引入这个轻量库是最快最省心的。它的代码也很简洁，必要时我可以直接复制我需要的那个绘制函数到自己的工具类里，实现完全的自定义。

2.3 方案C：Unity社区资源商店的免费资产

在Unity Asset Store里搜索“Gizmo”或“Debug Draw”，也能找到一些免费的、带漂亮图标和完整示例的资产包。这些资产通常是开发者将自己用的工具打包发布。

• 核心特性：

  • 开箱即用的可视化效果：很多资产提供了更美观的材质和着色器，比如渐变色、半透明填充、屏幕空间固定的文字等。
  • 完整的示例场景：购买（或下载免费版）后，通常附带多个示例场景，直观展示每种图形的用法。
  • 可能包含编辑器工具集成：有些资产会提供自定义的Inspector绘制，或者编辑器窗口来管理Gizmo的显示。

• 优点：

  1. 视觉效果最好，适合对Gizmo美观度有要求的项目。
  2. 学习曲线平缓，通过示例场景可以快速理解。
  3. 由个人或小团队维护，反馈可能更直接。

• 缺点：

  1. 质量参差不齐，需要仔细查看评价和更新日期。
  2. 可能依赖特定渲染管线（如URP/HDRP），在项目切换管线时可能出问题。
  3. 黑盒程度较高，如果遇到bug或想深度定制，修改起来不如开源库方便。

横向对比速查表

我的建议是：日常开发备选方案B，开发复杂编辑器工具时评估方案A，对视觉效果有特定需求时去Asset Store寻找方案C。接下来，我将以最常用的方案B（轻量扩展派）为例，深入解析其核心实现与实战应用。

3. 核心实现原理与源码浅析

理解一个工具背后的原理，不仅能让你用得更好，还能在它无法满足需求时自己动手扩展。我们以典型的轻量级GizmosExtensions库为例，看看它是如何实现一个原生Gizmos没有的图形——比如一个3D箭头。

原生的Gizmos.DrawLine只能画线，而箭头是一个“锥形头+线段”的组合体。在编辑器模式下绘制，本质是在OnDrawGizmos或OnDrawGizmosSelected生命周期里，向Scene视图的绘制队列提交顶点和索引数据。

3.1 箭头绘制的实现拆解

一个健壮的DrawArrow函数可能会这样实现：

public static class GizmosExtensions { public static void DrawArrow(Vector3 from, Vector3 to, float headLength = 0.25f, float headAngle = 20f) { // 1. 绘制主体线段 Gizmos.DrawLine(from, to); Vector3 direction = (to - from).normalized; if (direction.sqrMagnitude == 0) return; // 防止零向量 // 2. 计算箭头根部位置（线段末端向前回退一点） Vector3 arrowEnd = to - direction * headLength; // 3. 计算一个垂直于方向向量的“右”向量（用于构造锥形） // 使用一个固定的上向量(0,1,0)来叉乘，如果方向恰好是垂直的，则换用另一个轴 Vector3 right; if (Mathf.Abs(Vector3.Dot(direction, Vector3.up)) > 0.99f) { right = Vector3.Cross(direction, Vector3.forward).normalized; } else { right = Vector3.Cross(direction, Vector3.up).normalized; } Vector3 up = Vector3.Cross(direction, right).normalized; // 4. 计算锥形箭头的两个侧边点 Quaternion leftRotation = Quaternion.AngleAxis(-headAngle, up); Quaternion rightRotation = Quaternion.AngleAxis(headAngle, up); Vector3 leftHeadPoint = arrowEnd + leftRotation * direction * headLength; Vector3 rightHeadPoint = arrowEnd + rightRotation * direction * headLength; // 5. 绘制锥形箭头（两条线从箭头根部指向两个侧边点） Gizmos.DrawLine(to, leftHeadPoint); Gizmos.DrawLine(to, rightHeadPoint); // 可选：连接两个侧边点，使箭头头部闭合 Gizmos.DrawLine(leftHeadPoint, rightHeadPoint); } }

关键点解析：

1. 参数设计：headLength（箭头长度）和headAngle（箭头张开角度）提供了灵活性。你可以让箭头比例固定，也可以让它相对于线段长度自适应。
2. 方向计算：核心是获取从from到to的标准化方向向量。这是所有后续计算的基础。
3. 构建垂直坐标系：为了在垂直于箭杆的方向上“张开”一个角度，我们需要一个垂直于direction的向量作为旋转轴。这里用了一个常见的技巧：先用Vector3.up与direction叉乘得到一个“右”向量，如果direction几乎垂直向上导致叉乘结果近乎零向量，就换用Vector3.forward来保证计算的稳定性。
4. 旋转计算：使用Quaternion.AngleAxis创建绕特定轴旋转的四元数，然后应用到方向向量上，得到偏移后的向量，从而计算出箭头侧边的点。
5. 分段绘制：箭头被分解为1条主线段和2-3条头部线段，由多次Gizmos.DrawLine调用完成。

注意事项：这段代码在OnDrawGizmos中每帧调用是高效的，因为它只提交了少量的顶点数据。但如果要在运行时每帧绘制成百上千个箭头，就需要考虑批处理或使用方案A那种更专业的运行时绘制库了。

3.2 其他常见图形的实现思路

• DrawWireArc (绘制圆弧)：原理是在一个平面内，从起始角度到结束角度，以固定步长采样，用Gizmos.DrawLine连接相邻采样点，形成折线近似的圆弧。核心是Mathf.Sin和Mathf.Cos计算圆上的点。
• DrawFOV (绘制视野锥)：这通常是一个扇形（Fan）。先画一个圆弧，然后将圆弧上的每个点与原点（角色眼睛位置）连线。这比画一个真正的3D锥体（需要Mesh）要简单且高效得多，对于可视化来说通常够用了。
• DrawLabel (绘制3D文字)：这通常不是用Gizmos直接绘制，而是使用Handles.Label方法（在UnityEditor命名空间下）。所以很多扩展库会通过条件编译#if UNITY_EDITOR来封装，确保非编辑器环境不会报错。

理解了这些，你就会明白，GizmoExtensions库并不是魔法，而是将一些常用的几何计算和Gizmos/Handles API调用封装成了更友好的函数。这大大降低了我们开发者的心智负担。

4. 实战应用：构建一个敌人AI可视化调试系统

光说不练假把式。让我们用一个具体的、贴近游戏开发需求的例子，来展示如何利用GizmoExtensions提升工作效率。假设我们正在开发一个潜行游戏，需要为敌人AI实现以下可视化调试功能：

1. 视野范围：一个扇形的视野锥。
2. 听觉范围：一个圆形的可听觉区域。
3. 巡逻路径：连接多个路径点的线，并在每个点显示停留时间和朝向。
4. 当前状态指示器：在敌人头顶用不同颜色和形状的Gizmo表示其状态（如巡逻、警戒、追击）。

我们将创建一个EnemyAIDebugger组件，并挂载到敌人预制体上。

4.1 组件结构与基础绘制

首先，我们定义组件的序列化字段，方便在Inspector中调整可视化参数。

using UnityEngine; #if UNITY_EDITOR using UnityEditor; // 为了使用Handles #endif public class EnemyAIDebugger : MonoBehaviour { [Header("视觉设置")] public float sightRange = 10f; [Range(0, 360)] public float sightAngle = 90f; public Color sightColor = new Color(0, 1, 0, 0.1f); // 半透明绿色 [Header("听觉设置")] public float hearingRange = 5f; public Color hearingColor = new Color(1, 1, 0, 0.05f); // 半透明黄色 [Header("巡逻路径")] public Transform[] patrolPoints; public float waitTimeAtPoint = 2f; public Color pathColor = Color.blue; [Header("状态指示")] public AIState currentState = AIState.Patrol; public enum AIState { Patrol, Suspicious, Chase } // 假设我们引用了轻量级的GizmosExtensions库 // 或者将上一节的DrawArrow等方法直接写在这个类里作为一个内部静态类 }

4.2 实现核心可视化方法

在OnDrawGizmosSelected中绘制（这样只有选中对象时才显示，避免场景过于杂乱）。

#if UNITY_EDITOR private void OnDrawGizmosSelected() { if (!enabled) return; DrawSightCone(); DrawHearingRange(); DrawPatrolPath(); DrawStateIndicator(); } private void DrawSightCone() { // 使用GizmosExtensions绘制扇形 // 假设我们有一个 GizmosExtensions.DrawWireSector 方法 // 参数：中心点，朝向，角度，半径，颜色 Gizmos.color = sightColor; // 填充扇形内部（使用Mesh或Handles绘制实心多边形，这里简化用线条） // 更高级的做法可以像方案A那样使用GL或Mesh进行填充绘制 Vector3 forward = transform.forward; Vector3 origin = transform.position + Vector3.up * 0.5f; // 从眼睛高度开始画 // 绘制扇形边缘线 Handles.color = sightColor; Handles.DrawSolidArc(origin, transform.up, Quaternion.AngleAxis(-sightAngle / 2, transform.up) * forward, sightAngle, sightRange); // 绘制两侧的边线 Gizmos.color = Color.green; Vector3 leftDir = Quaternion.AngleAxis(-sightAngle / 2, transform.up) * forward; Vector3 rightDir = Quaternion.AngleAxis(sightAngle / 2, transform.up) * forward; Gizmos.DrawLine(origin, origin + leftDir * sightRange); Gizmos.DrawLine(origin, origin + rightDir * sightRange); } private void DrawHearingRange() { Gizmos.color = hearingColor; Gizmos.DrawWireSphere(transform.position, hearingRange); // 如果想画实心圆，可以使用Handles.DrawSolidDisc Handles.color = hearingColor; Handles.DrawSolidDisc(transform.position, transform.up, hearingRange); } private void DrawPatrolPath() { if (patrolPoints == null || patrolPoints.Length < 2) return; Gizmos.color = pathColor; for (int i = 0; i < patrolPoints.Length; i++) { if (patrolPoints[i] == null) continue; // 绘制路径点 Gizmos.DrawWireCube(patrolPoints[i].position, Vector3.one * 0.3f); // 在点上方绘制停留时间标签 Handles.Label(patrolPoints[i].position + Vector3.up * 0.5f, $"{waitTimeAtPoint}s"); // 绘制连接线 int nextIndex = (i + 1) % patrolPoints.Length; if (patrolPoints[nextIndex] != null) { Gizmos.DrawLine(patrolPoints[i].position, patrolPoints[nextIndex].position); // 在连线中点绘制箭头指示方向 Vector3 midPoint = (patrolPoints[i].position + patrolPoints[nextIndex].position) / 2; GizmosExtensions.DrawArrow(midPoint, patrolPoints[nextIndex].position, 0.5f, 15f); } } } private void DrawStateIndicator() { Vector3 topPosition = transform.position + Vector3.up * 2f; Gizmos.color = GetStateColor(currentState); // 用不同形状表示状态 switch (currentState) { case AIState.Patrol: Gizmos.DrawWireCube(topPosition, Vector3.one * 0.4f); // 方块代表巡逻 break; case AIState.Suspicious: Gizmos.DrawWireSphere(topPosition, 0.3f); // 球体代表警戒 break; case AIState.Chase: // 画一个向上的箭头表示追击 GizmosExtensions.DrawArrow(topPosition - Vector3.up * 0.2f, topPosition + Vector3.up * 0.4f, 0.3f, 25f); break; } Handles.Label(topPosition + Vector3.up * 0.5f, currentState.ToString()); } private Color GetStateColor(AIState state) { switch (state) { case AIState.Patrol: return Color.blue; case AIState.Suspicious: return Color.yellow; case AIState.Chase: return Color.red; default: return Color.white; } } #endif

4.3 在Inspector中增强可视化控制

为了让调试更便捷，我们还可以为这个组件编写一个自定义的Editor脚本，在Inspector中添加一些按钮，比如“在场景中聚焦所有路径点”、“测试视野检测”等。

#if UNITY_EDITOR [CustomEditor(typeof(EnemyAIDebugger))] public class EnemyAIDebuggerEditor : Editor { public override void OnInspectorGUI() { DrawDefaultInspector(); // 绘制默认的序列化字段 EnemyAIDebugger debugger = (EnemyAIDebugger)target; GUILayout.Space(10); if (GUILayout.Button("聚焦所有巡逻点")) { List<Vector3> points = new List<Vector3>(); if (debugger.patrolPoints != null) { foreach (var point in debugger.patrolPoints) { if (point != null) points.Add(point.position); } } if (points.Count > 0) { // 计算包围盒并聚焦场景视图 Bounds bounds = new Bounds(points[0], Vector3.zero); foreach (var p in points) bounds.Encapsulate(p); SceneView.lastActiveSceneView.Frame(bounds); } } if (GUILayout.Button("模拟玩家进入视野")) { // 这里可以调用一个测试方法，临时在玩家位置画一个红点，并判断是否在视野内 Debug.Log("模拟测试功能需在EnemyAIDebugger中实现具体逻辑"); } } } #endif

通过这样一个系统，我们无需运行游戏，就能在Scene视图中直观地配置和调试敌人的AI参数。巡逻路径是否合理？视野范围是否太大或太小？状态切换的逻辑是否正常？一目了然。这比单纯修改数值然后反复运行游戏测试要高效得多。

5. 性能考量与高级技巧

在编辑器下使用GizmoExtensions通常不用担心性能，因为绘制调用只在编辑和选中的时候发生。但是，如果你将某些调试可视化功能带到了运行时（比如在开发版本中显示敌人的Debug信息），或者需要在编辑器下一帧绘制极其大量的Gizmo，就需要考虑性能了。

5.1 运行时绘制的性能陷阱

原生的Gizmos和Handles在运行时是无效的。这就是为什么像“Runtime Gizmos”这样的库要自己实现一套绘制系统。它们通常使用GL库（立即模式）或者在Camera.OnPostRender回调中创建临时的Mesh进行绘制。

如果你的项目需要在运行时绘制大量调试图形，务必注意：

1. 避免每帧创建新Mesh：这是最常见的性能杀手。应该将需要绘制的图形数据缓存起来，每帧只更新变换矩阵。
2. 使用简单的着色器：调试图形不需要复杂的光照和纹理，使用Unlit/Color或最简单的顶点/片元着色器。
3. 控制绘制数量：提供开关，可以一键关闭所有调试绘制。或者根据距离、重要性进行裁剪（Culling）。
4. 区分编辑器与运行时：使用#if UNITY_EDITOR和#if DEVELOPMENT_BUILD等编译指令，确保发布版本中完全剔除这些调试代码。

5.2 编辑器下的优化技巧

即使只在编辑器下，面对成百上千个对象同时绘制Gizmo，也可能造成场景视图卡顿。

1. 善用OnDrawGizmos与OnDrawGizmosSelected：

   • OnDrawGizmos：每帧都调用，用于绘制始终需要看到的信息（如导航网格边界、永久性标记）。尽量轻量。
   • OnDrawGizmosSelected：只有对象被选中时才调用。将最复杂、最耗性能的绘制放在这里，比如我们上面敌人的视野扇形和巡逻路径。这是最有效的优化手段。

2. 按需绘制，分级显示： 可以在组件中增加一个DebugLevel枚举，比如None、Simple、Detailed。在OnDrawGizmosSelected中根据级别决定绘制内容的多少。简单级别只画个图标，详细级别才画全部范围和数据。

3. 减少复杂的几何计算： 例如，绘制一个平滑的圆或弧线，不需要每帧计算360个点。可以预先计算好单位圆上的顶点数组，绘制时只需进行缩放和平移变换。

5.3 让Gizmo更“聪明”：响应式绘制

一个高级技巧是让Gizmo能够响应鼠标交互。虽然完整的交互式Gizmo（像Unity的移动、旋转工具）实现起来很复杂，但我们可以实现一些简单的功能，比如鼠标悬停高亮。

这需要用到HandleUtility类（在UnityEditor命名空间下）来检测鼠标拾取。例如，在自定义Editor的OnSceneGUI方法中：

#if UNITY_EDITOR [CustomEditor(typeof(MyComponent))] public class MyComponentEditor : Editor { private void OnSceneGUI() { MyComponent comp = (MyComponent)target; // 绘制一个可交互的点 Vector3 pointPos = comp.transform.position + Vector3.right * 2; EditorGUI.BeginChangeCheck(); // Handles.FreeMoveHandle 会绘制一个可拖拽的点，并返回新位置 Vector3 newPos = Handles.FreeMoveHandle(pointPos, Quaternion.identity, 0.1f, Vector3.zero, Handles.DotHandleCap); if (EditorGUI.EndChangeCheck()) { Undo.RecordObject(comp, "Move Point"); // 更新组件中的数据 comp.somePoint = newPos; } // 检测鼠标是否在某个自定义Gizmo上 Event e = Event.current; if (e.type == EventType.MouseMove) { // 计算鼠标位置到某个Gizmo几何体的距离 // 如果距离很近，可以设置一个标志，然后在绘制时改变Gizmo颜色 // 这需要一些几何计算，但能极大提升工具易用性 } } } #endif

实现响应式Gizmo能让你制作的编辑器工具体验媲美Unity原生工具，但这属于更进阶的Editor编程范畴，需要投入更多时间。

6. 常见问题与排查实录

在实际使用GizmoExtensions或自己编写绘制代码时，你肯定会遇到一些坑。这里记录了几个我踩过并且有代表性的问题。

6.1 Gizmo不显示或显示异常

这是最常见的问题，排查思路如下：

1. 检查绘制方法是否被调用：确保你的代码写在MonoBehaviour的OnDrawGizmos或OnDrawGizmosSelected方法中，并且组件是启用的（enabled == true）。
2. 检查Gizmo显示开关：在Scene视图的顶部工具栏，确认Gizmo图标是打开的（那个看起来像摄像机和星星的按钮）。另外，检查下拉菜单中，对应类型的Gizmo（如Icons、Selection等）是否被勾选。
3. 检查坐标和缩放：如果你绘制的图形远离世界原点或者尺寸极其微小（如0.001），在Scene视图中可能看不到。尝试先将绘制位置设为Vector3.zero，尺寸设为Vector3.one，看看是否出现。
4. 编辑器模式与运行时：记住，Handles类下的方法（如Handles.Label,Handles.DrawSolidArc）只能在编辑器模式下使用。如果在运行时脚本中调用，会报错。务必用#if UNITY_EDITOR包裹。
5. 颜色Alpha值：Gizmos.color和Handles.color的Alpha通道如果为0，图形将是完全透明的。确保你的颜色设置有合理的Alpha值（如new Color(1,0,0,0.5f)）。

6.2 绘制顺序与深度测试问题

有时候你会发现Gizmo被场景中的物体遮挡，或者半透明的Gizmo渲染顺序错乱。

• Gizmos默认在所有几何体之后绘制：这意味着它们总是显示在最前面，不会被场景物体遮挡。这通常是期望的行为。
• Handles的绘制顺序：HandlesAPI的绘制顺序更复杂，有时会受到深度测试影响。如果你使用Handles绘制实心图形（如DrawSolidDisc）并希望它忽略深度，可能需要设置Handles.zTest（比较老的Unity版本）或使用Handles.DrawingScope（较新版本）来临时修改渲染状态。不过对于调试可视化，被遮挡一部分通常也能接受。
• 半透明重叠：多个半透明Gizmo重叠时，渲染可能不正确。这是一个经典的半透明渲染排序问题，在调试绘制中很难完美解决，通常可以忽略，或者改用线框模式（DrawWire系列）避免半透明。

6.3 自定义Inspector与Gizmo的协作

当你为组件编写了自定义Inspector（CustomEditor）时，OnDrawGizmos仍然会正常工作。但是，如果你在OnSceneGUI中进行了复杂的绘制，可能会和OnDrawGizmos中的绘制产生冲突或重叠。

• 最佳实践：将所有编辑器下的可视化绘制逻辑，统一放到自定义Editor的OnSceneGUI方法中管理。这样你可以获得更强的控制力，包括使用HandlesAPI和响应交互事件。OnDrawGizmos则保留给最简单的、不需要交互的图标类绘制。
• 性能：OnSceneGUI每帧都会调用（当Scene视图渲染时），即使对象未被选中。如果里面有重逻辑，记得加判断if (Selection.activeGameObject == target.gameObject)，只在选中时执行。

6.4 扩展库的兼容性与版本问题

从GitHub或论坛下载的第三方GizmoExtensions库，可能会遇到以下问题：

1. 命名空间冲突：如果两个库都有GizmosExtensions类，或者和你自己的工具类重名，会导致编译错误。解决方法是修改其中一方的类名，或者使用完整的命名空间来引用。
2. API过时：一些老的库可能使用了已被标记为[Obsolete]的Unity API。Unity会给出警告，并提示新的替代方法。你需要按照提示修改库的源码，或者寻找更新版本的库。
3. 渲染管线支持：一些在Asset Store下载的、依赖特定着色器的可视化资产，可能在Built-in管线工作正常，切换到URP或HDRP后就失效了。在引入前，最好查看其文档或评论，确认其支持的渲染管线。

一个实用的排查清单：

• [ ] Gizmo图标在Scene视图是否开启？
• [ ] 组件是否启用？
• [ ] 绘制代码是否在正确的生命周期方法内？（OnDrawGizmos/OnDrawGizmosSelected/OnSceneGUI）
• [ ] 绘制位置和尺寸是否在合理范围内？
• [ ] 颜色Alpha值是否大于0？
• [ ] 是否使用了#if UNITY_EDITOR包裹了编辑器专用代码？
• [ ] 控制台是否有编译错误或运行时错误？
• [ ] 如果使用了第三方库，其命名空间是否已正确引用？

7. 从使用到创造：封装你自己的Gizmo工具集

经过几个项目的实践，你可能会积累一批自己常用的Gizmo绘制函数。这时，将其封装成你自己的个人工具集，是水到渠成的事情。这样做的好处是：代码风格统一、完全可控、没有外部依赖。

我的建议是创建一个名为MyGizmos或DebugDraw的静态类，放在项目的Editor文件夹下（如果只用于编辑器）或一个Runtime/Utilities文件夹下（如果也需要运行时支持，并配合条件编译）。

一个简单的个人工具集框架：

// MyGizmos.cs using UnityEngine; #if UNITY_EDITOR using UnityEditor; #endif public static class MyGizmos { #if UNITY_EDITOR // 保持与原生Gizmos一致的API风格 public static void DrawArrow(Vector3 from, Vector3 to, float headLength = 0.25f, float headAngle = 20f) { // ... 实现代码同上文 } public static void DrawWireSector(Vector3 center, Vector3 direction, float angle, float radius, int segments = 20) { // 绘制扇形线框 // ... 实现代码 } public static void DrawLabel(Vector3 position, string text, GUIStyle style = null) { Handles.Label(position, text, style ?? GUI.skin.label); } // 一个实用的方法：在世界空间绘制一个2D的十字准心 public static void DrawCrosshair(Vector3 position, float size, Color color) { Gizmos.color = color; Gizmos.DrawLine(position - Vector3.right * size, position + Vector3.right * size); Gizmos.DrawLine(position - Vector3.up * size, position + Vector3.up * size); Gizmos.DrawLine(position - Vector3.forward * size, position + Vector3.forward * size); } #endif // 可以添加一些运行时可用的Debug绘制，例如使用GL或自定义Mesh public static void DrawRuntimeArrow(Vector3 from, Vector3 to, Color color) { // 这里可以调用一个运行时管理器的单例来提交绘制命令 // RuntimeGizmoManager.Instance.SubmitArrow(from, to, color); } }

更进一步：创建一个运行时调试管理器

对于需要复杂运行时可视化的项目，可以创建一个单例管理器RuntimeDebugDraw。它维护一个绘制命令列表，在LateUpdate或特定的摄像机回调中，使用GL或Graphics.DrawMesh执行所有绘制。这样可以将绘制调用合批，提升性能，并提供统一的开关控制。

这条路走下来，你就不再仅仅是GizmoExtensions的使用者，而是成为了创造者。你能根据项目特定需求，打造出最趁手的可视化调试工具，这本身就是一项非常有价值的技能。