Unity封装协程异常求助：协程执行在yield处中断

这种协程半路“失联”的问题真的很磨人，我帮你梳理几个关键排查方向，从最基础的错误到协程的核心运行逻辑一步步来：

你的C类代码里有两个明显的错误，会直接抛出异常让协程中断，这是最容易排查的点：

• List的长度判断要用names.Count而不是names.Length（Length是数组的专属属性，List用Count）
• names.RemovaAt(0)是拼写错误，正确写法是names.RemoveAt(0)
  这些错误会在运行时抛出异常，直接终止协程。赶紧打开Unity的Console窗口，看看有没有未捕获的异常日志——这大概率是你当前问题的导火索。

你的B类是MonoBehaviour但没有挂载到任何GameObject上，而且你在A里直接用B.Bar(text)调用一个非静态的实例方法，这本身就违反了Unity协程的运行规则：

• 协程的运行必须依托一个激活状态的MonoBehaviour实例，如果你调用的是B的实例方法，但没有B的有效实例（因为没挂载，也没通过AddComponent创建），要么编译报错，要么运行时协程启动后直接中断在第一个yield return处。

给你两种修正思路：

• 如果B不需要MonoBehaviour的生命周期（比如不需要Update、OnDestroy等），直接把B改成普通类：

  public class B { 
      public IEnumerator Bar(string text) { 
          // do some stuff 
          yield return Something(text); 
      } 
      public IEnumerator Something(string text) { 
          // do some stuff 
          yield return C.FooBar(new List<string>(text.Split(someChar))); 
          // wait for C.FooBar and do some more stuff 
      } 
  }
  

  然后在A里实例化B再启动协程：

  public class A : MonoBehaviour { 
      public void Foo() { 
          string text = "some text here"; 
          var bInstance = new B();
          StartCoroutine(bInstance.Bar(text)); 
      } 
  }
  

• 如果B必须是MonoBehaviour，那得给它找个“宿主”：在某个激活的GameObject上添加B组件，或者在A里动态创建：

  public class A : MonoBehaviour { 
      private B bInstance;
      void Awake() {
          // 给当前GameObject添加B组件作为实例
          bInstance = gameObject.AddComponent<B>();
      }
      public void Foo() { 
          string text = "some text here"; 
          StartCoroutine(bInstance.Bar(text)); 
      } 
  }
  

有时候协程里的异常不会在Console里直接显示（尤其是在yield return之后的代码），给每个协程方法套个try-catch，强制输出异常信息：
比如在B的Something方法里：

public IEnumerator Something(string text) { 
    try{
        Debug.Log("进入B.Something方法");
        // do some stuff 
        Debug.Log("准备调用C.FooBar");
        yield return C.FooBar(new List<string>(text.Split(someChar))); 
        Debug.Log("完成C.FooBar的等待");
        // wait for C.FooBar and do some more stuff 
        Debug.Log("执行后续逻辑");
    }catch(Exception e){
        Debug.LogError($"B.Something出错: {e.Message}\n{e.StackTrace}");
        yield break; // 终止协程
    }
}

这样就能精准定位到哪一行代码抛出了异常，导致协程中断。

C是挂载在GameObject上的，但要确保：

• C所在的GameObject处于激活状态（没有被禁用）
• C组件本身没有被关闭
  如果C的载体被禁用，它的协程会直接暂停，后续的yield return就不会继续执行了。

你说之前测试正常现在突然失效，那大概率是某个配置或依赖代码变了：

• 有没有修改过Unity的脚本执行顺序？比如A的Foo调用时，C还没完成初始化？
• 有没有修改过someChar的值？比如现在text.Split(someChar)得到的是空数组，导致C的FooBar直接结束，让你误以为是中断？
• 有没有更新Unity版本？某些版本的协程处理可能存在bug，或者API有细微变化？

在每个yield return前后加上Debug.Log，把协程的执行路径“可视化”：
比如在C的FooBar里：

public IEnumerator FooBar(List<string> names) { 
    Debug.Log($"C.FooBar启动，当前有{names.Count}个元素");
    while (names.Count > 0) { 
        Debug.Log($"正在处理元素: {names[0]}");
        // do some stuff 
        yield return new WaitForEndOfFrame(); 
        names.RemoveAt(0); 
        Debug.Log($"移除元素，剩余{names.Count}个");
    }
    Debug.Log("C.FooBar执行完毕");
}

看Console里的日志，就能清楚知道协程是在哪个yield之后停住的，从而锁定问题根源。

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