Unity永久while循环协程与Update条件启动协程优劣对比

在性能敏感、触发频率极高的逻辑场景下，仅启动一次、内部通过无限循环等待条件执行业务的协程，确实是规避重复调用StartCoroutine产生GC开销的可行方案。
每次调用StartCoroutine产生GC的核心原因，是Unity协程调度器需要为新协程创建状态管理实例、缓存迭代器执行上下文，这部分分配在高频触发场景下会不断累积，最终触发GC回收导致卡顿。你给出的常驻协程思路本身成立，但存在几个容易被忽略的潜在问题：

• 生命周期管控成本高
  常驻协程不会随业务逻辑执行完成自动终止，只要绑定的MonoBehaviour实例未被销毁、协程未被手动调用StopCoroutine终止，就会一直留在协程调度队列中每帧执行。如果在物体禁用、场景切换、实例销毁时忘记手动停止协程，轻则出现逻辑残留（比如物体已被禁用但逻辑仍在后台运行），重则触发空引用异常、内存泄漏问题。
• 存在隐式GC分配点
  你提供的常驻协程示例代码中，循环内的yield return new WaitForSeconds(0.1f)语句，依然会在每次执行时创建新的WaitForSeconds实例，同样会产生GC。如果要实现完全零GC，需要将WaitForSeconds、WaitForEndOfFrame这类YieldInstruction对象提前缓存为类成员变量，循环内直接返回缓存实例即可。
• 逻辑灵活性较差
  动态启停的协程可以很方便地根据业务状态调整触发时机、执行间隔，也可以灵活绑定到不同MonoBehaviour上匹配生命周期；而常驻循环协程的执行流完全固定在内部循环结构中，后续如果要新增临时暂停、动态调整等待时长、多分支触发等逻辑，需要额外添加大量控制标志位，改造成本更高，也更容易引入逻辑bug。
• 调试维护成本上升
  短生命周期协程执行完成后会自动从调度队列中移除，排查执行时序错误、重复触发类问题时调用链路清晰；而常驻协程会一直存在于调度列表中，如果项目中这类常驻协程数量较多，不仅会增加协程调度器每帧的遍历开销，排查协程相关异常时也很难快速定位问题来源。

常见易产生GC的动态启停写法示例 #

void Update()
{
    if (condition)
    {
        // 每次触发都会调用StartCoroutine产生GC
        StartCoroutine(Example());
    }
}

IEnumerator Example()
{
    if (coroutineRunning)
    {
        yield break;
    }
    coroutineRunning = true;

    // 执行业务逻辑

    yield return new WaitForSeconds(0.1f);

    coroutineRunning = false;

    yield return null;
}

修正后的零GC常驻协程写法示例 #

// 提前缓存等待指令，避免循环内重复new产生GC
private WaitForSeconds _wait01s = new WaitForSeconds(0.1f);

void Start()
{
    // 整个生命周期只启动一次协程，规避StartCoroutine的重复GC
    StartCoroutine(Example());
}

IEnumerator Example()
{
    while (true)
    {
        // 等待触发条件满足
        while (!condition)
        {
            yield return null;
        }

        // 执行业务逻辑

        yield return _wait01s;
    }
}

// 物体销毁时手动停止协程，避免逻辑残留
private void OnDestroy()
{
    StopCoroutine(Example());
}

内容的提问来源于stack exchange，提问作者MarioM