在ContinueWith回调中访问自身返回的任务是否合理？有无更安全写法？

你当前用闭包捕获局部continueWithTask变量的写法，运行时逻辑能正常跑通，但存在两个可优化点：

• 触发可空引用警告：因为你先将continueWithTask声明为可空类型并初始化为null，闭包捕获的是这个带可空标注的变量，编译器无法静态验证「回调执行时该变量一定已经被赋值为非空的延续任务」，因此会告警。
• 存在顺序依赖风险：这种写法依赖「变量先声明、再赋值、最后被闭包捕获」的固定执行顺序，如果后续代码调整了执行顺序（比如在变量赋值前就执行了Add操作），就可能引入null引用的bug。

写法调整思路 #

你可以从两个方向改造：

1. 去掉给continueWithTask赋null初始值的步骤，直接在声明变量时就接收ContinueWith的返回值，从根上消除可空标注问题
2. 把回调逻辑抽成独立的局部函数，让闭包捕获发生在变量完全初始化之后，编译器就能正确识别变量的非空状态

改造后代码示例 #

void RunTask(Action someAction)
{
    var task = new Task(someAction);

    // 直接在变量声明时完成赋值，从初始状态就是非空实例
    Task continueWithTask = task.ContinueWith(OnContinuationCompleted);
    
    _runningTasks.Add(continueWithTask);
    task.Start();

    // 局部函数作为ContinueWith的回调，此时continueWithTask已经完成初始化，无空引用风险
    void OnContinuationCompleted(Task antecedent)
    {
        _runningTasks.Remove(continueWithTask);
    }
}

改造后的优势 #

• 从根本上消除可空引用警告：continueWithTask从声明开始就是非空类型，局部函数捕获它时编译器可明确判定其非空状态，不需要手动加!非空断言
• 从代码结构上规避顺序错误：变量的创建、加入跟踪列表、启动原任务的逻辑是线性执行的，不会出现未初始化就被使用的问题
• 可读性更强：把回调的清理逻辑从创建任务的lambda中抽离，代码分层更清晰

• 如果你需要控制延续任务的执行时机（比如仅在原任务成功完成时才移除跟踪），可以在ContinueWith调用时传入对应的TaskContinuationOptions参数，默认的无参数重载会在原任务进入最终状态（成功、失败、取消）时都执行回调，完全适配你需要清理跟踪任务的场景。
• 如果_runningTasks存在多线程并发读写的场景，需要替换为线程安全的集合实现（比如ConcurrentBag<Task>），避免Add/Remove操作的竞态问题。

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