任务取消后音乐队列播放循环终止的原因及ContinueWith生效疑问

咱们先拆解你遇到的问题：当调用SkipSong()取消当前播放任务后，播放循环直接终止，没有继续播放下一首——但添加.ContinueWith(x => { return; })后就恢复正常了。这背后的核心原因和取消操作的异常处理有关，咱们一步步说清楚。

为什么原代码会终止循环？ #

当你调用_cts.Cancel()时，discord.WriteAsync(..., cts.Token)会触发OperationCanceledException，这个异常会从PlayMusicAsync方法冒泡到StartPlayingAsync的try块。但关键是：使用await时，由CancellationToken触发的取消会被包装成TaskCanceledException，而你的代码没有捕获这个异常。

未被捕获的TaskCanceledException会直接终止StartPlayingAsync方法，整个播放循环自然也就停了，不会继续取下一首歌曲。

为什么ContinueWith能解决问题？ #

ContinueWith会创建一个新任务，它会在原始任务完成（无论正常、失败还是取消）后执行。最关键的点是：如果原始任务是取消状态，ContinueWith不会主动将异常冒泡出来，除非你主动访问x.Exception。

当你await这个ContinueWith返回的任务时，它会忽略原始任务的取消异常，让代码继续执行finally块重置CancellationTokenSource，然后回到循环逻辑，自然就能播放下一首了。

不过这种方式其实是一种“取巧”的写法，不是推荐的最佳实践——它会隐藏所有异常（包括非取消类的错误），可能掩盖潜在的bug。

更优雅的解决方案：主动处理取消异常 #

更好的做法是在try块里主动捕获TaskCanceledException，明确处理“歌曲被跳过”的场景，代码可读性和健壮性都会更高。修改你的StartPlayingAsync方法如下：

public async Task StartPlayingAsync(IAudioClient audioClient, SocketCommandContext context)
{
    IsPlaying = true;

    while (HasNextSong)
    {
        var nextSong = PopSong();

        if (nextSong is null)
        {
            await context.Message.ReplyAsync("Error.");
            continue;
        }

        try
        {
            await _musicPlayer.PlayMusicAsync(nextSong, audioClient, context, _cts);
        }
        catch (TaskCanceledException)
        {
            // 明确处理歌曲被跳过的逻辑，比如给用户提示
            await context.Message.ReplyAsync("已跳过当前歌曲！");
        }
        catch (Exception ex)
        {
            // 处理其他播放异常
            await context.Message.ReplyAsync($"播放出错：{ex.Message}");
        }
        finally
        {
            _cts.Dispose(); // 别忘了释放旧的CancellationTokenSource资源，避免内存泄漏
            _cts = new CancellationTokenSource();
        }

        await Task.Delay(1000);
    }

    IsPlaying = false;
}

另外还有两个小优化建议：

1. 优化参数传递：你的PlayMusicAsync只用到了CancellationTokenSource的Token，建议直接传入CancellationToken即可，这样更符合单一职责原则，也避免外部代码意外修改CancellationTokenSource状态。修改后的方法签名：

   public async Task PlayMusicAsync(YoutubeMediaInfo youtubeMediaInfo, IAudioClient audioClient, SocketCommandContext context, CancellationToken cancellationToken)
   

   调用时传入_cts.Token就好。
2. 资源释放：在finally块里调用_cts.Dispose()，释放旧的CancellationTokenSource，避免潜在的内存泄漏。

总结 #

你原来的问题本质是未处理取消操作引发的异常，导致播放循环被终止。ContinueWith通过隐藏异常解决了问题，但不是最佳实践。主动捕获取消异常并明确处理，同时做好资源管理，才是更健壮的解决方案。

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