RabbitMQ消息按ServiceNumber保序处理：代码问题与优化咨询

首先看你代码里的核心问题：task.ContinueWith(_ => taskFunc())这一行，因为taskFunc是返回Task的异步方法，所以ContinueWith返回的是Task<Task>——外层Task仅表示「调用taskFunc()这个动作完成了」，而内层Task才是taskFunc里异步操作（比如await Task.Delay(5000)）的完成信号。

但你直接把这个Task<Task>赋值给了_currentTasks[serviceNumber]，并且await taskToAwait时，只会等待外层Task完成（也就是taskFunc()被调用并返回内层Task），不会等待内层的异步操作结束。所以第二个任务进来时，第一个任务的外层Task已经完成，它的ContinueWith会立刻执行第二个taskFunc，导致第二个任务先输出，而第一个任务还在Delay中。

举个直观的例子：第一个任务的ContinueWith链是CompletedTask → 调用taskFunc()（返回一个等待5秒的Task），外层Task在调用完taskFunc()就结束了，所以第二个任务看到的task已经是完成状态，直接启动自己的taskFunc，自然先输出。

方案1：快速修复ContinueWith的用法 #

只需要在ContinueWith后面加上.Unwrap()，把Task<Task>转换成真正代表异步操作完成的Task：

taskToAwait = _currentTasks[serviceNumber] = task.ContinueWith(_ => taskFunc()).Unwrap();

这样_currentTasks里存储的就是等待taskFunc内部异步操作完成的Task，第二个任务就会等待第一个任务的异步操作结束后才开始执行。

方案2：用async/await替代ContinueWith（更推荐） #

ContinueWith是较底层的异步API，容易出错，用async/await的写法更清晰，也能避免嵌套Task的问题：

private readonly Dictionary<string, Task> _currentTasks = new Dictionary<string, Task>();
private readonly SemaphoreSlim _semaphore = new SemaphoreSlim(1);

private async Task WrapMessageInQueue(string serviceNumber, Func<Task> taskFunc)
{
    await _semaphore.WaitAsync();
    try
    {
        // 获取当前该ServiceNumber的最后一个任务，没有则用CompletedTask
        if (!_currentTasks.TryGetValue(serviceNumber, out var lastTask))
        {
            lastTask = Task.CompletedTask;
        }
        // 定义新的任务：等lastTask完成后，执行taskFunc
        async Task ExecuteNext()
        {
            await lastTask.ConfigureAwait(false);
            await taskFunc().ConfigureAwait(false);
        }
        var newTask = ExecuteNext();
        _currentTasks[serviceNumber] = newTask;
        await newTask.ConfigureAwait(false);
    }
    finally
    {
        _semaphore.Release();
    }
}

这种写法完全用async/await串起任务链，逻辑直观，不容易踩异步嵌套的坑。

如果是在生产环境中处理RabbitMQ消息，还可以补充以下优化：

• 异常隔离：如果某个taskFunc抛出异常，后续同ServiceNumber的任务会全部失败，建议在ExecuteNext中添加try/catch，捕获异常后重置该ServiceNumber的任务链，避免影响后续消息。
• 字典清理：对于已经完成所有任务的ServiceNumber，从字典中移除对应条目，避免长期内存占用。
• 全局并发控制：如果需要限制全局的消息处理并发数（而非仅同ServiceNumber串行），可以再加一个全局的SemaphoreSlim。

测试修复后的代码，第一个任务会先等待5秒输出first task finished，然后第二个任务立刻输出second task finished，完全符合预期的顺序。

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