C# WPF异步任务进度上报异常，多任务状态返回相同FileStyle值

• 原有状态更新逻辑的设计前提被打破
  你当前的UpdateStatus方法，是按照单任务串行执行的场景设计的，隐含了一个固定规则：任意时刻只会有1条处于“待完成”状态的行，进度消息里的1/0标记，分别对应“新增一条待完成的Connecting行”、“把当前待完成的行替换为对应任务的完成态内容”。

这个规则在单任务场景下完全成立，但并发4个任务时会完全失效：

1. 4个任务几乎同时启动，先后上报带新增标记的“Connecting...”消息，状态面板会连续新增4条待完成的Connecting行
2. 所有任务共用同一个Progress<string>实例，上报的消息没有携带任何任务身份标识，UpdateStatus在处理完成类上报时，根本不知道这条完成消息对应之前哪一条Connecting行。按照原有单任务逻辑，所有完成消息都会被绑定到最近创建的那一条Connecting行上，反复被替换成不同任务的完成内容。
3. 因为线程池调度的时序不确定性，最后停留在这行上的内容就是最后一个被处理的完成消息——也就是你观察到的DepotList对应的完成文本。而其他3个Connecting行，因为永远等不到和自己对应的完成消息，会一直停留在初始状态。

• 为什么加Thread.Sleep(10000)时观察到逻辑正常？
  加了延时之后，4个任务的进度上报会被错峰触发：任务打出Connecting消息后进入10秒等待，这段时间里其他任务依次打出自己的Connecting消息，等任务醒过来打完成消息时，时序上刚好匹配原逻辑里“当前编辑行”的位置，看起来更新是正确的。本质上这是时序巧合，不是逻辑本身适配了并发场景，只要调度时序变化就会复现原有问题。

注：你通过SQL Profiler观察到4个任务都正确传入了不同的FileStyle参数，恰恰证明Update_FileSchema方法内部的参数传递是完全正确的，问题出在UI层的状态消息匹配逻辑上，和业务方法本身无关。

代码中第三个任务调用的是Update_FileSchemac（方法名多了一个c字符），如果这不是特意定义的重载方法，需要修正为正确的Update_FileSchema方法名，避免意外调用错误逻辑。

核心思路是给每一条进度消息加上任务唯一标识，让状态更新逻辑能准确把消息和对应的状态行匹配起来：

1. 调整进度消息格式
   把原有仅包含“行标记、状态码、消息内容”的格式，扩展为嵌入任务唯一标识（可以直接用FileStyle枚举值当标识，或者给每个任务分配唯一Id），比如格式调整为：
   {行标记}[状态码][任务标识]消息内容
   对应到Update_FileSchema里的上报代码，调整为：

   // Connecting上报
   progress.Report($"1[{StatusCode.Connecting}][{fileStyle}]Connecting...");
   // 完成上报
   progress.Report($"0[{StatusCode.Connected}][{fileStyle}]File Schema ({fileStyle}) Retrieved");
   

2. 改造UpdateStatus方法
   不再基于“当前编辑行”的单任务假设，而是维护一个任务状态字典：
   • 字典的键是任务唯一标识，值是对应任务的状态文本
   • 收到进度消息时，先解析出行标记、状态码、任务标识、消息内容
     • 如果是新增行标记：把任务标识加入字典，初始值为Connecting内容，再把字典里所有任务的状态行按顺序拼接成完整的Status文本
     • 如果是完成更新标记：更新字典里对应任务标识的状态内容，再重新拼接完整的Status文本
3. 可选优化
   不需要给所有任务共用同一个Progress实例，可以为每个任务创建独立的Progress实例，在回调里直接传入任务标识，省去后续消息解析的步骤，性能更好也更不容易出错。

内容的提问来源于stack exchange，提问作者High Plains Grifter